Some software industry practice is very similar to lotteries: we think we already know the user’s problems and we try to solve it with the most wild products
This mentality is problematic because if you don’t reach product-market fit, you have wasted a lot of effort and money
Startups should not function in the following process: think of an idea → engineer idea → launch idea → measure
This is what you can call optimistic guessing at best
Guessing puts you at a competitive disadvantage, arrogant and expensive
Important to spend time to first understand customer and their needs
Any company serious about design and engineering should be equally serious when it comes to learning about their customer
Two types of research you can do:
Quantitative: things you can measure. Think of analytics
Qualitative: tells us about the qualities of a product and user experience
You need both to become extremely effective. Qualitative evidence provides context for numbers and data
Make sure to randomize order of choices to avoid order bias
Use filter questions to tailor your survey to particular segments
Conclude with open-ended questions
Make sure you test out the survey on a pilot test of users
Craft the email with the survey link carefully to maximize response rates
Can automate these surveys or go ad-hoc
Customer interviews
These are incredibly useful because they help you understand their emotions and workflows, enabling you to think of better products
Use survey results to identify key customers/users you would want to talk to
Ask for a quick (20-30 minute) interview and make sure to record it
Interviews shouldn’t be connected to a project. Having consistent interviews ensures that you are constantly learning from the customer
Get one person to write notes, another to guide, another to observe
If the customer gets emotional, note that!
Use existing data from marketing, sales, customer support, engineering and analytics to discover user needs and problems
While the software industry is all about failing fast, you need to make sure that you at least give yourself a decent chance by researching users before you start
Successful companies are succeeding because they guess less!
Story First
Create a clear and compelling story as you move along development so that the end user is always in sight and we don’t lose sight of the forest to focus on the trees
Makes the ‘why’ behind a product extremely clear
Stories should be based on user research: understand what are the major problems and frustrations that they are dealing with
Use Pixar’s framework: Once upon a time there was ____. Every day ____. One day ____. Because of that, _____. Because of that, ______. Until finally:____.
These stories should describe how the product fits into the lives of its users
A good story:
Demonstrates how a cast of characters behaves in a particular setting
Shows how the product creates value for your customers
Takes place in the near future where current technical constaints have no meaning
It can be visual
Use a story arc (intro, conflict, resolution) to craft an effective story
Identify the characters main goals, be specific, talk about particular hurdles, make it informative and fun
Use a storyboard or video to communicate the story in a more visual manner
Create user personas to really understand your core group of users you want to target
Interview people from interested segments, analyze to find common traits, create a common profile and make sure to update often
Job story framework: when_____, I want to ______, so that _______
Identify the situation, motivations and expected outcome. Do this for each interview and combine
Pencils Before Pixels
Make crude outputs first to explore and discover many ideas before comitting to one and drawing it out with pixels
Sketching with a pencil is a good thinking exercise as well and can lead us to think down other idea paths
Sketching out using computer makes people think that the design is already finalized. Instead, if you do it with pencils first, it seems more accomodating to other’s inputs
You ideally want people to provide input and feedback.
If the person is afraid of sketching, you can trick them into drawing their idea but intentionally misinterpreting and making mistakes. Eventually, they will be frustrated enough that they will sketch out their idea
Team sketching often allows some new ideas to pop up or ideas to be reinforced
Use 6-8-5: 8 people with 6 really rough sketches in 5 minutes. Discuss with group
Try to use thick pencils or markers to prevent people from sketching out fine details
Show and Tell
Feedback is incredibly important for the iterative process of design
Helps create faster designs, multiple perspectives, syncs team for design, learn
Use design reviews regularly to go over design work. Critique the work, not the person
Post design sketches on walls so that passerbys and other designers can provide feedback
Formal design feedback
Reviews: conduct anytime during project with designer and a couple of people.
Should be used to get critiques and detailed feedback. Should not be used to announce new features
Should have a facilitator (not the designer), state the problem and state the ask (what does the designer need feedback on?) ⇒ especially important to make meeting a feedback session rather than a brainstorming session
Don’t pitch, just listen to the feedback
Standup: do it within design team daily
Retros: Held after project is completed or sprint is completed
Make sure to take steps to prevent bias and bandwagon effect
Get individual and team scores on a rating from 1-5 from everyone
Start, Stop, Keep
Postmortems: held after project gone completely terribly
Get everyone involved to identify the key points in the project timeline (rather than what people did) to construct a master timeline and determine where the team went wrong
Create an action list of items on what to improve on and email to everyone
Fast Feedback
Good design teams are habitually testing out their designs before a single line of code is written
They build high fidelity prototypes and get feedback from colleagues and customers
This allows the team to learn faster, creating a competitive advantage
Ex: Disney invested a lot in technologies that can help them get faster feedback, creating a media entertainment monopoly
Use a design tool to create a prototype, not code
Should be focused on: how easy is it to focus on prototype, can this prototype be used on multiple devices, ease of sharing
Use UI kits
Focus on features that you have questions on, not the whole app
Prototype should feel real enough to the point where people don’t realize that this is a prototype
Can create pattern libraries, which form the building block components of each screen, helping the team move incredibly quickly later on
You don’t need to test with a lot of people. Just test with 5 customers and you can get some healthy feedback
Use a screener form to get some people, ideally power users
Lateral Design
Remember: design is the act of planning with the intention to serve others
Organizational design influences product design significantly; broken teams lead to broken products
Design should not be siloed with the engineers, they should be working hand in hand so that it meets design requirements and engineering requirements
This is why there is lot of hype around the whole concept of cross-functional teams, because it encourages teams of different purposes to come together to design a product as a team
Collaboration becomes much easier if both the designers and engineers are working at the same time on the same features
Techniques to foster lateral collaboration: design sprints, working groups (5 people from different functional teams)
Engineering, product and design (EPD) teams should be organized around features and the leader of each of the three functions should have good rapport and remain united
Problem with working groups: may feel like a vaction, but if it were more permanent, people will have a hard time determining what their identity is apart from the feature or project
Can always have pairs across EPD to ensure that designer doesn’t feel lonely
Use design reviews to foster vertical collaboration, rotate employees across teams
If EPD is the way, the design teams have to spend time making sure that the design is consistent across features
Spotify uses a GLUE team to guide the whole design system of Spotify and designers regularly sync with GLUE to make sure that the design remains consistent
Be wary of pushback from engineers, as they often look at how difficult it is to implement. Can prevent this by having company-wide design values that designers can reference when in discussion from people in other functional groups
Break the Black Box
When design isn’t visible, it is no longer powerful.
When companies scale, design usually becomes a black box where the executives and engineers have limited ability to provide feedback before some grand reveal
Spend time creating social capital by talking to people in different parts of your organization
Make sure stakeholders interact with design early and often