ievb

[ievb]

a final entry

monday 21/3 

Today we had presentations. Each group presented their final concept and received some feedback. It was fun to see what everyone had created. Some of the concepts, mainly from the groups I had helped with user testing, were familiar to me whilst other were completely new.

All the ten presentations were constructed in diverse ways. One group started their presentation by posing a question, which is always a very clever way to begin a presentation. It engages the audience and makes them think. Another group had a live demonstration or role-play of their product which I found very enjoyable. Instead of telling people what it does, why don’t we just show you. Multiple groups used videos to display their concept. I am always in favour of that approach since it’s a very straightforward way of informing the audience, if done ‘correctly’. And it also catches peoples attention. 

I couldn’t help but notice how some people during their presentation said: we chose to do this because we wanted to create.. But then not stating after or explaining throughout the presentation why they wanted to? Was it, for example, because of insights they had found from user testing? Or was it just based on preference? Personal opinions? 

Our presentation revolved a lot around our process, talking about how we ended up with this concept. This resulted in not leaving enough room for our final product to shine, which was a bit unfortunate. I know some groups have had a certain focus on one of their concepts for multiple weeks, which wasn’t really the case with us. PaySwipe (our final concept) made a fairly late entrance in our process, which might have been because of us being too ambitious, having lots of ideas and too many directions to go in. I would assume that this is the reason to why it felt natural to talk more about how we got there, then what we actually ended up with. 

We began our presentations by brining up the insights we found during methods II, where it all started, followed by our HMW statement. The idea was then to shortly present our final concept, just a simple video that would function as some sort of teaser. “This is what we ended up with, wanna hear more about it and how we came to this: follow along”. Although, it wasn’t really interpreted by the audience in the way we intended. There was too little explanation surrounding PaySwipe which left the audience uncertain throughout the presentation about what we had actually created. We should have dedicated more time talking about the concept instead of moving on with the process. 

The app is all about the swiping motion. Dragging the money from myself towards the terminal/cashier/store is a focal point. One idea we received during feedback was that it would’ve been fun to make the audience try it out themselves. It would not only have been helpful in trying to convey the purpose of the app but also made our presentation stand out a little. 

One of the things brought up during feedback was questions towards the creation of this app. What is the intent or purpose of PaySwipe? I already have an app where I swipe to pay, but instead I swipe in a horizontal direction instead of vertical. To be frank, I understand what they are saying. But it might be more valuable to our target audience. People who struggle with abstractness within personal economy. It is not meant for everyone which is also why it cannot be understood by everyone. Yet, I also know that many of us are completely new to the field of design. These ways of thinking, of approaching a problem, of findings ways to ‘solve’ that problem are fairly unfamiliar to us. It is a learning process. And it is through experience and guidance that we will (hopefully) develop confidence and knowledge on how to tackle these situations. The view I had on prototyping before starting this course is completely different to how I view it now. I have learned things about the practice as a whole but also discovered new things about myself, which I will forever value. 

Further takeaways:

Showing the product/idea/concept on the final slide of the presentation instead of a text that says: thank you for listening. In this way the audience it gives the audience something to think about even after the presentation has ended as well as something to refer to when bringing up questions/feedback.  

[ievb]

Essay brainstorming snapshot

[ievb]

finalising the presentation.

friday 18/3

To work on a presentation with six people is tricky. We all have our own thoughts about what we should bring up, and what not. Diving back into our journals and the miro board has been very helpful. Seeing when we did the different activities and in what order. Personally, the most important things to bring up during the presentation are how and why we ended up here. Briefly mentioning the define stage of the double diamond and focusing on the deliver phase. 

We decided to begin the presentation by showing the insights from the methods II course followed by our HMW statement. In this way we inform our audience about what we have been trying to explore and learn more about during these nine weeks. Hopefully resulting in finding an answer to our statement. Instead of directly jumping into the beginning of the process we found it a better idea to show what we came up with. Not yet going into detail but in a minimalistic way showing our idea. We didn’t want the audience to have to wait until the end of the presentation to show what we came up with. Capturing their interest right away with this small teaser. “To hear more about it, and how we got there, why don’t you follow along?” 

