UX Discovery: Empathy, Hypothesis and Assumptions

Posted on by Barrett Kenney

UX Discovery and Early Requirements Gathering

I tend to look at product development as moving along two tracks. 1) Path-finding, where fewer competitors exist and there is more room to blaze a trail with emerging technology or new solutions – or 2) Iterating on a mature or known product, where people are familiar with your product and common interaction models are available for reference. The former tends to be more of a revolution where the latter is an evolution (dang cliches).

Regardless of what track you’re on however, as you approach a product problem space you can use some of the tools from the discovery section of your toolbox. What I mean by discovery is the time you invest to uncover the issues surrounding use of your product by real consumers in the wild. This should begin with immersion, observation, and empathy. You don’t necessarily need to fire up a research effort that will take months of data gathering and interviews to generate a summary of findings and implications report – unless you do (in which case you can still use some of these tactics to keep yourself moving and be ready to strike when that report comes in).

Requirements gathering should aim to pull inputs from a few sources in order to make informed product decisions:

  • Where is the pain-point or opportunity and what is the potential ROI
    • Market research or customer feedback and market signals should you responding to
  • What benchmarks can we measure success against
    • Is there trend data such as a 90 day conversion rate or market averages you can benchmark against
    • Key Performance or Key Engagement metrics you are looking to move toward
  • What is the cost structure for supporting the effort
    • Weighing the nice to have vs need to have components of the product

Immersion, Observation and Empathy

Put your Anthropologist hat on here and walk a mile in the shoes of a person who would use your product. This is a great time to gather some ethnographic or psychographic data that uncovers your customer’s motivation, desires, goals and perceived usefulness of your solution. Go to where they go, observe in context and try to understand what their motivations are and how your product fits into the picture. For example a few years ago I was working on a next generation running watch and took the time to wear and use the current generation and decided to train for a race (wearing it both casually and while actively running). I took note of everything from comfort, style, ease of use, utility and entertainment. I also went to a handful of retail stores that sold watches and spoke with sales associates and other customers, paying close attention to their biases, opinions and perception (both emotional and physical). Some commented on the size, fit, cool factor, price, but I noticed that few really got into the technicalities. Of course I bought a number of magazines, and then I joined a run club and casually, conversationally conducted ad-hoc interviews at each run. I also bought a couple of competitors products used them and did heuristic evaluations of features and analyzed the out of box and set up experience.  I married this experience up with more formal efforts to conduct research and interviews and the findings were insightful.

  • Use the product, observe and listen to people
  • Evaluate the competition and if you can use their products
  • Heuristic review of features and rate how well they are implemented

This process doesn’t need to be exhaustive but taking the time to imagine and immerse yourself will help you construct a better understanding of the world as seen through the eyes of your customer.

Deliverables and Outcomes

  • Summary of research findings including competitors, features, and positioning
  • Use case definition
  • Context Scenario
  • Overview of Market Segment Data
  • Fictional Persona and Outline of their goals and intended use

Table Stakes and Understanding the Barrier to Entry

So now you’ve got a good understanding of the landscape and customer’s motivation. If you have an existing customer base what can you learn from them? Be sure you’ve gathered your customer feedback, had conversations with customer service, engineering support or whomever has a direct interface with your customers frequently. If not then you’re going to have to make some assumptions, that’s ok though cause you can always design a quick test to validate them.

A question to ask yourself: are you creating a “me too” product or a “yes and…” product? The former will allow you to focus on operational efficiency and competing on price where the latter will require you to hone in on key differentiators, marketing and user experience.

Table stakes require you to enter the market at a certain level or at least have functional parity for the product’s core utilities. If there are other products customers use to solve the problem your product is designed to do then there may be a baseline perception or patterns for how they work that you should consider adopting–spend your custom engineering resources on what sets you apart.

Value propositions and the elevator pitch, you should be able to hone in here on how your product does what, for whom, better or differently than the competition. Oh yes and definitely don’t forget to consider “why people will love it”. Take the time to write out a statement from the customers perspective, or better yet pull quotes from satisfied customers or enthusiastic test participants.

When you think about product requirements and lining up your backlog they should be framed from three perspectives, from this you should be able to identify your core market readiness criteria and some high level criteria that you will use to evaluate against at each step of the development process.

  1. Marketing impacts. How does this align to the overarching strategy and industry benchmarks, and are there external forces and timelines for marketing the product that need to be considered.
  2. Business impacts. Is the infrastructure available to support development of the feature/function/product and what technology is impacted or what licenses or services are required to support it – and of course how does that fit into the pricing structure.
  3. Operations impact. This may come down to people and resources to get the work done or finding the right agency or vendor to do the work and ultimately managing and integrating that within your organization and workflow.

Deliverables and Outcomes

  • Heuristic summary of parity or essential feature functionality
  • Proposed technology requirements to support development
  • High level UX vision, information architecture and hero visuals
  • Estimates for development costs, resources and license agreements
  • Forecast for release plans and forecast for margins

Finding the North Star: Ideation, Prototyping and Failing Quickly

