Product design process for #startup

While reading About Faces 3 by Alan Cooper, Robert Reimann, and Dave Cronin i began reflecting the information over the startup community.
The processes you get exposed to in the book, though aimed to the Interaction Designer / Information Architect, seem to be very useful to any product design process and seem to be very focusing when it comes to designing products from the ground up, as it is usually done with a startup.
Looking around the web for a one pager / cheat sheet of the books essence i drew a blank. there is a big void when it comes to interaction design.
So i will do my best to get this books essence in the shortest form i can to give the startup community a great guide for product design that requires less than the 600 pages in the book.
This will not replace reading the book if you want to get to the full depth of the interaction design, but it will be handy when you are limited on time and funds and want to get your product focused.
The book bundles together a few processes to create an aspiring for completeness process for creating a product.
When we think of a business about to create a product we let our thought roam in the realms of features/activities and functionality and in the look and feel of the product thinking about our users.
The reality is that we are not doing this in a methodological way and tend to try our luck more then fine tune the product before launch.
Most of us still approach the design of interfaces by asking, “What are the tasks?”.
The books takes us through the following processes

1. Goal-Directed Design
2. Implementation Models and Mental Models
3. Understanding Users
4. Modelling Users
5. Scenarios and Requirements
6. Framework and Refinement

I will try now to skim off the top of each of these and make some sense at the end.
Lets go

Goal-Directed Design
The first principle here is the Goals are not tasks, they are the end goals that the tasks lead to, the motivation for getting tasks done.
The main goal of a user is not to look stupid, keep that as one of the basic principles when you think of all the interaction of the user while using the system.
Most it products tend to:

• Make users feel stupid
• Cause users to make big mistakes
• Slow users down hampering performance
• Prevent fun and/or bore users

but how do we know what are the users goals?
User goals are not like tasks they change slowly, tasks and activities change often and relevant to context.
The way to find what are the goals are to do qualitative research understanding Why a user is performing the activity.

Goals will help later in the process to better understand the users as we model them into personas.
Implementation Model vs. Mental Model, You know how we always cry over software UI that it was “Developed by Developers”? a software like that was developed using the implementation model, thinking over the features from the developers perspective.
Mental model on the other hand is how a user perceive the experience, taking the car acceleration pedal for instance. the user needs to know nothing about the ignition or air intake to understand that pressing harder against the pedal will bring the car to higher speed, this is the mental model of the pedal.
Your users are one of these 3 groups

1. Beginners
2. Intermediate
3. Advanced

The biggest group out of the three is group 2, the intermediates, most beginners turn intermediate quickly and most of them stay like that and never get to the expert group they stay perpetual intermediates.
One thing to remember here is that users don’t use the product in a frequent thus forget how some of the knowledge they accumulated.
Software UI needs to cater to the biggest group while not harming the other group’s usability.
I recommend reading this section in the book (pages 42-48) as it is one of the toughest points you will have to deal with while designing the product.

Now the book goes into understanding the users where qualitative research is to be done to establish Personas and Goals.
The research that is described in the section requires the following:

• Stakeholder interviews
• Subject matter expert (SME) interviews
• User and customer interviews
• User observation/ethnographic field studies
• Literature review
• Product/prototype and competitive audits

When trying to create the initial product in a startup we do not have the means to facilitate such a research and thus will need to create some alternative method in order to acheive partial Personas and Goals.
Some simple solutions will be to look at the competition and find out who of our friends/family/coworkers is using it, observer them and interview them.
If there are no competitors in the space we might be able to get some information from the same people while asking them to imagine the software.

When asking questions about a desired product use the guidance “Imaging that the software is magic” this will get you some ineresting responses.

If we have non of these we can try imagining what are users will be and give them qualities, we can use persona cards like organizational zoo to focus you on the type of persona’s and their associated behavioral attributes.

When approaching the personas definition (hypothesis) ask the following questions

• What different sorts of people might use this product?
• How might their needs and behaviors vary?
• What ranges of behavior and types of environments need to be explored?

When thinking about a persona we need to cover all aspects of the product usage.
Its nice when entering content is smooth and easy to a first grader but when the IT guy needs to create an export of that content and make it available to in the new upgrdaded environment we need to think of him too. He is a persona using the product.
In order to differentiate the Content Editor from an IT administrator we need to specify roles in the system usage. a role is constructed from a given number of tasks needed to be completed successfully with the system

Up to now we have a very flat persona with a Role and some character specifications but we need the persona to get some depth,
The depth of the usage is what we are more interested in as oppose to the theological thought that user might have, though they can indicate user behaviour.

The 3 measurement vectors are Frequency, Desire and Motivation.
Frequency represents the users frequency in usage of the feature.
Desire represent the will to do tha action.
Motivation is the reason behind the action, this could potentially be nowhere near the actions result.

So now you know more about the persona and its goals for some of the usage of the system.

From here the book will go into the methods of research which is valuble in the standard company improving product scanario, but has less relation to a startup before the first alfa, you can purchase the book by then with some funding on the table.

image curtesy of Design and Technology student