We chose to divide the presentation into six parts, so that each one of us gets to present. Since some of us had preferences in which slides they wanted to talk about the line-up gets a bit jumpy. Although, everyone in the team feeling comfortable is very important. I assume that everyone wanted to talk during the presentation since we all wanted to show that we are involved. Yet, looking at how we chose to divide the presentation it might have been better if we chose only 2 or 3 people to present. All six of us standing up there and jumping in now and then might be a bit much. I see everything as a learning experience. If it doesn’t work out now then I’ll keep that in mind for the next time we have to present in groups. 

[ievb]

users and designers.

thursday 17/3

Some of the activities today: 

Refining and finalising the Figma wireframes.

Filming the concept video.

Presentation preparations.

We have explored with different versions of interfaces. Feedforward and the thrown objects behaviour were the main points for exploration. During the user testings participants followed the prompts written (feedforward) and there was not much uncertainty. They all understood what ‘had to be done’. The swiping motion is quite familiar to a lot of people today, yet it being associated or performed while making a payment might be or feel unknown to the participant. 

During the latest user testing the participant mentioned the swiping movement contributed to them feeling more in control. I find it interesting to reflect on since I can’t really wrap my head around it. For me, taking out my card from my wallet and placing it on the card reader is something I choose to do. It is in my control. Equally as much as swiping one object from one place to another. The participant said that they felt like they had more of a say this time around. The optimal follow up question would be, can you try to explain why you feel that way? Unfortunately we did not get to asking this. Maybe it all went a bit too fast and we had no time to actually reflect in the moment on what had been said. But I want to continue on this train of thought, although in a hypothetical manner. Let’s say (hypothetically) that the participant had said: well it’s just a feeling, I can’t really explain it. An answer that would not be unexpected. Describing or explaining feelings is not an easy task, and then for someone else to make sense of them (understand) is also not effortless.  We will not reach the same level of understanding if we cannot identify ourselves in their way of thinking. Therefore, accepting that we will only be able to understand the user to a certain extent is important. Unless we are users ourselves there will always be a gap between us and them. We can only aim to narrow that gap as much as possible. 

The figma wireframes: 

[ievb]

what feedback do we listen to, and what not?

Yesterday we did one round of user testing. While ‘observing’ the participant and hearing them think aloud I noticed the participant went in a different ‘route’ then we were expecting. Just as before we had introduced the scenario, paying for an item at a grocery store, yet the experience took a different turn. The participant started visualising our prototype in a different setting and spoke about non-existing functionalities the prototype had. During the user testing I couldn’t help but wonder what we would do with this kind of feedback. The imaginative and explorative way of thinking would have been interesting at the starting phase of the concept. We are now making final refinements, not quite seeking major adaptions of the concept. I also don’t see that we are permitted to interfere and in someway ‘set the user straight’. Like, this is what the prototype is meant to do and this is the environment it will be placed. This is simply their experience, it could be a result of misinterpreted or us not providing clear context. Sometimes this will be the case, not every user testing can go as we expected.

[ievb]

"What I hear I forget. What I see, I remember. What I do, I understand!"

Lao Tse

Buchenau, M., & Suri, J. F. (2000, August). Experience prototyping. In Proceedings of the 3rd conference on Designing interactive systems: processes, practices, methods, and techniques (pp. 424-433).

https://courses.ischool.berkeley.edu/i290-13/07readings/p424-buchenau.pdf

[ievb]

entering the final week.

tuesday 15/3

We started the day by discussing everything we needed to accomplish this week. During the previous week we conducted a lot of user testing, and adapted our lo-fi prototype in-between. Alongside, the other half of the group worked on developing high-fidelity wireframes in Figma. We did one round of user testing today (with the figma wireframes), continued working on the presentation and made a storyboard for the new concept video we are filming. Since we are entering the ‘last week’ of the project it is now time to focus on making final refinements and ‘knyta ihop säcken’ as we say in Swedish. Basically, connecting the dots, pulling everything together or closing the loop. 

