Process for answering critical business questions through design, prototyping, and testing ideas with users – Google Ventures
In this article I provide an overview of my thoughts on the processes that create great designs. I learned a lot of these ideas from trial and error as well as reading articles and stories online and in books.
I’m particularly fond of GV’s article, Product Design Sprint, and ideas from, User Story Mapping: Discover the Whole Story, Build the Right Product
Understand Objectives & Learn About Your Users
The first thing to understand is what we are being asked to solve. What is the problem? Below are just a few of the methods you should be using to understand objectives and learn about users.
- Stakeholder Interviews
- Competitor Analysis
- Market Research
- Data Analytics
- User Interviews/Observations
- Define Business Success Criteria, high level requirements
As an interaction designer, I like to be close to the research team during the learning phase. Learning about the user in the field provides me with more insight into who the users are, how they think and what needs to be done to solve the problem.
Build a Shared Understanding
After collecting and analyzing all of the information start to design a concept and build a shared understanding with the team.
- Map the user journey
- Create a high level conceptual flow
- Storyboarding a conversation or interaction
Use your UX “War” Room (if you don’t have one, get one) to share concepts with other designers and get feedback. Share the idea with stakeholders, development leads, and other team members so that as the conversation grows you are all reviewing the same story. Use your War Room’s wall to post the storyboards or flows and concepts and get plenty of feedback. During the reviews use the wall to capture notes, vote on certain aspects of the design and tie in the technical aspects of the project.
Information Architecture, Layout, Interactions
Once the flow is mapped out and you feel good about where you are, start to create structure. Begin to tie together the information architecture and layout as well as start to define interactions. I always start with paper and pencil and then later take it to either mockups or omnigraffle to share with the larger audience.
Critique and Do it Again!
Once you feel comfortable with the concept, flows, and early design, pull the team together (stakeholders, product owners, development leads, designers, etc) and get feedback to ensure you are not missing any critical functionality. You want to ensure you are on the right path and that you are aligned to the business as well as supported by your technology partners. Stay lo-fidelity (whiteboard or pencil and paper) as long as you can and iterate as long as you can without putting the timeline in jeopardy, but to ensure you’re and then take the design to a higher fidelity when everyone is in 100% agreement.
Don’t forget to review with actual users! If you can get in front of user representatives, that’s great, but try to get in front of at least 5 or 10 actual users to get feedback. This early review with users doesn’t need to be a full fledged usability study, but simply an interview with users to get early feedback.
Define the Visual Language
Whether you are the one creating the visual language or not, now’s the time to start thinking about it. Unless your tests failed with the stakeholders or the users and you need to start from scratch, your design is probably well defined now and you can start to think about the visual language.
Build a Prototype and Test with Users!
During the iterate phase, just before I start to work with the artists, I also begin to pull in our front end team to do rapid prototyping. I will typically pull them in once the layout and information architecture are both solid so they can get a head start on building out the structure of the app while the artists are defining the visual language. I’ll also start to help the researcher or research team begin to define scenarios and scripts for usability testing.