Discovery projects: Finding out what we don’t know

I’ve always been interested in cross-functional teams, and have been fortunate to work on a team that integrates research heavily into the design and development process. Over the past few months, myself and the rest of the Optimal Workshop team have been working on a new special type of project. It’s something that we called a “Discovery Project”.

Before I explain what a Discovery Project means, I’ll set some context.

At Optimal Workshop, we have a pretty steady stream of small feature improvements that get rolled out continuously (we do about eight releases a week consisting of about 30 small changes!) but generally these changes are small enough to have only one or two developers working on them with a small amount of design input and research. We learn a lot from the people who use our tools, and we’re always listening so that we can do our best to continuously improve what we already have.

But what about new stuff?

The year 2016 rolled around and brought with it some new feature requests, and some new team additions too. We formed a mini team and labeled what we were doing as a “Discovery Project” because, well, we wanted to do things a bit differently and do lots of discovering. This blog will talk about the discovery process and how we did it. 

We really wanted to learn what to build and how to build something new for Optimal Workshop. This meant embracing uncertainty and starting out with very few requirements. We had to discover how to work together in a more collaborative way with this new cross-functional team (new hires included a designer/developer, a senior developer, and two user researchers).

A discovery project gave us a chance to dig deep into a feature request and try to understand why users want it and how to best deliver it.

A discovery project meant starting out with very little requirements and accepting flexible scope.

A discovery project gave us space to say: “We don’t know what we don’t know…so let’s find out.”

Here is what we did know:

Our customers wanted a way to organize their studies.

Many had asked for folders as a way to do this.

What we didn’t know:

How our customers would like to organize their files.

Why they like to do things the way they do things.

What the final project might look like.

Who will use this feature.

So, we started on a journey which looked a bit like this (a lot of this work ran in parallel):

Background research

• We went back through support channels to see what people had requested.

User interviews

• Gathered the users that would most benefit from this.
• Invited these users to contribute their thoughts. Asked what they think about various ideas, how they currently perform tasks, and what they would like to see improved.

Interactive wireframe interviews

• Built a very simple prototype to show customers to see if we can solve some of the trickier interactions we were getting stuck on.
• Checked comprehension.
• Checked expectations.

Design

• We allowed design to change over time as new information came in. Nothing was set in stone yet.

Team discussions

• Put work-in-progress up on internal servers for staff to play with and comment on.

Iterating and building

The key thing was trying to do this all in parallel, as we were going to need to define scope as we learned things.

Being collaborative doesn’t mean sticking things up on a wall and letting people comment with their opinions. It means having the whole team pitch in with their areas of expertise. With our new senior developer we were able to try out some new front-end javascript heavy tech. Meanwhile, our user researchers tested our theories. As I’m a designer and coder, I could mock these up to test interactions. We tried out Atomic, and found we could easily run remote user tests by sending our interactive mockups to our participants. Developers sat in and watched the user testing so they could empathize with the people we were building for and understand any difficulties in the interface.

Key takeaways

Work in parallel

Working in parallel can be challenging, but it’s an essential technique for this type of work. It’s hard, and it will take some time to get right. While research is happening, there are things you can start building even if you don’t know exactly what it would look or feel like yet. Get comfortable researching things that might not be perfect (the whole point is to find things out, not just to validate what you have already finished).

Support

Having management support and buy in to allow for the ambiguity of a discovery phase like this is key.

Your team is also a project

Each time you work together you also discover things that worked well and things that could be improved. Hosting a retrospective is a great way to discover these insights. Iterate on your processes and your team — not just your project!

What does ‘done’ look like?

Eventually, you should have a list of tasks the user will absolutely be able to perform. Once this list is assembled, you can consider the project launchable. There should also be a list of ‘nice-to-haves’. You could, in theory, continuously develop and design something but you have to be able to draw the line in the sand somewhere and say “This can go out now”. I’m quite fond of the concept of Minimum Loveable Product (over Minimum Viable Product) because it makes it clear to the team that they should address what needs to be done for the product to be usable and lovable — not just functional.

What’s next?

Our first discovery project has just been released. It’s a new way to organize your studies into folders, and a consolidated view of all our tools. If you have any feedback, we’d love to hear it. Send an email over to support@optimalworkshop.com and let us know your thoughts.