Looking back I cannot believe how fast it has all gone, it feels like nine weeks just flew by. Even if numerous days have felt endless and draining it has all been a worthwhile experience. I have throughout the course browsed some articles online that talk about prototyping and design in general. And a lot of them can’t really seem to explain these topics in a clear way. They claim that to fully understand or grasp these topics you need to experience them. Explaining or telling someone about these topics can only get you so far. Both design and prototyping extremely broad, and they apply to so many things. Design is everywhere, which implies to some extent that prototyping is as well. The best way to therefore establish a perception on these things is though experiencing them. And that we have certainly done. 

[ievb]

‘pulling the strings’

[ievb]

our role during user testing

thursday 10/3

The insights we received from todays user testing were very helpful. We provided the same context and displayed the same scenario as the one we conducted yesterday. Throughout the day we adapted both the prototype and the questions after discussing the feedback within the group. If we gathered that the user didn’t really understand the question caused by our formulation, we adapted. 

I think it’s hard to figure out where we as observers/interviewers ‘cross the line’. How much can we interfere? I don’t want to put words into their mouth or lead them in any direction. But having no guidance at all can leave the participant confused or lost. We don’t want to end up explaining the whole idea behind the concept to make sure they ‘get it’. As if we were to persuade them into liking it. Although, I can’t hide the fact that I cheer a bit on the inside when they confirm what we have been wanting to establish. With that said, ‘failure’ or ‘success’ of the prototype is equally important for design exploration and evaluation. 

Users are not designers. But who do we turn to when we don’t know what’s the better option? Is this just something we experience as people who are very new to the field of design? We don’t have enough experience, knowledge or confidence to make these decisions? What if it is a question about personal preference? And it isn’t up for us to decide. Or is it? I don’t think twice when I choose a background color for an application. Yet when we need to decide what object should be thrown in our application we consider that choice to not be ours. 

[ievb]

9/3

wednesday 9/3

We started the day with creating low fidelity wireframes. Since the concept had ‘only’ been tested on a bigger surface (whiteboard) we wanted to find out how users experienced or interacted with the concept but instead on a smaller surface. By doing so we are also able to create a very ‘real’ scenario since the user is able to move or behave as ‘intended’. The goal of the testing, which is making a payment, is harder to accomplish/visualise/experience when using a whiteboard. 

We discussed prototyping the wireframes either by hand or using an application like Figma. I rooted for trying out the simple, lo-fi wireframes since that translates the questions we are asking ourselves the best. We are curious about the movement on a smaller screen. How will it be perceived? How does it feel? How do they behave? etc. We are not aiming to find out what color combinations work best. The questions we have should guide what we prototype. Also, paper prototypes are easy to produce. We can conveniently iterate and make different versions in between user testings. Therefore, speeding up the process. This is very helpful in our case since we are a bit behind in the process. 

We conducted one user testing. As before we had prepared questions and context (setting the scene). How did the swiping motion make you feel in relation to making a purchase? Does this app better convey the sense of exchanging money in a transaction? are two examples of the questions we asked. The participant mentioned that they found it a fun experience. They said that there was a higher volume of interaction during this type of payment compared to the existing card we use today. In a sense you need to ‘do more’ or be ‘more active’. 

Sketches of ideas/thoughts:

[ievb]

8/3

tuesday 8/3

Activities: 

Each mini-group presented our results from user testings.

Chose one prototype to continue with.

Ideated on the prototype.

Set up a plan for the rest of the week.

It was an intense day. We managed to get a lot done. It was nice that we narrowed down the concepts/ideas/prototypes to only one. Since we are such a big group and we are bit behind in the process we chose to split up again. One team will work on user testing the adapted and refined prototype whilst the other will develop a clear strategy/plan and organise the timeline, basically structuring since everyone is a bit all over the place now. Making sure everything we think/feel/say/do can be found in writing as well. 

This entire course/process has been quite overwhelming for me. The feeling I have right now is that I can’t wait to just absorb again. I want to listen and learn. And I know that we are learning by doing right now. Which I find effective, it’s just that there are so many things lingering (supervision, reflecting, doing research, producing, planning). Since there is so much going on or to think about I feel like I’m losing the actual learning part. I have really enjoyed the lectures and literature provided during this course. Yet I feel like I have had to push them back a bit since the group project has taken so much time and energy. And I know that we are supposed to incorporate everything together, but I have not really managed to do so. And I guess that’s on me, that’s something I need to work on. After all it is a learning process, and I have noticed that I’m not only learning things about the topic of the course but also about myself. 

