Learnings from Interface Prototyping workshop = a lot of learnings mean a lot of text :)

This is going to be the learning diary of the “Interface Prototyping” workshop that I took in school last week.
We focussed on lofi-prototypes, which was very good for different reasons: (1) some hands on tasks and a lot of stuff we got done in just one week, (2) the awesomeness of drawing things by hand came back to my mind and (3) I finally learned different methods at least a bit more academically, though it was very hands on. I found it pretty crazy that a lot of things we do quite naturally, without even thinking about it, but when we should explain them to others it gets really hard and complicated.

So let’s go a bit more into detail on the different days:

DAY 1: WIZARD OF OZ-PROTOTYPING

The first day started with a lecture that summarized quite many things I somehow new but I wasn’t consciously aware of. Just one example here: the difference of Hifi and Lofi protos:

HiFi
realistic
presentable
no big step to implementation

LoFi
quick
easy to change
more iterations in testing easily possible
obviously not final > focus on navigation, functionality

Then we continued with something I’ve been looking for for a while but didn’t really find good books to get into: User test tasks and how can you make good test tasks?
– direct wording (NO: “you would like to” BUT INSTEAD “you do”) > clearly defined task
– keep them short
– give paper strips with all details to the test users
– test tasks should be read out loud
– primer with introduction, situation, setting is possible
– use understandable language
– avoid UI words (also don’t use the exact words you have on the interface. That would make it unrealisticly easy.)
– don’t reveal the steps to achieve the goal
– focus on tasks and goals
– start and end easy (for good feeling; that’s common practice)
– don’t number the tasks so you can shuffle them later and the test user doesn’t notice if you skip one
– think about the order of tasks: is there a learning effect?
– where do you start? always with same screen?

I think this was actually one of the most useful things for me. It is going to be super important for my Master thesis project. (Actually user testing and interviewing is one of the main parts of the thesis).

So then we started the first task:  Using the Wizard of Oz method we developed and tested a Call service for Car booking. We were a project group of 4 (Jarl, Nina, Noora and me) and started right away by deciding what kind of car booking service we wanted to design: “Awesome Cars” was a service operating in capitals in Europe where one could book a car via phone call. Making this decision from the very beginning we limited the numbers of choices for pick up and return locations quite much. Then we immediately started on designing the flow chart diagram, where we first went quite straight forward like this: short intro; choose where to pick up the car (city and then 3 available options within the city; those were airport, main train station, city center); choose pick-up date; choose car type; choose drop-off location (city and then those same available options within the city); choose drop-off date; get information on price and summary of booking; confirm the booking and it’s done! A bit later we added an option if the user inputs some wrong information (e.g., city that was not a capital) and added a confirmation after each step. That was to make the user feel safer that the system actually catches the right information already during the process and not just in the end.
I was mostly involved in the development of the Flow chart with Noora, whereas Jarl and Nina were thinking more about the test tasks for the users.
Lastly we did user testing with about 5 users, some people from our class but also from outsiders. It was easy to notice that people who had basically no idea of what we were doing needed a lot more explanation before starting the actual user testing. I mostly liked being the “computer” (that means simulating I’d just follow the flow chart, being the synthetic voice of the system), although that can be really hard, especially using this Wizard of Oz method.
In the user testing on the first day I also learned to pay more attention to my (bad) habits when being in this kind of test situation (especially as a test leader). Also it was quite impressive how much we achieved within just a couple of ours (although those really were very intense).

We ended the day with tips on how to behave during the tests:
– clear articulation
– avoid unintentional help (things like “hm”, nodding,…)
– avoid hassle/be prepared for your test users
– being a computer can be tricky (memory problem, human computer is really slow)
– think about test setup (environment)
– outsiders are better for testing (but need more detailed explanation)
– interview afterwards should be prepared (semi-structured interview)
– give users the opportunity to ask questions

Also some notes on voice-based services:
– temporal information > slow input; needs to be remembered
– 7 +/- 2 is the maximum number of items remembered by human brain > give them max 5 options, better even less
– tell action first, number than (we did that wrong…)
– use the imperative (give straight options, no “might be”s)
– politeness, tone, nature of voice (male-female, young-old) also depends on culture

DAY 2: FIRST PAPER-PROTOTYPE

In the beginning of the second day we talked a bit about the mediated communication and the challenges appearing from that. Then I learned a new thing about testing: There is a difference between horizontal and vertical testing:
Horizontal testing is used to get an overview and see if the top level navigation works.
Vertical testing is used to test one particular functionality.
Those are more 2 ways of thinking about testing than actual opposites. So they are mostly used in combination.
Also something to be aware of: Don’t expect to test everything. You and your test users do have time limits. (That means you can also design a concept/service for testing and don’t need to prototype everything.)

Here is a short overview about different LoFi-prototyping methods: (+ for positive points; – vor negative points; * for explanations/neutral points)
Wizard of Oz:
+ go around technical constraints
+ for voice services or gestural interfaces /wherever a human computer can easily detect things)
+ can already regard many ideas
– e.g. for web interfaces
Paper-Prototype:
+ quick
+ easy to modify
– slow computer
– interactivity might be hard to simulate (highly interactive systems)
– not real (no real fonts,…)
+ test the wording
+ test navigation/structure
* best suited for 2D/page like interfaces
* roles: computer, test leader/facilitator, observer
– some features are hard to immitate: pop-up-menus, mouseover, scrolling (although I don’t think this is that hard), animation, right click, progressive tasks, photo taking,…

Wireframes:
* rough content and layout
* designer’s tool
– might be hard to use as communication material for customers (they don’t understand it the placeholders…)
Storyboarding:
+ movies
+ multiple uses
+ communicating ideas/what a service is about
+ make scenarios more tangible
– no interactive features

