As a product manager, having a good overview of the product design process is essential so you can:
do the designers job get their asses firedAssist in proper personnel decisions.
- Know enough to ask smart questions.
Do you remember in school when the teacher told you there were no dumb questions?
Well, guess what, they meant when you were in grade 2, not in a product design meeting at work.
So, if you have some stupid question about the product design process, we are here to enlighten you (and save you from wearing the proverbial dunce cap at work).
Breaking Down The Product Design Process
- User research
- Information architecture
- Interaction design
- Visual design
- Content strategy
- Despite what you read on some blog or at the insistence of your boss/HR manager, do not expect anyone you hire to be excellent at each of the phases. In fact, if some in your HR department yammers on about only hiring “the top 1%” bullshit, you should add getting them fired to one of your annual objectives
- Life is a series of compromises (Trust us, we’ve seen what your spouse looks like, you seem to be familiar with compromise) and product designers are no exception to the laws of human nature.
- In a perfect world describe by books, you usually have a design team with different people specialized in each tactical element, or some combination of elements.
- In the world you actually live in, you need to learn how to improvise and make the most of what you have, so we hope to impart enough knowledge on you that you know how to roll with the punches.
When you read blogs, this one included, you might think that product management processes occur in an orderly serial fashion.
Reality presents much differently; in a best case scenario many product management processes occur in parallel fashion, (but most often in clusterfuck fashion) and different stages and functional areas of product management bleed into one another. User research is perfect example of this bleed.
Let me start off by dispelling any notion that as a product manager you will some how become an expert in user research, many of the professionals you work with in the area of user research will have advanced degrees in the subject. Your goal is to leverage their talent and not offend them with your ignorance.
The reality is that the beginning of the design process probably start when you are engaged in product hypothesis testing and working through the product roadmap process. and carries on through the product requirements gathering process.
User research is focused on understanding the customer, their needs and goals and what they do now to address those needs, in order to design a solution to their problem.
This means that product designers will often be involved with:
- Gathering information from customer surveys and interviews
- User testing once a prototype has been built to see how well the customer accomplishes key tasks using your prototype.
The purpose of information architecture/design is figuring out how to model and organize the data. It is more clear cut that information architecture is part of the product and solution stage of the product development.
IA attempts to answer the question of what information a user should see first, second, and so on by modeling how the product concepts should be presented to the customer.
The purpose of your IA is to help users:
- Find information and complete tasks.
- Understand where they are, what they’ve found, what’s around, and what to expect.
IA focuses on informing the content strategy through:
- Word choice
- User interface design
- Interaction design via the wireframing and prototyping processes.
- Organizing, structuring, and labeling content in an effective and sustainable way.
To do this, you need to understand how the pieces fit together within the system to create the larger picture. This is often visualized as a site map, which you can see below.
Successful information architecture requires a diverse understanding of industry standards for creating, storing, accessing and presenting information and includes the following main components :
- Organization Schemes and Structures: How you categorize and structure information
- Labeling Systems: How you represent information
- Navigation Systems: How users browse or move through information
- Search Systems: How users look for information
Information architecture addresses and understands the interdependent nature of
- Context: business goals, funding, politics, culture, technology, resources, constraints
- Content: content objectives, document and data types, volume, existing structure, governance and ownership
- Users: audience, tasks, needs, information-seeking behavior, experience
Interaction design involves figuring out how to take the information architecture and present it in the product.
This involves obsessing over:
- How users navigate through the product,
- What UI controls to use
- How many steps it takes to achieve commonly performed tasks.
At this point in the product design process, design starts to bleed into engineering to ensure that the desired interactions are technically feasible.
Out of the interaction design stage in the design process, you usually generate a series of wireframes; rough, block diagrams showing how users interact with your product
As a tool, they visualize where users find various pieces of information and how they navigate the product.
In the magical land I read about in product management books, design teams have prototyping experts who turn these static wireframes into interactive prototypes.
In reality, a few things could happen in the prototyping phase:
- Someone figured out how to iterate on the wireframes from the interaction design phase as they were build using InVision or Balsamiq, meaning the read the instruction manual and learn to make these things interactive prototypes
- You begged and pleaded with a developer to whip up a quick HTML prototype
- You put your own HTML/CSS skills together and did your own prototype
Why would you go to the trouble to do this?
- People have shitty imaginations, can’t visualize things and are lazy: Most people aren’t going to read the requirements document, so prototypes help everyone working on the product understand what is getting built.
- Helps engineering with estimates: In general, software engineering estimates suck but providing a working prototype “should” allow them to provide
less badmore accurate estimates for how long parts of the product will take to build and enable the team to make engineer/product trade offs to speed up product development.
- Prototypes help with usability testing.
Even at the crappiest smallest of start ups, this is a job that will not fall on a product manager’s head as visual designers need to know design stuff.
Visual design, which means figuring out how your product will look, is usually a parallel process with the wireframes and prototyping processes, as a certain amount of iteration is needed to make sure that readily accepted design standards have been accounted for and the product flows as it should.
The output of the visual design process are a set of high fidelity mock ups, that are pixel perfect representation of the desired product. These mock-ups are designed to help
- Gauge how the product comes together.
- Improve usability by ensuring the font large enough to read and the buttons large enough to tap accurately on a phone?
- Ensure consistent brand messaging.
- Provide the developers with exact specifications of what needs to be implemented. These mock ups specify font, spacing, color schemes, etc.
Once the high resolution mock ups have been approved, they head off to engineering along with the wireframes, prototype and product requirements document to start the development work.
While not a core of the product design process, consider using a content strategist to ensure you used consistent terminology and lexicon across your product and making sure your customers expectations are met.
Wrapping Up The Design Process
The core product design process is done when you, as product manager, have signed off on the prototypes, requirement documents and high fidelity mock-ups and engineering has accepted them.
You have now worked yourself out of a job…
No, that isn’t how it works.
After you hand all the designs over to Engineering, they will come back to you with questions they discovered as they have finally decided to read the product requirements. These questions include items like:
- How parts of the product should behave.
- Unanticipated edge cases that need to be accounted for.
- New wording needs, and
- Parts of the design that are problematic to implement.