[ievb]

some more thoughts on user testing.

The biggest difference between this user testing and the previous one was that we created a script. We wrote an introduction where we ‘set the scene and presented the goal for the user’. This was our introduction for both user testings:

You are buying a cinnamon bun and a cup of coffee and using your card for the purchase. The object you have in front of you is a card terminal. To pay you have to squeeze the card terminal until it reaches the total amount. Step one is squeezing the terminal, step two is blipping your card. 

To help the user visualise the prototypes environment we set up a simple scenario, buying fika. We then went on to explain what they have in front of them and how to use it. After they had performed the interaction we went on to ask them some questions. Some of these questions were: What was your experience?, What did you think about the squeezing?, Did it feel natural or logical to you? etc. 

It was comforting to have this prepared. I felt that these users were well informed before starting the actual interaction, instead of missing to communicate information. Instead of audio recording the participants we wrote down notes. And something i noticed which made it a bit difficult was that we were all taking notes. I ended up asking questions as well as taking notes. I could sense the participants ‘waiting’ for the next question while I was writing down their answer. Which made me a bit stressed and hindered me from maybe writing down exactly everything they said. In hindsight, I think it would’ve been better if we had split up these roles among us. One or two people taking notes whilst the other asks the prepared questions.

This technique is more demanding compared to audio/video recording. You need to multitask. If you instead record the testing you can sort of let it go, since ‘someone else’ is doing that work for you. Both techniques have their strengths vs weaknesses. I imagine taking notes is something you have to do a lot in order to get good at it. Practice makes perfect I guess, to a certain extent. 

[ievb]

squeeze

monday 7/3

The goal for today was for each mini group to finish their user testing so that we could present the results to each other tomorrow. We are a bit behind in the process, which I find a little troublesome. Within these sub-group we are exploring different ideas. We are opening up the field again instead of narrowing it down and refining one idea. I guess why it has turned out this way is because the idea we presented in the concept video was not something we had thought long and hard about. During ideation we had so many ways we could go and we didn’t have a single idea that ‘outshined’ all of the other. By setting up requirements we managed to narrow down our ideas or concepts. Yet the one we ended up choosing was a fairly new idea. 

After we handed in the concept video, conducted one round of user testing and received feedback during supervision the group had divided opinions. Both regarding how we should proceed but also what we should proceed with. We all found it hard to see where the current concept could go. This led to a small round of testing different ideas, whilst still focusing on ‘resistance’ or ‘friction’.

The mini group I was a part of had already finished the prototyping and user testing the previous week. And since we couldn’t really move on in the project before everyone else had done so as well we chose to help our team-mates. We joined them today in the design lab to finalise their prototypes and do some user testing. 

So this idea is an adaptation or evolvement of the lemon squeeze terminal. To pay you have to squeeze the card terminal until it reaches the total amount. So you start off with 0kr and then squeeze until you have reached the amount you ‘owe’. 

Link to video

https://www.youtube.com/watch?v=M6gFwitBFlY

[ievb]

a quick visit to the design lab

friday 4/3

Since we finished our prototype and done some user testing in our little group, I joined another group member in the design lab during the afternoon. She worked on the idea of the squeezable terminal. You accept the purchase by squeezing the terminal. She used some styrofoam to create the card reader. And used some sort of plaster-like material to wrap it in. Because we are only doing a ‘small’ round of user testing with different ideas, there is not that much time to create high-fidelity prototypes. With the design lab staff we discussed some materials we could use for future prototypes, when a greater fidelity might be needed. For example, using the vacuum press to create a sleek design.I also got to help some of the other groups by participating in their user testing. It was fun to see what everyone has been up to. I have been so focused on our own process so it was very welcomed to be occupied with something else. It has been a while since I have been in the lab and it felt good to be back. You get inspired even if you are not here to initially create. 

[ievb]

some thoughts about the user testing

