How To Avoid Design By Committee — Developing an effective product design process

All startup teams are filled with people who are passionate about the product, with strong opinions about how to best solve the customers’ problems. While their hearts are all in the right place, and the product could be designed in a multitude of ways, it must be developed in only one way. As a designer or product manager, you need to listen to their feedback, but ultimately decide on a final design. How can you create a cohesive user experience when everyone thinks it should be designed in a different way?

Developing an effective product design process starts with acknowledging some hard truths:

• There is no one right answer. Multiple people with conflicting opinions can all be right.
• You can A/B test forever, and never release anything. While everyone on your team is entitled to their opinion, you should not waste time testing every one. You must find a balance between going completely on your gut, and testing every possible variation.
• You can never truly know the right answer until the product is released in the wild. You can put wireframes and proofs of concept in front of beta users, but until the product is fully developed, you won’t know how it will behave as a wholistic experience.
• People are different. You are never going to solve the problem for every user. You cannot compromise your design by trying to account for every possible user mindset. You should instead focus on guiding people into your product mindset.
• The user voice always speaks the loudest. Everyone on your team is giving their opinion of how they think the user thinks or behaves. What the users actually tell you should trump all opinions in your organization. Gathering good user input is difficult, but critical. Surveys, focus groups, support tickets, social media, and in-app analytics will support or refute the proposed solutions. Be prepared to be wrong, change your mind, and move on quickly.

With that in mind, our product design process will involve gathering feedback from as many sources as possible, brainstorming and fleshing out potential solutions, and validating them early and often throughout the design and development process. Without further ado:

Lay the Groundwork

• Define the problem — Every product and feature should exist to solve a problem for the user. Trending problems collected from user feedback should be the inception of all design efforts.
• Define success — Quantitatively and qualitatively define what success looks like. This could mean a target improvement in certain KPI metrics, or an improved experience for the user.

Do Your Homework

• Study competitor solutions — Chances are you are not solving a completely new problem. You are likely solving a familiar problem in a new space, or incrementally improving on existing solutions. Start with the available solutions, and study what approaches they took. What works and what doesn’t? Look for analogous problems in other segments as well. Perform teardowns on existing solutions and take meticulous notes at each step.
• Read literature — Look for articles, posts, eBooks, and forum discussions that cover this problem. Just Google it.
• Analyze accessible data — Pore over your user surveys, support tickets, and system data to look for clues about how to solve the problem or what people are looking for.

Wireframe

• Brainstorm — Hold brainstorming sessions within your design team to come up with potential solutions. Outline a high-level flow of actions and information.
• Sketch — Create hand-written wireframes with basic actions and information. With each step, think about what information you need to teach and learn from the user in order to complete the flow.
• Prototype— Clean up the drawings and take photos of each step. Use a tool like InVision or POP to create a mockup of the flow using the hand-drawn sketches. You now have a facsimile of the application in a very rough form that you can share with other members of your team.

Refine

• Get into the flow — You will immediately begin refining and altering the wireframes as soon as you see them as a whole. Go through several internal revisions until you are reasonably happy with the results.
• For every decision you make, note the reason and cite the source — Good designers will put thought into every single word, action, element, color, transition, and animation. Don’t get caught later on trying to defend a design choice without the reasoning behind that choice. I typically have at least one full page of notes on each screen of a flow.
• Consider alternatives — Get in the minds of different user profiles and think about how each one would act at this point in the flow. Try to find a common solution. If conflicts arise, you may need to add additional steps or choices to bring them onto a single path.
• Create wireframe document with callouts — When you and the design team have come up with a solution you are happy with, it’s time to put your best foot forward. Create digital wireframes with placeholder assets and import them into your prototyping tool. Create a PDF or PSD of the entire flow with callouts for all the major design decisions.

Present Solution

