Note: this was previously 'Definition workshop - part one'

Schedule

We usually allocate a little longer than needed in the schedule to give time for running behind and having a break.

• 00:00 - Synthesise Research

• 00:40 - Mapping

• 01:00 - How Might We...?

• 01:15 - Consequence Scanning

• 01:30 - End

Synthesise research

The group will have separated for research, and now need to communicate their findings to one another.

We ask them to take three steps in doing this:

1. Write down notes on what they heard from the research

2. Organise those notes into themes

3. Write up statements of the research insights

Mapping the journey

This is a version of User Journey mapping. Developers should plan the main path through the application.

On the left hand side, they consider their user. And on the right, the goal of that user. These can both be lifted directly from the Problem Statement and don't need much thought. It's the product itself, the 'I need a way to...' that needs to be explored.

There's three main phases here:

• Discovery: finding the service

• Learning: Finding out what your service offers and how to use it

• Using: The regular steps the user will take when using the app Discovery is the least important step for us on the programme. It's worth considering but not for more than a minute or two.

There might be a few different avenues, or choices made along the way. But by the end of the exercise, the team should have a broad idea of what the app will do and the order the user will perform actions in.

How Might We...?

This is a speculative exercise which intends to get developers thinking about the challenges of building a Product which will respond to the needs they've identified so far. Asking questions, and not worrying about the answers, will help to shape the key challenges of building this product.

Consequence scanning

Developers are encouraged to think about the effects of building a product like the one they have in mind. What good could it do? And what harm might it cause?

Create a table with two rows and two columns. The rows can be labelled "Intentended" and "Unintended"; and the columns labelled "Positive" and "Negative". You'll then have four squares for the developers to add notes.

Developers should add notes to the relevant sections for different intended/unintedend and positive/negative consequences of the app. The consequences might be broad, and can be imminent or distant. The main idea here is to consider the impact of a certain digital product.

Figma is a tool used for high-fidelity wireframing

Tools available

Toolbar

Component based design

build components and replicate them across frames

change the component and it will change across all frames

change an individual frame to show a different state

Connections

Prototype mode allows you to define a flow for users to click through the app

You can view the live prototype

Use this for usability testing of your prototype

Schedule

• 00:00 - Inspiration

• 00:20 - Lightning talks

• 00:30 - Generate ideas

• 00:38 - Big idea

• 00:42 - Wireframing

• 00:50 - Upload

• 00:55 - Dot vote

• 00:60 - Discuss

• 00:90 - End

Inspiration

Find sources of Inspiration for the look and feel of the application they're building. Look online for similar apps, colour schemes, user flows that might be drawn from for this app.

Lightning talks

Give an overview to the rest of the team of what each individual brought from the round of finding inspiration. Each summary should be short, no more than 2 minutes.

Generate ideas

In 8 minutes, come up with 8 unique sketches of elements to include in the app. Fold a piece of paper into 8 panels. In each of these, sketch an idea to include in the app. It could be a screen, a component or a piece of copy. The goal here is to think divergently and to pivot to a new idea after each minute is up.

Big idea

Expand on one of the ideas you've come up with in the idea generation stage. You might sketch what comes before it, and what comes after it. Or expand on the level of detail.

Wireframing

This low-fidelity wireframing should be done on Miro or on paper. The goal here is to start to draft what the app might look like. Focus on four main screens and the flow through the application. Low-fidelity wireframes don't need to show much detail or look fancy - they should show the context of moving through an application

Upload

If you've been using Miro to facilitate the workshop, give each team some time to upload what they've done on paper to the board.

Dot vote

Each person should look back over the sketches and wireframes that have been created so far. Indicate what stands out to you by placing a dot over it. This marks something you want to highlight as interesting, innovative or otherwise worth discussing.

Discuss

Spend some time as a group discussing what has been created so far and how it will feed into the application. Reach a consensus on which ideas should be taken forward to the next stage of higher fidelity wireframing.

Spending time on planning what to build before builiding it

Project planning

Or the service blueprint - represents the user flow and how the app responds to user interaction at every step

Code planning

Deciding on a tech stack and justifying choices

Conducting user research on the in-house project gives our developers an opportunity to challenge their assumptions and adjust their product to meet the needs of their users.

Scheduling

Each interview should be 20-30 minutes long and scheduled in advance. We ask the cohort to arrange a few users each before they start their project.

The best users to interview are people who aren't developers or otherwise familiar with the software development process, and aren't familiar with the product idea.

Conducting interviews

Interviews are conducted in pairs with one developer taking the lead on asking questions, and leading the conversation. The other developer takes notes of what the user has said.

The interviews can be face to face, or online.

Conducting good research

Start with an introduction: to the developers, the process, and one sentence on the product idea.

• Keep an open mind, don't be afraid to challenge assumptions

• Ask open-ended questions, which give a user plenty to talk about or reflect on

• Look for stories - for example, with questions starting with 'tell us about a time...'

• Listen to the user and give them ample opportunity to speak

• Ask follow-up questions based on what the user says, and don't worry about sticking too closely to a script

• Avoid bias by only giving the user a brief summary of the product idea and avoiding giving your own opinion during the interview

Usability testing gives validation of the user journey and user interface

Scheduling

Each session should be about 20 minutes with 10 minutes in between to decompress or tidy notes

Conducting testing

Explain little about the app but give a good introduction to testing

Disclaimers are helpful:

• we're testing the app and not you

• you can't do anything wrong

• the app isn't finished - some things won't work

Let the user lead Ask them to speak aloud as they go through the prototype

Synthesising the feedback

There's a few methods

Qualitative - write everything down that was said and write in depth reports Quantative - rainbow charts or traffic lights

Schedule

We usually allocate a little longer than needed in the schedule to give time for running behind and having a break.

• 00:00 - Problem Statements

• 00:10 - User Personas

• 00:30 - Research: Assumptions

• 00:50 - Research: Brain Dump

• 01:10 - Research: Organise

• 01:30 - End

Problem Statement

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:

As a USER, I'd like a way to NEED, so that BENEFIT.

Example

As a black, queer person
I'd like a way to access information about local attitudes, laws and practices
So that I can choose travel destinations where I will feel safe and accepted

User Personas

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 research questions

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.

Assumptions

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.

Brain dump

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.

Organise

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.