by Chris Myhill
Director of Experience
Imagine that a client sends a project brief to a digital agency.
The project in question is a website redesign. The current site isn’t meeting their needs, and they’re looking for outside help. The brief they send contains a lot of information. It contains background, goals, and even a list of detailed requirements.
All the client needs is for their agency to go ‘make the thing’.
To anyone familiar with digital agencies, this scenario will sound fairly standard. In the past, the agency would have been expected to give full costs and timings straight away – from initial design, right up to deployment.
These details would (hopefully) be agreed, and the agency would crack on with the project.
To provide costs and timings upfront, the agency must fix the site’s complexity in this early stage. This is called “agreeing the scope”. It’s necessary so that a reasonable amount of development work is committed for the agreed price.
That makes sense. It keeps the engagement fair for both parties. The client knows what they’re getting, and the agency knows that they can deliver the website for the cost.
Here’s the thing, though. To agree on the scope and to provide a cost, developers need something tangible to base it on.
At this early stage, the agency doesn’t truly understand what they’re quoting. Any decisions made around what the site will (and won’t) do are informed only by the client’s original brief, and many assumptions that the agency will be forced to make.
Even if the client’s brief was exceptionally detailed, it won’t account for any new information uncovered once the agency gets started. And that’s a problem.
Agency-client collaboration doesn’t normally occur in earnest until after the project starts.
As the agency begins their work, they gain a better understanding of organisational goals and user needs. Stakeholders will raise important information that may have been missing from the original brief. Research conducted with users can bring into question how features and interactivity should be approached.
Design should reveal insights about the way things need to work. What use are these insights though, if we’ve already fixed the scope?
Seeing the product come together through wireframes and prototypes brings everyone onto the same page. It encourages feedback and discussion. It makes teams ask the important questions, and challenge their original assumptions.
These revelations can be fundamental to the product. In some cases, they can even be existential. We’ve worked on projects where user testing an early design prototype has made the organisation dramatically change the way things work. Once, a product was even scrapped completely, due to learnings from user feedback.
That’s the cool thing about design. It helps us get to where we need to be.
A good design process encourages a way of working where priorities can (and should) shift. Interactions can be rethought. It’s not until teams see and agree on a wireframe prototype that the project scope is understood in earnest.
A good design process encourages a way of working where priorities can (and should) shift.
Let’s jump back to the example we gave at the beginning. Because the agency agreed to a project scope before running any kind of Discovery Phase, the site’s requirements were fixed from the outset. The solution was predetermined before any kind of research, exploration or collaboration took place.
During the design process, the agency may learn that the best possible solution is actually different to that which they quoted for. This information has come too late, and it’s put everyone in a sticky situation.
If a fundamental learning changes the project scope from what was originally agreed, the agency may need to renegotiate costs and timings. This means that what was once promised can end up changing. It makes the client feel mislead.
If the complexity of a feature goes beyond what was originally understood, the project may go over budget. Having to constantly change the plan also creates unnecessary work.
When the scope is fixed before we truly understand things, it incentivises teams to ignore important discoveries. After all, avoiding the unexpected makes life a lot easier. It’s much simpler to crack on with the agreed scope rather than to revisit the plan, and have difficult conversations. In these situations the agency often pushes forward, knowing that what they’re building isn’t actually right.
This old way of working doesn’t accommodate the unexpected. When the unexpected inevitably happens, someone ends up losing out.
At Pixel Fridge, we’re big believers in the upfront Discovery Phase.
The Discovery Phase is a small, self-contained piece of work that takes place before the full design & build project. It gives us enough time to understand and plan the broad user experience.
By the end of a Discovery Phase, we’ll have :
We go through this process collaboratively with our clients. The interactive prototypes give everyone a shared understanding of how things will work, and provoke those all-important design discussions.
By conducting a Discovery Phase, we get clarity and agreement of the user experience.
Only then can we plan the project’s costs, timings and overall scope accurately.
The Discovery Phase removes uncertainty, encourages collaboration and drives better design decisions.
At first, the Discovery Phase can sometimes seem like a terribly frustrating notion to clients. We’re no strangers to a bit of backlash here.
“Why can’t you tell me how much it costs?” and “Can’t you just build the thing?” are common questions. On a complex digital project a Discovery Phase is crucial though, if we want to get things right.
For a small upfront investment, there are big benefits. It’s a chance for us, as experts, to challenge assumptions and suggest alternative ways of doing things.
It allows us to have a smoother client-agency relationship, by avoiding possible nasty surprises later on. Most importantly, it gives a more concrete vision of what we’re all working towards.
Another important way to view the Discovery Phase is as a ’trial period’ for clients to work with an agency. They can see how the teams work together, before committing to a much larger scope of work.
For us at Pixel Fridge, the main deliverable for a Discovery Phase is often a wireframe prototype along with a functional specification. Any agency could inherit these assets, and proceed with them. In most cases this ends up being us… but having options makes everyone feel a lot better.
It’s just another way of offering flexibility in the process.
Another benefit to the Discovery Phase is that we get a full oversight of the product vision, before planning the logistics of the build process. The knowledge gained in discovery can allow us to break down the delivery into more self-contained phases. These phases are based on an understanding of priority, along with any outside dependencies we became aware of.
Knowledge is power, and knowing these things in advance means that we can be more efficient in our work. It allows us to target earlier release dates, and save time in the long run.
It’s for all of these reasons that the Discovery Phase has become a crucial part of our approach as an agency.
It removes uncertainty, encourages collaboration and drives better design decisions. Simply put, the Discovery Phase represents a more efficient way of working.
It helps us to make better products with our clients.
30th June 2020
At times, getting direct access to your users can be tricky. In this article we discuss 5 ways to conduct audience research, even when you can’t talk to people.
16th June 2020
This week-long process for design and discovery is a great way to kick-start your project. Learn about how Design Sprints work, and when you should use them.
26th May 2020
Simply put, there are too many to choose from. At the end of the day there is no right or wrong answer.