Helloes, and thanks for last.
I promised I would write a post on prototyping on paper and in Axure, so here goes! I had a dream a few nights ago where my cat's legs were made out of jelly and that I ate them. It was very traumatic, so today I don't feel like being funny.
What have I been doing on the prototyping front? As mentioned, my main task is to look at the process of adding a new Tise. I started with looking at what people thought about the process of adding a Tise the way it is today. The feedback from this inspired me to come up with some paper mockups of my own.
Now why prototype on paper? Simply because it's quick and easy to iterate and change the errors you discover while testing it. To make the test as close to realistic as possible, I recommend implementing the mockup to be tested through a phone screen setup and not a computer screen. This is because people today are used to telephone screens, and observing them interacting with one gives you pretty good clues about when and where they would like the possibility to zoom in, a proceed-button, where they become unsure and so on. This, I suspect, is harder to observe when it's on plain paper.
From my experience, the trick is to make a mockup as early in the process as possible, instead of spending time on fancy drawings and functions. Don't make your first mockup your baby, you might have to kill it. Here's some photos of my first mockup.
The websites/softwares for making digital mockups I know about are balsamic, proto.io, uxpin, InVision and Axure. I ended up using Axure because I suspect we're going to use it at Industrial Design (my study) and also Axure has free student licenses. Although Axure has an interface from the early 1930s, it let's you do pretty much everything.
Axures pre-war look.
The problem with usability testing is that people are different, and therefore have different preferences and needs. Another problem is that few people know their brain good enough to articulate what their needs are. For example, before Snapchat, nobody really missed it. Now, we almost can't live without it. This is why I during a usability test have bigger focus on their body language and the movements they make than what they're actually saying. If I was to make a swiss knife, and asked 20 people what type of functions they wanted to be in it, I'd end up with a 2 square meter big collection of 20 gadgets. That's why you during a usability test have to try figure out why they're saying or doing what they're doing and saying, and not only what.
What I'm trying to say is that usability testing is all about getting input, and it's up to you as the developer to use the input in the best way. When you sit alone and work with your design, you might think that everyone will understand and like your solutions the way you do. With only one conversation with a testing user, you'll might discover things you should have, but didn't, think about.