Skip to end of metadata
Go to start of metadata

You are viewing an old version of this content. View the current version.

Compare with Current Restore this Version View Version History

« Previous Version 16 Next »

Output types

Throughout the discovery phase and its subsequent activities, it is imperative to document the acquired knowledge in order to provide transparency to all stakeholders involved. These discovery articles possess a dynamic nature, necessitating regular updates as additional insights are gained over the product's lifecycle. The characteristics of these articles can be summarized as follows:

Desktop research

[WIP] Competitive analysis report

[WIP] Review and analysis of existing data

  • Product usage analytics and data - Mixpanel

  • Revenue analysis

  • Cohort analysis

Interview snapshots

Following each interview conducted, concisely document the essential points in a summary for convenient reference and future access. Although it may be appealing to rely solely on audio recordings of the interview, reviewing these recordings to extract specific information can be time-consuming. To facilitate efficient information retrieval for yourself and relevant stakeholders, it is recommended to synthesize these summaries as you progress through the interview process.

Sample snapshot: https://docs.google.com/document/d/14zQm08w4AK8jYGItw0PzCSUBqo8qra3e06YkLqBZueo/edit?usp=sharing

All interview snapshots should be compiled into one log for easy access. Example: https://docs.google.com/spreadsheets/d/1aMl5xbTeixmYpKHQS2T9-cCeRkzj05_8aXY0pi2rDw0/edit?gid=157615990#gid=157615990

Personas

A persona is a fictional, yet realistic, description of a typical or target user of the product. It is used to promote empathy, increase awareness and memorability of target users, prioritize features, and inform design decisions. These require some level of critical thinking, but as with most of these discovery articles, you cannot simply think up a persona, they will jump out at you the longer you spend in discovery. Your definitions of your personas should be updated over time as you uncover more insights about your users.

Source: https://www.nngroup.com/articles/personas-study-guide/?lm=personas-are-living-documents&pt=article

Sample persona:

image-20240913-164531.png

Template article: https://www.interaction-design.org/literature/article/personas-why-and-how-you-should-use-them

Template:

Empathy maps

Create empathy maps per interview / engagement with the customer.

Source: https://www.nngroup.com/articles/empathy-mapping/

Customer experience maps

This document presents a cognitive representation of the interactions that transpire amongst the various actors involved in and surrounding your product. It fulfills two primary functions: firstly, it facilitates a shared understanding within the team regarding the actual activities undertaken by your customer in relation to the utilization of your product (or the product you intend to develop). Secondly, it serves to dispel any preconceived notions or inaccurate mental models pertaining to the actions and behaviors of your customers. The experience map is the parent of the journey map. The former focusing on all the actors and interactions between them, while the latter focuses on one actor’s journey at a time.

Use the method described in Continuous Discovery Habits.

Sample:

https://www.figma.com/board/Hmwwhwp5OetSXivMQq1uep/Experience-Maps?node-id=0-1&t=7S07PHKbp1ARqpgk-1

Customer journey map

Source: https://www.nngroup.com/articles/journey-mapping-101/

Confused about which maps to use?

See this article for a good breakdown of these articles, their uses and their interrelationships.

Source: https://www.nngroup.com/articles/ux-mapping-cheat-sheet/

As-is service blueprints

https://www.nngroup.com/articles/service-design-101/

Opportunity-solution trees

As discovery is conducted, opportunities will arise - fashioned as pains the customer goes through, needs and desires (whether they tell you explicitly or not). Now they could be listed out in a typical backlog and prioritized from there, but what an OST does is that it allows the team to see interrelationships between problems. If done correctly, the team will build a tree knowing that if they solve parent nodes, they can deliver actual value to the customer - this follows the agile methodology of delivering value every sprint.

The team will also discover some opportunities that you can work on outside the current business objectives. As new objectives come up, the team will not be starting from scratch because you would have seen these opportunities.

Not all opportunities need to be worked on. Some opportunities discovered might belong to another team. Some do not even need product solutions. 

Sample:

https://www.figma.com/board/IvyPPDxGyzx4FZQqZTIgP5/Opportunity-Solution-Tree?node-id=0-1&t=I5tM7X0UKCsrmExH-1

Findings presentation