At this point a fuzzy image is coming into view on the horizon. Some common language is starting to form around how we talk about the (problem, opportunity, product, market, etc…). From here I feel like the focus shifts a bit more toward the substance of the story or “crafting the narrative”. We have our assumptions, some data to reference and a framework for the experience so let’s dive into prototyping.

At this point I’d suggest bringing the design team in to really dig into the vision. Present a brief overview that sets the context for where you’re going and allow the design team to stretch their creative brains a bit to explore how you approach the problem. Depending on the amount of time you have (hours or days) there are a ton of creative exercises you can incorporate to hone in on design direction.

Some Design Collaboration Ideas:

  • Design Sprint (this book is a great resource and chock full of great ideas to pull from, for example answer the questions How might we… Why Should we… How else might we… etc..)
  • Value Proposition Design (another great resource full of consensus building ideas)
  • Diverge Converge (go broad with potential solutions, evaluate for common themes, narrow down for feasibility)
  • Pivot (how do we leverage an existing product or feature to move closer to the desired outcome)
  • Superheroes (if the solution were a superhero what powers would it have)
  • How does this scale (consider building in phases, for example how does it grow from manual to automated over time)
  • Why do customers love it (how does the solution create an unexpected gain for the customer, or simplify their life)
  • What design elements support this (if this is a UI for example take inventory of those layout, UI kit and steps required to execute)
  • Value vs Cost (collectively weigh your ideas against value to the business or customer and cost to execute)

I feel like this type of collaboration should still be treated as open-ended and blue sky as possible. Ideas that come out of this could start to influence and shape the overall direction or bring new insights to share with stakeholders. I think of the UX team here as a pendulum that swings between the needs of the stakeholders and goals of the business, incorporating market insights and data, and collaboration with engineering to explore what’s possible.

Prototyping can take many forms; paper, sketches, cardboard, 3D print outs, physical spaces, etc… Do whatever works for you to be able to set the context for someone to evaluate and  for you to observe use to gain meaningful insight and validate the design direction with as little investment as possible. The idea here is failing quickly. However don’t fail quickly too publicly or address these issues outside of your immediate team – in truth executives don’t want to hear about failures, instead lets call them findings or observations. This should really be aiming for your MVP. In another post I caution against taking the MVP to market but rather releasing the MVP to a control group and iterating towards Consumer Viable Products or CVP.

When presenting your prototype here’s an outline that I use:

  • What is the context for the problem we’re trying to solve
  • What we tested with our prototype
  • What testing showed
  • What opportunities for improvement we can make

Engaging with Engineering and Development to Begin production

How does all this UX stuff line up with Agile? We’re fully equipped now with KPI’s, research, acceptance criteria, some sort of spec and a prototype to reference–we should be in a good spot to start lining up our backlog. The good news here is that at least one or two people have been involved in some of the conversations regarding direction and feasibility so none of this should be a surprise. Hopefully you even had a developer participate in some of the ideation and brainstorming as well.

Lining all of this up for development should include an FRD or feature/functional requirements doc. Though I’ve had adverse reactions from engineers when you talk about documentation so if that’s the case for you frame it as a user story, that is part of an epic or theme, that has acceptance criteria, validated user test and design assets associated with it.

User Story Deliverables

  • an overview of the use case and context
  • identify alignment with business strategy
  • data and research findings
  • functional requirements, components affected and an indication of future iteration functionality
  • targeted touchpoint (iOS, aOS, desktop etc..)
  • where users will “discover” this feature and how, and why they will love it
  • reference to your user testing and prototype
  • design assets

Design and Development Collaboration and Workflow

A quick note here on workflow tools that can make all of our jobs easier and reduce the amount of questions and churn on button radius and tint values, dimensions of assets or otherwise. Some great tools have come onto the market in the last few years making UX design easier, more efficient and integrated. Along with this are some tools for prototyping that can ease the burden on developers and save product teams from building products nobody wants.

Here’s a list of products and benefits for the design process:

  • Slack – great for team chat and file sharing as well as integration with Jira, Confluence, Trello, Jenkins and a million other things
  • Sketch – vector graphics application quickly becoming the defacto standard–not only does it combine the best of photoshop and illustrator it integrates with dropbox, box, drive, Principle and Invision and the new Craft plug-in is awesome
  • Invision – quickly prototype for any screen size, web or native (and its responsive so if you’ve got a 6, 6+ or android you’re covered), works with a simple drag and drop storyboard style interface with most native actions built in. If you sync your Sketch working files simply hit save and Invision sync updates the prototype.
  • Principle – quickly create custom animations to communicate user interaction. Timeline based editor and much easier and cheaper to use than After Effects
  • Keynote – I’m partial to keynote because its awesome for presentations and has enough custom animation capability and timing control to convey most animation and interaction (downside though is it’s not super interactive and files can get kinda large)
  • Zeplin – you can also sync your Sketch files with Zeplin. Zeplin is great for design comp review and collaboration (people can share notes and comments on designs) and Zeplin also does a great job at slicing and exporting assets for pixel perfect accuracy and generating style guidelines for colors, font and type as well

I’ve seen plenty of other comprehensive tools and prototyping suites out there like Axure and the suite of tools from the Zurb Foundation. In terms of fitting into the comfort zone of the design team and figuring out a handoff for development the list above I’ve seen work really well.