The cheapest, fastest way to mock up your interfaces is with pen and paper. The creation process involves the whole team, and the unfinished feel means you’re less attached to any one idea.
Once you have created some product ideas using scenarios and sketched them out using the design charrette process, you’ll need to turn these ideas into designs.
Systematic design for minimum viable product
The charrette left you with some UI sketches. Now you have to build the full interface around these sketches and fill in all the intermediate screens so that you have a complete task flow.
The big rule here is to build only the interface elements needed to enable the scenario you wrote. That scenario described a solution to a problem you observed in the field. There’s no need to add the “what if” options, the bells and whistles. Sticking with just the core scenario helps you avoid feature creep and create the minimum viable product.
- Read through the scenario. Every time it refers to the user interacting with the product, note down the UI elements you will need.
- Your scenario probably doesn’t make explicit reference to UI elements, so look at each behavior and each outcome and decide what components would be necessary to make the interaction work in your interface.
- Create each UI element on a separate piece of paper. Better still, use card stock (index cards work well) because it’s easier to handle.
- Draw the text field, drop-down, button, icon, or whatever other control you need, then cut it out.
- Individual elements can be rearranged or removed without re-drawing everything. Your first layout is almost guaranteed to be wrong. Removable glue dots are brilliant for this task.
- Arrange the UI elements into screens
- Split the task into steps that make sense, and then create a screen around each step.
- Walk through the flow to check that it follows the scenario.
- Make sure you included all the little bits of interface, like pop-up messages or interstitial screens. If you don’t design these now, they won’t be so much designed as thrown together later in code.
Rule: No rulers
The paper prototypes that you create are supposed to look hand drawn. They are supposed to look unfinished. “Lorem Ipsum” might as well be Latin for “I haven’t written my content yet,” but with paper you don’t even need to put in text, just squiggles are sufficient to show that an area of the screen would contain content.
Your interfaces aren’t supposed to look pretty, they are supposed to be fast and functional. The only people who see them will be the team and some usability participants. They just have to be clear enough to get the ideas across. That doesn’t require a ruler.
Why not just do this in code?
You might be a super-fast coder. Maybe you think it would be just as easy to build this interface using your dev platform.
- Even with pairing, only two people can sensibly get involved in coding. That excludes the rest of the team. Many ideas for the interface will occur to you only when you start building it. That means the whole team needs to participate in the creation process.
- You’re going to be user testing this prototype. Study participants give different types of feedback to code than they do to paper prototypes. They will be more open and honest if they think there is still room to make big changes. A paper prototype makes it clear that you aren’t done yet.
- Showing participants a design with neat fonts, a clean color palette and icons from a matching set will lead them to critique those elements rather than the underlying interaction.
- Familiarity with your coding tools makes you less likely to consider unusual UI elements or different approaches to the problem. Getting back to basics forces you to build every control from scratch. That makes you more creative and more efficient in your design.
- If you hack together a prototype in code, you or some other person on the team may be tempted to use it as the basis for real code.
The same applies to tools like balsamiq and mockingbird. Both have a place in the design process, but although you could argue that these tools are as fast to use as paper, they don’t allow for the same level of spontaneity or team involvement.
What next?
Create a video walkthrough of the interface, narrating how it meets the desired outcome for your chosen persona. This (and the paper prototype pages themselves) become the documentation for your interface.
But don’t start coding it yet – first you want to verify that the design you think is so perfect actually resonates with the people you built it for. You are too close to the design to be impartial. You can get a fresh perspective by running some paper prototype user studies.