Thinking About Discovery

By Neontribe
Published

Very interesting session at Agile tea camp last night about Discovery, led by @lily_dart from DXW. She talked about how they do it: open conversations, surveys and card sorting.

We've fairly recently changed our term for this bit of the software development process. It was always “Sprint 0” for us, that chunk of work that needed to be done so you could start coding. Then we read the Service Design Manual, and appropriated the term “Discovery” for the same kind of activity. We been developing a set of tools for this piece of work for a few years now. As you'd expect from a company on the Digital Services Framework, we concentrate on users.

That said — we generally begin with a quick conversation about objectives. The objectives of a project will usually have been articulated before we've become involved, and all we're doing is making sure we understand. It's just a check.

Getting into a user-centred mindset

The meat of our work in Discovery is in user research. We'll be thinking about the demographics of the people who'll use the project, how they think and feel and behave. We might even have some analytics information from an existing version of the service

It continues with a workshop with our customer's staff. Where possible, we'll have people who might actually use the digital service along too to give us some real lived experience. Here we'll often generate personas: fictitious characters that we use to help make sure everyone's focussing on real user needs throughout the project. We'll generate these characters together. We'll give them a name, an age, we'll understand where they live, what their homelife is like, what some of the other important people in this life are like. We need to know enough about them for them to be useful, but they can evolve during the project. These first character sketches can be pretty quick and still useful.

What these persona do is advocate on behalf of the people who'll eventually use the digital service. They represent the audience: unless the service is very targeted, they aren't all of it. They aren't average: they're individuals who we can ask questions. They won't lie to us: they won't be affected by other persona in the room as you might find real people at a focus group might be. They can reveal more about themselves than real people might: we can ask them questions about their unrealised needs in a way that isn't possible with real people.

Where this technique can fall down is where someone with an set view of precisely what the service should do. We've seen people like that use persona as a proxy for their pre-existing opinions. Having people who might use the service along to validate helps combat that. What we might also do is use a survey to check we're on the right track: that can expose entrenched thinking as unrepresentative.

That done, we'll put those personas in situations where their goals intersect with the project objectives. Those situations are generally one line or so - they certainly fit on a post-it note. They enable us to understand what's important to people who will actually use the digital service we're working on.

Those personas, in those situations, help structure a conversation about what's important to the real people who'll use a digital service. The insights from those conversations, we validate with more user research as we move through development.