So what ‘technique’ or ‘method’ did we end up choosing? Let’s just say we went with a combination of the previous mentioned ones, observation and think aloud. We had not written a script and sort of went with the flow. There are both pros and cons with this. Something positive with jumping in to it very freely is that you need to reflect on what is happening whilst it is happening. Focus on the interaction is necessary. When following a script there is a possibility of getting lost in it, and not noticing details of the interaction. Something I noticed during the testing, caused by this kind of improvisation, is that we missed to convey certain information. For example, during both testings we forgot to mention that the card will vibrate when we were ‘setting the stage’. Quite crucial information that can affect how the testing is going to be carried out. Another consequence with not having clear guidelines was that participants got confused. One participant even asked during the testing if they were supposed to think aloud or not. That alone speaks volumes. Overall I would state that there was a lack of communication and preparation regarding this user testing. 

Even though we had some difficulties here and there we got some very interesting and useful insights. There were mixed feelings towards the vibrations, mostly dependant on the intensity. Both participants mentioned that the vibrations that occurred during the lower purchases felt ‘nice’. They said that for people who have impaired hearing or use headphones it can be good to receive that kind of feedback. Considered as an additional confirmation that the purchase was successful. One participant voiced that the largest vibration (occurring during the biggest purchase) almost felt negative. The purchase felt like a ‘big life decision’ and that they are already aware that it’s putting a dent in their economy. Feeling that they did something wrong even. 

I guess the ‘issue’ with the intensifying vibration during this user testing is that WE decided what is considered a small/big purchase. And when thinking about it, how do WE decide what is considered a big purchase when it’s not our money we are spending. Leaving the user in control of those settings can be interesting to explore. Somebody might want a small vibration with every purchase, just as an additional confirmation. While someone else might want a more intense vibration because they are a lousy or big spender and wants to be reminded/aware/told? 

Regarding future user testings I think there definitely is some room for improvement. I would like to dedicate some more time towards preparation. Knowing exactly what the intentions with the testings are and perhaps writing a script for introduction and questions. 

[ievb]

user testing

thursday 3/3 

Today we did some user testing. We wanted to create a more realistic looking and feeling card, so we used two real cards instead. The card was still thick but we could simply not escape that at this moment, we needed to watch in between to establish the vibration.

We then shortly discussed the ‘method’ we were going to use. I had the evening before revisited the powerpoint from the lecture on user testing. There were many different ‘techniques’ we could choose. Both observation and think aloud spoke to me in the sense that they focus on setting the scene and asking the participant to reach for a goal. We inform them about the setting, which is that they are in a store and the goal is to make a purchase with the given card. 

We introduced three different locations during the testing. A coffee shop, grocery store and a tech store. The distinction between the stores was the amount of purchase. The lowest amount was at the coffee shop and the biggest was at the tech store. The vibrations had a connection to the amount, increasing in intensity when the amount goes up. 

It was really fun to see that the participants brought up aspects of the interaction that we had not even considered. Even though the testings were a bit shaky at times we managed to collect some very useful insights. 

Heyer, C. (2022). User Testing [PowerPoint slides]. School of Arts and Communication, Malmö University. https://mau.se/canvas/

[ievb]

building the prototype

wednesday 2/3

The smaller group I am a part of a the moment met up in the morning to start building our prototype. Each one of us had brought random stuff from home to create the sensory function (vibration). One of us was able to bring a music beat measuring watch. I am pretty sure that’s not the name of the actual thing, but it describes it best. Something that was extremely helpful was that the watch could be controlled through a phone, giving us the opportunity to create a very realistic scenario. We did not have to interfere during the interaction to make It behave the way we wanted to. We could just do it behind the scenes, very wizard of oz like. 

We wanted to create a very simple scenario, focusing solely on the experience of the vibration. We placed the case of the watch inside a card we built. The card consisted of paper and cardboard, we designed it be realistic looking. Then out of cardboard and a phone we created a card reader, displaying a picture on the phone. 

After we had constructed the simple prototype we tried it out ourselves. It’s hard to explain how I felt when the card buzzed. It sort of felt like someone tappin on my shoulder, asking for my attention. We explored four different vibrations:

Picking up the card, vibrating 3x times in a sequence.

Small, medium and big purchase, the vibration intensifying in strength depending on size of purchase. 

The higher the vibration the more ‘urgent’ it felt. 

Video of prototype

https://www.youtube.com/watch?v=Z8vvm8ndHCw