Over the years, I have witnessed the change in how I approach any design problem. And create design explorations for the problem.
The change could be credited to factors like new tools being available, understanding the deeper sense of design, adding more granularity to the design deliverables, interconnecting the relationships between different variables, etc. This is an ongoing process and the learning never stops :).
There are different ways to start off and design for any context. End to end user experience design lifecycle is expressed in different forms by different design agencies – the sub processes change a bit, but the essence remains the same. On a high level, any user experience design project will fall into four distinct buckets – (a) requirements understanding (b) conceptualization (c) prototyping (d) implementation / deliver.
Paper prototyping falls into activity (c). Some might be inclined to slot into (b) as well, its acceptable. May be it falls in both areas. Purists will never stop arguing, pragmatists will get the paper, sketch it out and pitch the design :).
I have used paper prototyping technique most of the times in presales process. It helped me a lot. While I do this step in the detailed design activity (low and high fidelity prototyping), it’s the pre-sales paper prototypes that have garnered the customer ‘wow’. Once you go past that stage and enter the delivery cycle, wow is replaced by ‘now’ (“I want this to be designed now”). Nevertheless, paper prototypes will never let you down.
So how does one go about designing the paper prototypes?
Here’s a 4-step approach.
Step 1) Understand the ecosystem
Get answers to these questions – Who is the real user of the product / service? What are the dependencies? What is the overall goal? What are the controllable and uncontrollable variables involved? Who are the stakeholders? What are the different business processes?
Once you get the answers, be as visual as you can. Create mind-maps, information graphics or any other graphical form that expresses “the big picture”. Yes, the big picture.
Step 2) Create the information architecture
Understand the different “information buckets”, the hierarchy of information and create information architecture. Some might be comfortable to see and depict the relationships among data, which serves well too.
Information architecture will help you understand the length and depth of the information the product / service holds. Having information architecture ready is like having a blueprint ready of your product.
Step 3) Create the user task matrix
Write down these questions – How many times a user is going to perform a specific task? What is the input user needs to perform this task? Will the product / service break down if the user does not do the task? What are the dependencies of this task with other tasks?
Some designers might consider skipping this step and creating “task flow” – its perfectly fine. The idea is to understand the nuances of user tasks – who does it, when and how.
Step 4) Understand the target device considerations
Is it an iPhone app? Or an enterprise dashboard seen on a tablet? A good-old fashioned desktop application used by legacy users whose keyboards squeak every time they press any key?
Of course, connect this point with real-life usage context too. E.g. this is a point-of-sales application to be used by a sales agent in a crowded grocery store on a monitor with screen resolution 640×480.
You are welcome to add your steps in between or skip some of these steps. Whatever works for you, works better. These 4 steps have worked for me, so far. And as I said earlier, I may refine these steps as I learn new things down the line.
We will expand these 4 steps in coming posts.
Paper prototypes for everyday design 