• Develop presentation for stakeholders — Now is the time to present your proposed solution to other members of the team. This step is the crux of the entire process. By doing your homework and coming forth with a proposed solution, you frame the conversation around your proposal. You aren’t starting with a blank slate and asking the committee for their designs, you are improving and refining your chosen solution.
• Include problem, metrics, objectives — Your presentation should follow the methodology you took in developing the solution. Present your hypotheses, assumptions, data, and goals.
• Set expectations for feedback — If you don’t set boundaries, people will take the conversation to whatever catches their eye. Ask for specific feedback. Define what’s negotiable.
• Present context and designs principles — You’ve done your research. You’ve pored over user feedback. You’ve read the literature. You’ve analyzed competitor apps. You are more prepared and educated about this than anyone else in the room. By establishing this fact, you can combat those unsupported opinions.
• Present teardowns — Capture the flow of several other apps in a PDF. Walk through how competitors solve this problem. Discuss what you like and don’t like about each one. Identify what elements you borrowed and why.
• Walk through proposed solution — Go through each screen and describe the reasoning behind major decisions. Make specific requests for feedback from a technical, marketing, financial, and user perspective.
• Accept feedback in a non-judgmental way —This is where these discussions go off the rails. Strong opinions will come out. Some will use anecdotal evidence to support their argument. It may feel like you are being bullied or mobbed. Now is the time to maintain composure, listen closely, take notes, and make no promises.
• Make a list of possible A/B tests and revisions — In certain cases where multiple viable solutions are available, consider A/B testing multiple variations. When there is consensus around a change, incorporate it into the design.

Flesh Out Designs

• Create layouts, image assets, and copy — Start with the slide show version of the design
• A GIF is worth a thousand words — Create GIFs of animations and transitions.
• Develop refined mockup — InVision supports animated GIFs as well as images. At this point you can create a fairly lifelike replica of how the app will look when developed.
• Create focus group survey — Develop a set of questions to validate whether or not your solution will solve the problem or improve the experience. We heavily leverage the Expectancy Test. Before each action, ask the user what they expect to happen when they take that action. After they took the action, ask them how the result matched their expectations.
• Validate designs — Show the designs to new and existing users. If you need a fresh source of new users, use a testing service like UserTesting.com to validate your designs. If you frequent coffee shops, approach a stranger and ask if they’d be willing to check it out. Use your focus group survey to walk them through the flow.
• Present validation results to your team — After you’ve collected your feedback, you should do another round of revisions, then present the “final” design to your team. Expect some nitpicking at this point, and be prepared to make several minor tweaks.

Development

• Create technical assets — Once you’ve gotten final approval for the design, you can flesh out the final details. Create detailed callouts for placement and sizes. Create reference assets and publish them in an organized repository.
• Scope technical requirements — At this point, it is the product manager’s job to specify the low level technical details about how to implement the solution, tying the UI layer all the way down to the database layer.
• Build the darn thing — Development is out of scope for this story, so I will simply say that for the purpose of beta testing, you should plan to release beta builds every 2–3 weeks to get early and iterative feedback.
• Capture data — The application should capture any relevant data that will determine if the problem has been solved and the goals have been achieved. We have developed a home-grown event tracking system using Amazon SQS as a message queue. We use tools like MixPanel and ElasticSearch/Logstash/Kibana to track and analyze these events.

Beta Test

• Create beta group — You should create a group of friends, colleagues, and users that you can reach out to for beta testing. We use Crashlytics as a distribution platform.
• Gather beta user feedback — After we distribute a build to our beta group, we use SurveyMonkey to get feedback. We usually take the original focus group survey and modify it to gain additional insight from the working development build.
• Incorporate revisions — Any glaring issues should be revised in the designs and requirements. Issues that are out of scope or nice-to-haves should be put in the backlog for a future release.

Crunch Data

• Analyze data post-deployment — After the product has been released, you should be running reports to determine how the KPIs and user behavior has changed.
• Gather user feedback — After some time, you should expect to see user feedback related to your solution. It will either be positive feedback, supporting your solution, or negative/meh feedback showing that you failed to solve the problem.
• Backlog issues — Throughout this process you likely discovered problems or potential improvements. Some time after the product is out in the wild, you will get additional feedback that may prompt you to revise the solution. Plan for this in your roadmap and create backlog tasks so you don’t forget the details.

Party!

• Every release needs to be celebrated. Hopefully everything went well and you made a meaningful impact on your users and your business. Quantify those results and present them to the team. Give thanks and acknowledgement to everyone involved. Even if you failed to accomplish your goals, you should still support the effort that went into the project. Establish a ritual, whether it’s a post-release happy hour, a catered lunch, or a box of donuts and coffee. Do something every release to make your team feel valued and accomplished.

The product development process at a startup can be wild and harrowing. By following this process you can at least put some structure and predictability around it.

Do you need help streamlining your product development process? Is your business struggling to scale with your growth? I’m now doing full-time strategic consulting and fractional CTO work. Check out Voyagent.io and let’s connect!