Sometimes before you embark on a journey to develop something new and meaningful the biggest question is the unknown between the cost and benefit. It is better to first validate the idea and ensure that everyone has a clear understanding of the needs and goals of the solution.

There are numerous ways in doing this, but here at Zure we have started to call this process a Discovery.

What is a Discovery?

Discovery is a design-driven approach where we combine our knowledge in digital service design and technology to ensure that both business and user needs are met and the technical solution is developed in a meaningful way with high quality.

Discovery is a process where 1-2 designers and 1-2 Technical architects work together with our client’s key stakeholders and users. We run multiple workshops to dig deeper into our client’s challenges, needs and goals and aim to provide a clear roadmap forward for a successful development project.

A Discovery digs deep enough so that we can validate that an idea is worth investing in, but at the same time, it is quite light, so that we do not spend too much time or money on excessive upfront planning.

Assuming that Discovery leads to a development project together with us, then always one designer and one architect from the Discovery team will continue as part of the development team.

Working on the challenge together

Working together in workshops (face-to-face or online) is key to getting the right results. A Discovery usually has 3-4 workshops ranging from 2 hours to a full day (depending on the need). Based on our experience we have found that it is better not to tie the process into a fixed calendar time. Instead, the structure is quite flexible so that we can adjust based on our client’s capability to participate in the work.

Everything always starts with an alignment and planning workshop, where together we go through the starting point and the challenges we want to tackle. We also plan the following workshops.

We continue by identifying our users and visualising the journeys they take. This way we can better understand them and the as-is pain points within the current tools and practices.

Identifying and contacting actual users is an important part of the work. We want to interview and observe the work they do. This helps us in getting a clear understanding of how the new solution could help do things better.

At the same time, based on the findings our architects start to draft an idea of the to-be solution architecture and related technical details.

The time between workshops helps the team to get concrete results. After the first workshops, the following workshops are planned in a way so that we can dig deeper into the to-be solution, but also ensure that there is enough time in between so that we can work on the deliverables and ensure that there is always something new and more refined in the next workshop to look at together.

To sum it up. During the workshops we want to get a better understanding on:

• Who are the real users and what is important to them?
• What is the business goal and benefits we are trying to achieve?
• How are things done as-is?
• What is the to-be vision?
• What are our technical limitations?

Analysing the findings

Especially with user needs. It is always good to actually reserve time to properly analyse the findings. By analysing the results from the as-is walkthroughs, user interviews and observations we can validate assumptions and organise the findings in a way that is easy to identify what is important and what might have less value.

By comparing our findings with the given business goals we can identify the most valuable needs with the highest payback value. This information is then transformed into prioritization when we start drafting the initial backlog for the development project.

Making it more tangible with visualisation

Nothing helps more in building a common understanding than looking at something visual together and having a discussion around that. As early as possible in the process, we try to create something visual to use as a discussion anchor. Usually, we start by visualizing user flows/journeys. First the as-is and then moving towards the to-be. These can be followed with a site map and some user story mapping.

If possible and if we get a good enough understanding of the to-be requirements early enough then we might also do some initial wireframes or even light prototypes to get a first idea of what the solution might actually look like.

Concrete deliverables

What really matters is that our clients get something concrete and valuable from this process.

At the end of every Discovery, we come together one more time and go through all findings and provide a plan to go forward.

After each Discovery we provide:

• A prioritised list of business and user requirements as an initial backlog
• A description of identified user profiles
• A visualisation of the process and identified user flows
• Possibly some light wireframes or mockups of the to-be solution
• Architecture design
• Cost estimates
• A plan to help go forward

In the end

Discovery does not remove the need to do planning and design during the project. Doing iterative design and planning throughout the project is key to ensuring that we go in the right direction and consider the findings we get during the journey. There are always assumptions in the beginning and if they are not considered properly, then they will transform into risks.

Still, a Discovery as it best is a small investment that is an easy way to validate if the project is really worth it. It generates concrete results in a short timeframe and contains clear deliverables that can be used to justify needed costs and speeds up the start of a development project.