NEAR Wallet: Q4 Design Sprint Proposal

[heycorwin]

As we wrap up the latest wallet release and reflect on the launch of NEAR’s mainnet, it is an appropriate time to take a step back to evaluate the current state of the product, and to collaboratively define and address the critical problems our users face so that we can plan and prioritize effectively.

We’re reaching the end of a sustained “reactive” period, and will benefit from a strategic reorientation. This document outlines the Product Design Sprint process as a proposed mechanism for orienting the team as we look forward and prepare to tackle our next set of challenges.

---

What is a design sprint?

A design sprint is a 2-4 day strategic and collaborative effort where key stakeholders get together in a room (virtual in our case) to participate in a series of co-design exercises facilitated by a trained expert (@corwinharrell ).

How is it valuable?

A design sprint is a battle-tested tool that aims to condense and democratize the process of designing for product.

It allows for us to:

... rapidly build a shared understanding of a problem set

... come up with lots of varied solutions

... converge on what we think the best solutions are

... conduct testing to validate the assumptions we’ve accumulated during the process.

In doing this, we orient the team, extract valuable insights from everyone involved, and reduce the inherent risk in building towards the next iteration of our product.

What the design sprint is not

The design sprint is not...

... a multi-day free-form discussion / shouting match. Each exercise has been intentionally designed to result in repeatable outcomes, and will be facilitated and time-boxed.

... a presentation or an activity where you should expect to be able to passively participate. If you attend, you will be expected to bring your full self, take part in all of the activities and discussions, and be able to present your ideas to the group.

... a review of the granular feedback we’ve received from users in response to recent feature releases. These should be aggregated and tracked separately, and at the conclusion of the sprint, relevant issues will be integrated into our roadmap where it makes sense.

---

How is it structured?

Day 1: Understand & Diverge (Morning & Afternoon session)

1. We’ll map out the set of problems and challenges our users face. The subject experts in the room will provide the necessary context and evidence for these problems (prepared beforehand).
2. We’ll hone in on the subset of these problems that we want to prioritize and address during the sprint.
3. Everyone will participate in a divergent design exercise to generate ideas and potential solutions for the problem/s we’ve defined.

Day 2: Converge & Decide (Morning & Afternoon session)

1. We’ll look at all of the ideas that everyone has generated, and will discuss and converge on what we think are the best (or a combination of the best) solutions.
2. We’ll collaborate on a “storyboard” that will represent a core user journey which will inform how we prototype our solution and test our assumptions later in the week.

Day 3: Prototype

The designer will take a full day to build a clickable prototype(s) representing the solution(s) generated during the sprint.

Day 4: Test

We’ll test our prototype(s) to validate against the assumptions we’ve accumulated during the sprint. We’ll put something in front of real users, and see how they react to the solution(s) that we’ve generated.

---

Following the sprint, we’ll plan and update our roadmap, accounting for the things we’ve learned and incorporating items from our backlog. We'll then present our findings and direction to the team at All-Hands, so that the org can stay up to date about any critical decisions made as a result. (@kendall Cole maybe you and I can tag-team this)