HiFi methods:
* mockups
* Flash, Visual Basic, Excel, Powerpoint, Indesign,…
+ work towards the final product
+ realistic results
+/- focus on details
– more work (so mainly: use HiFi after LoFi)

After this lecture part we started doing our own paper-prototype. This was quite a fun assignment. On Tuesday we worked in a new group (Fabian, Nina, Noora, me) developing a “little Facebook”-like social networking application. We immediately started thinking about how the service could look like and how we could make it more than just a “simple” social network, but something that we would want to use. We ended up with “Kopla”, a web-based group work management service for Aalto people. The idea developed quite quickly, we knew we did not want to make some “normal”-looking service but try something new, when Noora started drawing bubbles. I think this was the actual breakthrough point of the whole project and we decided together that we want to explore how the bubbles/circles can be used in interfaces. While developing the prototype Noora and I focussed on the visual paper prototype whereas Nina and Fabian worked on the Flow chart and the test tasks.
When conducting the user tests we changed roles. I still felt most comfortable being the computer, I guess this is just the perfect role for me (?). However, I also tried to improve myself in being a test leader/facilitator.
Also seeing people actively trying to think aloud when they were our test users was quite revealing. Some people had easy times telling us what they are confused about and what they see in the interface, some just focussed on the buttons they are pressing (well, we could see that ourselves). So it showed that it’s not an easy task being a test leader when the think aloud method is applied.
I think the main learning during the day was seing how much fun it was to make this paper prototype in the first place. Also Noora and I thought quite a bit about color coding of different things (using available copics).
We also tried to take user’s suggestions during the tests into account and took notes on how the service could be developed further, especially as during the testing we started realizing that Kopla has many opportunities. All in all the feedback to our first “kindergarden”-like (colorful) prototype were quite positive and other people also encouraged us to continue working with the idea. And so we did (see day 3-5)…

 

DAY 3: SECOND PAPER-PROTOTYPE OF KOPLA

On the next day we decided to continue working on the same service, but made a new prototype (also in a new group again: Jarl, Noora, me). When we started the work on this prototype we first explained the idea in more detail to Jarl, who had not worked on the service the day before. This was revealing in the sense that we noticed we had established some vocabulary to talk about certain things (bubbles, circles, …) rather unconsciously. Also Noora and I tried to wrap up our test experiences from the day before so we could use the first user test results already for our next design. Those changes were mostly about labelling of certain things (e.g., “all projects” became “public projects”). We actually had a long discussion about labelling. Then we also decided we wanted to focus a bit more on how the “projects” would work, how they would be added, shared, and what other functionalities they needed. We didn’t prototype this completely but started with some key features.
Noora and I mainly took care of making the bubbles when Jarl was formulating the test tasks. I continued late on wednesday evening to finnish the whole prototype, also filling in some content into the pages and so on. I see the second paper prototype production-wise as “my baby”.

DAY 4: USER TESTING

In the morning of the Thursday we did final preparations on our prototype, changed the test tasks a little and prepared the test setup (room, camera,…).
We had already decided that Jarl is a good test leader, I was the computer again and Noora took care of taking notes and video recording the user tests. We tried to keep the desk where the user testing was happening as clean as possible. I also tried to operate as a computer partly under the table so that the test user wouldn’t see what would be happening next. I think this was quite valuable since all test users focussed on the paper prototype active at this particular moment without being distracted by other things in the environment.
Another important choice was to have the camera filming over the shoulder of the test user. We have not asked all the users but at least 2 told us that they forgot about the camera completely during the test. This obviously does facilitate a rather relaxed feeling than putting the test user in a stressful situation (although at least one user was obviously quite stressed). Also I think it was quite good that Noora was standing behind the user so they didn’t notice her too much. She was taking her notes on sticky notes so it was more easy to sort them out after the tests.
We had initially quite some problems finding test users, but we finally managed to find 4 test users, out of which 2 where from Media Lab, 1 was from School of Engineering/Computer Science and 1 from Graphic Design. That was a quite good mix of users quite comfortable with computers and others not so used to use more complex websites.
During the user tests we shuffled the test questions to some extend/as much as logically possible. Jarl did a short explanation on the service and the test settings before we started the tests. After being done with the last test task Jarl asked some questions we had planned beforehand. There was quite some discussion within the group on the order of those questions. They mainly referred to the ease of use, if the user would be interested in using a service like this in future, if they had suggestions for us, but also asked for the background of the users, how familiar they were with more complex websites and their age. I still think the order should have been differently but every test leader has his/her own style (at least to some extend) so it was Jarls final decision and did not influence the proceeding of the user testing at all. It’s just a personal preference…

DAY 5: EVALUATION AND FINAL PRESENTATION OF RESULTS

On the last day Jarl and I worked on the final presentation of the results. We had split the results according to the test tasks already on thursday after conducting the last test. So it was easy to just make them into one document (which I will link here). It is now missing our suggestions on how to improve the problems raised in the user tests. So that is definitely the most important issue missing.
Personally I have to say I had a lot of fun in evaluating and sorting our results. I think they are really valuable and good results for future work on the service (in case we do).
So as already implied: Jarl focussed on the visual presentation, I did the evaluation document (and Noora was unfortunately missing in the morning). And at the end of the day we had the final presentation of our prototype before we ended our workshop week in the very usual way: a beer in Kipsari…

 

Alltogether the Interface Prototyping Workshop was not just a lot of fun and hands-on work, I also learned a lot, had good discussions, really awesome group work (which is not  self-evident) and I am 100% sure: It will help me with future design projects. So overall: course highly recommended! (and this is not to make Markku happy, who will be the only one to read this course to the very end, ’cause it’s a course assignment)

I also made a checklist for user testing from everything learned during the week. This will be useful in future.