Discovery

When an organisation employs a Design/Build Agency to deliver a Digital project; such as a CMS re-platform, website redesign or mobile app. The agency will typically suggest undertaking a ‘Discovery Phase’ before jumping into any Design work.

But what actually is a Discovery Phase? What happens during Discovery and why does your project need a Discovery Phase?

A ‘Discovery Phase’ is an intensive research period that is undertaken at the very start of a digital project, often by a mixture of people such Business Analysts, UX Designers and Technical Architects.

Throughout the Discovery phase, what the agency is essentially trying to understand from the client is:

• Where the client wants to get to (desired state)
• What exists today, in terms of systems, tools, processes (current state)
• What we need to know and understand to get the organisation to the desired state (gap)

As the multidisciplinary team of experts move through the Discovery phase, documentation is produced to capture all the key findings along with any follow-up actions that need to be further explored/answered.

These documents are typically stored within a central location (such as a wiki or shared drive) and made available to all members of the project team.

Such documentation typically provides answers to key questions such as:

1. Who are the current project team? And what are their roles / responsibilities.
2. What are the internal business processes? i.e publishing workflow
3. What are the potential risks identified and what are their impacts?
4. What is the project vision / goals and objectives?
5. What user stories / requirements are we looking to deliver against?
6. Who are the other external stakeholders and what is their role / responsibilities? I.e branding / SEO / content agencies

Documentation such as this helps to align all project stakeholders both within the client and agency around what the scope of the project is and what the desired end goal looks like.

Discovery Reduces Uncertainty

Ok got it… but why do we need a Discovery phase again?

In the early stages of any project, there is a lot of uncertainty. Knowledge gaps can exist within the organisation due to ‘Sioled working practises’, whilst cross departmental assumptions and a lack of a shared vision can create further stumbling blocks for the project if left undiscovered.

Depending on the severity of such issues, these can sometime have disastrous consequences to project timelines.

For example, let’s say a project team is tasked with building a Mobile App for a Clothing Store called ‘Feel Good Threads’.

In order to achieve the end user story of ‘being able to view product information’ the agency assumes product data is passed into the page from a Product Information Database (PID) via an API.

Should we find out 6 months into the project there is no API to extract information from the PID, or that no PID actually exists the consequences can be catastrophic.

However, if the team had undertaken a Discovery Phase at the start of the project this would have revealed the lack of a PID, allowing the organisation to justify a business case for building the PID first in order to enable the Mobile App Project.

Key takeaways here are:

1. Discovery phases help to provide purpose and direction to the project team and align all members around a shared vision. Not only that, they also help to highlight any potential roadblocks that could hit and derail the project later on.
2. A good agency doesn’t just build what the client asks them to build. A good agency should consider how the project fits into the clients current infrastructure and operational processes and provide recommendations on what changes / interdependent items need to be improved/updated to support the new.
3. Sometimes requests arrive to agency’s from an organisational Silo i.e. Marketing who aren’t aware of the current Technological infrastructure as they don’t communicate frequently with IT. In such cases Agency’s must be the ones to connect the dots to prevent the ‘Feel Good Threads’ scenario.
4. This is more common than you think… A recent survey by E-Consultancy revealed ‘40% of marketers admit that they are not adequately supported by other members of the organisation and that different departments have their own agenda’.

Waterfall and Agile

“We don’t do Discovery… we’re Agile!”

Nice try… If you’re part on an in-house development team, chances are you may not think you need a Discovery phase. Then again… someone somewhere would have done some discovery otherwise you wouldn’t know what you’re building.

A Discovery phase can be integrated into both Waterfall and Agile project management methodologies.

In Waterfall projects, the Discovery Phase happens at the very start of the project and can typically run for 4–12 weeks depending on the size of the project, the number of interdependent systems and the areas which need to be explored.

In Agile projects, you may run a Discovery Phase upfront to outline the purpose for the project and interconnect systems along with mini 1–2 week discovery process at the start of each sprint to gather the information you need to build out a feature.

Discovery and Design Discovery

So what’s the difference between Discovery and Design Discovery?

Design Discovery, is a smaller portion of the Discovery process. During a Design Discovery, UX Designers / UX Researchers are given time to explore specifically explore ‘who are we designing for?’ and ‘how should we design things?’

Let us use our ‘Feel Good Threads’ mobile app example again…

At this point we know we’re designing a Mobile App for a Clothing Store, however we’ve yet to explore HOW we should design the solution.

As UX Designers, before we even drop a pixel on a page we should have a number of burning questions we should want to ask both about the business and the end users.

I categorise these questions into 2 main groups:

Business / Project Focused

• Who is the client?
• What is their value proposition?
• What is the scope of the project?
• Who are the key stakeholders?
• What is the budget?
• What is the expected release date?
• What assets do the business currently have i.e. images / content?
• Does the business have a pre-existing style guide?
• What metrics will be used to measure success?

User / Solution Focused

• Who are the users were designing for?
• What are the key user problems/stories we are trying to address?
• What solution(s) exists today if any?
• How does the current solution Perform?
• What competitor solutions are there?

Informed Design Decisions

Getting answers to the above questions prior to starting the Design Phase is key to ensuring we set out in the right direction from the offset, informing design decisions around the size of the project and required design effort. Not to mention guiding design decisions on features, call to actions, colour selection, typography and more.

Furthermore, by understanding the above before we move through the Design Phase designers / project managers and other stakeholders can critique deliverables by questioning:

• Are we effectively communicating the value proposition?
• Does this solution appeal to our target users?
• Are we actively addressing user pain point X?
• How does the solution compare to competition solution A?
• Given X is out key KPI, do you feel there is enough emphasis on this CTA?
• How are these metrics being tracked?

TL;DR

A Discovery Phase should be undertaken at the start of any project. Its sole purpose is to reduce uncertainty by providing purpose and direction to the project team, as well as identifying any roadblocks that could derail the or impact the project if not dealt with accordingly.

I like to best explain the purpose of the Discovery Phase using my adaptation of the Design Squiggle by Damien Newman. See how the the Discovery phase allows us time to tackle the most uncertainty?

You can see here most of the uncertainty in the project is reduced during the Discovery phase. As we move from Discovery into Design, uncertainty becomes further reduced as artefacts such as wireframes and design mockups allow stakeholders to visualise and validate the end deliverable.

At this point, a clear focus is established. Here, everyone on the project team should be able to see how the initial brief and requirements have been shaped into a final deliverable along with how the interconnected systems come together to deliver the final solution.

There may be some small lingering items to confirm as we move into build however the build phase should literally be bringing the validated design to life.