Discovery Workshop
Facilitating the Discovery Workshop during Design Week
Last updated
Facilitating the Discovery Workshop during Design Week
Last updated
We usually allocate a little longer than needed in the schedule to give time for running behind and having a break.
00:00 -
00:10 -
00:30 -
00:50 -
01:10 -
01:30 - End
Sometimes known as a User Needs Statement. Try to get the participants to get into the head of their users by writing a one line summary of the problem they're facing.
These should answer three questions:
Who the users are?
What they need?
What responding to that need would do to benefit them?
and be in the form:
User Personas are descriptions of fictional individuals who are representative of a user group. These can help a team to understand and get into the mindset of those they're trying to serve with a digital product. Personas should summarise who the person is; their characteristics; how they behave; and their point of view.
It can be helpful to give a template for participants to fill in. This might include these prompts:
Their name
Who they are
What is their point of view?
What are their goals?
What do they do? How do they use technology? What are their frustrations?
During the first half of the allocated time, each participant writes a single persona. The remaining time can be spent introducing each user to the rest of the group.
Writing questions to ask users off the bat is pretty tricky. So we break the activity into stages building up a body of questions to ask.
Firstly, identify any assumptions being made. Testing assumptions is an important part of researching a digital solution.
These might be about who the users are, how they behave, or what they need. They might be about how people use technology, or how a new digital product might be beneficial to a user group. Or they could be about anything else to do with the user group or product.
There's also a number of fundamental assumptions - that people actually face the problem, or that technology can do anything to solve it. These might be hard to ask about, but are important to try and identify.
The assumptions can be written as statements, and turned into questions later.
Thinking particularly about anything not covered already in the assumptions, participants write down any other topics to cover in the research. Again, they might be statements at this stage and can be reformulated in the next step.
Encourage participants to add as many notes as come to mind. It's preferable to have too many questions and trim them down than to not have enough.
This step is to formulate a research script. Participants should work together to write open-ended questions which they'll ask to users. At this stage, notes from the previous two exercises can be turned from statements into questions.
When asking research questions, it can be helpful to look for stories. Frame the question in a way that gives the user scope to talk about their own experience. Usually these questions start with 'Can you tell us about a time when..." or "Have you ever...".
The questions should be organised into a conversational flow which can be followed in each interview.
Developers should write a brief introduction which they'll start off the interview with. It should include a one-sentence summary of what the idea is, without hinting at what the product will be. All interviews should begin without bias, in order to get honest and genuine feedback from a user.