BYOMSPM

For this assignment I listened to a UX Podcast with Dan Brown and read articles by Michael Storrs and Teresa Torres on continuous discovery, then I summarized them all here with a few thoughts of my own. Please see the Works Cited section at the bottom of this post; these sources are fantastic, as evidenced by how heavily I reference them throughout this post.

Grade I gave myself for this assignment: 95/100 (this was a highly useful assignment)

The Case for Continuous Discovery

First, multiple of the sources touched on the ways that design processes have evolved over time: historically, design in businesses has been “project-based” (Torres). This means that discovery has usually been done in a silo for a distinct period of time, then the findings are presented in a packaged unit. This design discovery phase, in which teams are deciding what to build, then informs the development phase, in which teams actually build the product during another distinct period of the project. This is sometimes followed by some form of validation done after implementation is complete (Torres).

Dan Brown (from the podcast) outlines a more ideal design flow, which also seems to be the direction that some businesses are now moving: ideally, discovery should be done throughout the whole project and continually inform implementation efforts rather than be centered around producing a single deliverable. In this type of a design process, discovery is not just a phase but rather a persisting attitude of humility and open-mindedness in which designers acknowledge that they might not always already know enough to make good decisions.

This is reiterated by Torres:

“The best teams recognize that digital products are never done. We can always iterate and improve.”

Torres, 2021

During the podcast, Brown also contends that the double diamond framework of design thinking makes the discovery-design-deliver process very linear, when in reality discovery is highly chaotic and should ideally be used on and off throughout the entire life of a project.

Torres then highlights a key gap in the project-based design flow: sometimes designers aim to analyze the success of project after it’s developed, but often at the beginning of a project teams didn’t define success beyond simply producing the product, so it becomes difficult to measure any aspect of success beyond that once it’s implemented. To me, this seems like a side effect of a poorly defined problem space, which might happen after a rushed design phase that prioritizes coming up with a solution over fully defining the problem space.

Another warning that Torres gives related to classic design processes is the “curse of knowledge,” or when a designer knows so much about their product that they forget what it was like to not be very familiar with it, thus making it more difficult to design for users who are in that position. To me, this also seems like it stems from the disconnect that is created when designers only interact with users in short, isolated bursts.

How-To: Continuously Discovery

In the article on product discovery, Torres lays out an ideal framework for arriving at product solutions: map high level business outcomes (sell more shoes) to product outcomes (increase user time spent on shoe-selling website), then use discovery to identify opportunity spaces within those product outcomes (users have a difficult time finding specific shoes through the search feature); then, through research on these pain points, identify appropriate solutions (use machine learning to enhance search feature) (of course).

With that said, Torres also shares that good product teams, in her mind, interact with customers on a weekly basis. These ongoing customer interviews allow design teams to stay in touch with customer pain points as they evolve in response to new product features and user environmental changes.

A key aspect of continuously discovering is that design teams need to be able to quickly verify that they’re on the right track without having to build an entire solution that they can then validate afterwards (see paragraph 1). Both Torres and Storrs, from “The Fastest Way to ‘Right’”, recommend story mapping, or outlining user/product actions step by step, as a method of quickly testing assumptions. Storrs also suggests using the “what must be true…” framework for creating some more specific questions for design teams to ask themself as they story map in order to identify their assumptions or things that must be true:

• What must be true about what our customers value for them to use this product?
• What must be true in order for our customers to download our app?
• What must be true in order for our customers to sign up for our app?
• What must be true… insert your own!

Storrs then proposes that after a design team identifies all of their assumptions or things that must be true, they should pick the top few riskiest assumptions, taking into account how likely they are, how big of an impact they would have if true, and how costly they would be to remediate. He offers a few strategies to then use to validate these assumptions, including but not limited to the following:

• Talk to users
• Collect surveys
• Create simple prototypes
• Do a competitive analysis

At the end of the day, the more you can get actual feedback from users, the better. I guess it’s time to start scheduling some more customer interviews!

Thanks for reading.

---

Works Cited

“#295 Discovery with Dan Brown (UXP Classic).” UX Podcast. 11 August 2022. Spotify.

Storrs, Michael. “The Fastest Way to “Right”: Assumption Testing.” Medium, Weave Lab. 15 May 2018. https://medium.com/weave-lab/the-fastest-way-to-right-assumption-testing-7b8508898b4f.

Torres, Teresa. “Product Discovery Basics: Everything You Need to Know.” Product Talk. 18 August 2021. https://www.producttalk.org/2021/08/product-discovery/.