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 be designed in a multitude of ways, it must be developed in only way. As a designer or product manager, you need to listen to their feedback, but ultimately decide on a final . How can you create a cohesive user experience when everyone thinks it should be designed in a different way? could one design 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 — 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 the problem — 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. Define success Do Your Homework 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. Study competitor solutions — — Look for articles, posts, eBooks, and forum discussions that cover this problem. Just Google it. Read literature — 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. Analyze accessible data Wireframe — Hold brainstorming sessions within your design team to come up with potential solutions. Outline a high-level flow of actions and information. Brainstorm — 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. Sketch — Clean up the drawings and take photos of each step. Use a tool like or 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. Prototype InVision POP Refine 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. Get into the flow — 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. For every decision you make, note the reason and cite the source — — 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. Consider alternatives 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. Create wireframe document with callouts — Present Solution Now is the time to present your proposed solution to other members of the team. This step is the crux of the entire process. You aren’t starting with a blank slate and asking the committee for their designs, you are improving and refining your chosen solution. Develop presentation for stakeholders — By doing your homework and coming forth with a proposed solution, you frame the conversation around your proposal. Your presentation should follow the methodology you took in developing the solution. Present your hypotheses, assumptions, data, and goals. Include problem, metrics, objectives — If you don’t set boundaries, people will take the conversation to whatever catches their eye. Ask for specific feedback. Define what’s negotiable. Set expectations for feedback — 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 context and designs principles — — 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. Present teardowns Go through each screen and describe the reasoning behind major decisions. Make specific requests for feedback from a technical, marketing, financial, and user perspective. Walk through proposed solution — —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 . Accept feedback in a non-judgmental way make no promises — 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. Make a list of possible A/B tests and revisions Flesh Out Designs Start with the slide show version of the design Create layouts, image assets, and copy — — Create GIFs of animations and transitions. A GIF is worth a thousand words 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. Develop refined mockup — — 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. Create focus group survey Show the designs to new and existing users. If you need a fresh source of new users, use a testing service like 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. Validate designs — UserTesting.com — 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. Present validation results to your team Development — 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. Create technical assets — 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. Scope technical requirements 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. Build the darn thing — — 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 as a message queue. We use tools like and to track and analyze these events. Capture data Amazon SQS MixPanel ElasticSearch/Logstash/Kibana Beta Test — You should create a group of friends, colleagues, and users that you can reach out to for beta testing. We use as a distribution platform. Create beta group Crashlytics After we distribute a build to our beta group, we use to get feedback. We usually take the original focus group survey and modify it to gain additional insight from the working development build. Gather beta user feedback — SurveyMonkey — 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. Incorporate revisions Crunch Data — After the product has been released, you should be running reports to determine how the KPIs and user behavior has changed. Analyze data post-deployment 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. Gather user feedback — — 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. Backlog issues 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 can be wild and harrowing. By following this process you can at least put some structure and predictability around it. startup 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 and let’s connect! Voyagent.io
