How We Conduct the Discovery Phase in Website Development
Written by Fransisca Smith
Table of Contents
- What is the discovery phase and why is it important?
- Kicking off
- Create working groups
- Define user personas
- Brand, character & UI
- Departmental buy-in
- User research
- Create job stories
- Integrations & technical considerations
- MoSCoW (must, should, could, won’t have)
- RAID Analysis
- UX and journeys
- Content Production
- Feedback from discovery
“We had a 95% sign-off rate of first draft designs in 2022 by refining our discovery process. That’s a huge achievement, especially for a small agency.”
What is the Discovery Phase and why is it important?
The discovery phase in website development looks different for every agency. For Crucible, the discovery phase is a crucial first step to any website design & build project. It comprises digital strategists, designers, project managers and stakeholders coming together to establish goals, requirements and features. The overall aim of the discovery phase is to establish a full, complete project briefing for everyone involved.
Back in 2015, our discovery process was far less robust. We were consistently seeing elongated and inefficient design and development processes as a result. Once we had refined our discovery phase, we saw a reduction in the number of rounds of amends clients brought back to us. We had a 95% sign-off rate in 2022 by refining our discovery process. That’s a huge achievement, especially for a small agency.
In this blog, we’ll take you through each step of Crucible’s discovery phase and talk about some things we learned.
Kicking Off
Every project has to start with a good kickoff meeting and this is a good opportunity for us to run through the following:
- Ways of working
- Stand-ups/rituals
- Communication (ie. email, slack)
- Points of contact
- Monthly progress reports
We’ll take this time to speak with key team members and stakeholders to better understand what their day to day ways of working and means of contact will be; whether this may be regular emails and catch-ups or more detailed progress reports.
💡 Aim: determine preferred ways of working with the client.
Create and speak to the Working Group
Once we are aligned on ways of working, the next step for any medium or large organisation is to create and speak to a working group. A working group is a group of stakeholders from around the business who contribute towards the success of the website project. This is either through their review and sign off, liaising with other colleagues, or through generalised project oversight. Generally, we will speak to one key working group, but this can vary from organisation to organisation. Some of the groups we may speak to are the following:
Project team/day-to-day stakeholders
These are the main contact points. This is usually 1-2 people and they are the people we’re asking all the questions to and those who are coming back to us with useful information, day-to-day sign off, organising meetings internally, and managing feedback.
Key stakeholders
These will be the senior stakeholders signing off on the project. We may not have as much contact with them day-to-day but they’ll often need oversight, and will be particularly involved at crucial points of concept and creative sign off.
Working group
In larger organisations, it’s often important that we have eyes and ears outside of the project team. A working group is going to be representatives of 5-10 departments that give us visibility in the organisation. They are the internal champions of the project (i.e. keeping everyone across the organisation interested, especially in longer projects). They’re also the group bringing broader ideas, interests, and domain-specific knowledge to the project.
Importantly, working groups heavily legitimise the project’s outcomes. If there ever exists any doubt from less involved stakeholders about the effectiveness of key deliverables, the working group’s involvement and enthusiasm for the project and its outcomes will be able to reassure and clarify the reasons behind key decisions that were taken. Throughout, the whole organisation will be able to look towards the working group as representing their major interests and determine that all of the requirements were met.
💡 Aim: establish key stakeholders and create working groups to gather fresh perspectives from the individuals involved.
Define User Personas
Next, we’ll work with the project team and some of the working group to define a set of user personas. User personas are the key target users who will be interacting with the site.
At this stage of the discovery phase, we want to understand their general demographics, motivations, pains/gains and what they hope to achieve on the website. Starting with users in this way is vital; it ensures that the rest of how we view the website project is through the lens of the users visiting the site.
If you’d like to learn more, we’ve written a detailed blog on how to map user journeys and why they are effective here.
From here we can gain a better understanding of the brand’s iconography, visual identity and overall ‘feel’.
💡 Aim: to define a clear set of 3-6 key user personas.
If you’re interested in learning more about Crucible and how we work, get in touch for a chat with someone on our team.
Brand, Character & UI
When we work to establish the look and feel of a website, we are quite often making key decisions with a client as to how their branding will be executed online. As a website is one of the most permanent and modern expressions of a brand, the web design process will apply new thinking, principles and applications to any visual identity, no matter how established.
A well-designed user interface makes it easy for visitors to navigate to the information they need and accomplish their goals, and the modernity of this is vital to establish the leading position of any brand.
To answer this need we have designed two proprietary workshops that allow our clients to express their UI and creative positioning clearly, and with reference to existing websites, they’ve seen. We work with our clients to position their current and future websites against those of competitors, similar and adjacent brands. Sometimes, we’ll bring to bear websites from entirely different sectors, if they are a suitable reference for a client’s project. The outcome of these sessions means when a design is first shown to our client, it is almost never a surprise – or at the very least, not an unpleasant one.
💡 Aim: agree on 2-4 UI and creative references that suit the brand’s overall look and feel.
Departmental Meetings
At this stage, we have covered the basics of how we will approach the project however, we might still be missing key aspects of the brief. This is where departmental meetings become critical.
Our goal in this phase of discovery is to speak with any department heads who have a vested interest in the website, such as marketing, finance, operations, customer service/success, and senior management. These findings will then feed directly into our creation of Website Job Stories, as it is important to capture all departments’ requirements for these to be comprehensive.
💡 Aim: to speak with all relevant department heads to select any areas we may have missed or need to highlight.
User Research
Up to this point, we’ll have made a number of assumptions and internally-led decisions as to how the website should function and look – and the needs of the users it serves. It’s important that we look to validate these assumptions by conducting user research. This can be in the form of questionnaires, surveys or interviews. It helps to reassure both the client and our strategists that the decisions we make are the correct ones to serve users effectively.
In order to get the most relevant insights into the website, we prefer to speak to real users – the people who are currently (or will be) using the website. However, this may not always be possible as we will need to be adaptable depending on budget and time restrictions – and sometimes, for a new product, users won’t yet exist. In these cases, we roleplay with our client’s team to ensure we’re getting as close a view of real customers as possible.
💡 Aim: to validate decisions and assumptions by speaking to real users.
Define Job Stories
What are job stories and how to use them
We’re now ready to tackle the foundations of the project. This is where we introduce job stories. From having met with the client’s team to define personas, and having a full and comprehensive rundown of their departmental requirements, we are now in a position to handle the most important task of discovery: defining job stories.
Our goal with job stories is to create a clear picture of how the website will serve specific target users. To do this we need to define the situation, motivation, and outcome for every task that every type of user (including website administrators) could want to achieve on the website.
It’s a big task, and larger websites will often have 100 or more stories, but it’s essential to have these as a reference point when building the website sitemap and information architecture. It also serves as a means of us creating project tickets for our teams to plan around and follow, and it serves as acceptance criteria at the end of a project: if a website fulfils all its job stories, the agency has fulfilled the functional brief. A good website isn’t just a collection of pages; it’s making sure there is a clear way to achieve each task required of it and a reason that every page exists.
Once we are happy with what we’ve defined, we will then bring it back to the client via a collaborative job stories review, where we aim to sign off this scope.
💡 Aim: to have built (and signed off) the foundations of the website through a series of job stories.
Integrations & Technical Considerations
During the early discovery and job stories definition process, we are aiming to become aware of all of the technical requirements of a client’s website in terms of their end functionality. However, we will usually need to engage with the client’s internal technical teams to fully understand the specifics of any technical integrations with other systems.
With a clear understanding of what we’re trying to accomplish and how users will navigate the website, we will meet with the client’s IT team or provider, operations, logistics and any other relevant departments again to ensure we are all on the same page with which integrations will need to be included in the build, the systems they run on, and how we will need to achieve these integrations.
Our development team will benefit from this part of the discovery phase as they will be able to gather as much information as possible about each integration and third-party system required for the build. This includes gathering and reviewing API documentation, determining the most appropriate methods for each integration, and ensuring they have fully scoped the time required to complete each technical functionality of the site. Depending on the number of integrations, the size of the website and how cutting-edge the build is, we may use part of our discovery period to build a technical sandbox. This is to test any novel functions or software, before design and full scope sign off take place.
💡 Aim: to empower our developers with the information they need to be successful with the build including all integrations and technical considerations.
MoSCoW
We now need to prioritise items via the MoSCoW method. The MoSCoW method is a popular approach to prioritisation in project management as it helps prevent scope creep and solidifies expectations around project outcomes. Using this framework, our team will have a clear roadmap of tasks to deliver in the order of priority, with the authority to de-scope certain tasks to backlog status if required. The priority levels are as follows:
- Must have: these are non-negotiable and will be required for the delivery of the project.
- Should have: these are not vital but do add significant value.
- Could have: these are either not essential, or restrictions exist due to client dependencies, and aren’t expected to be part of the scope, but some could conceivably be added in.
- Won’t have: these are either not important nor will be included for this project or upon reflection, the client may have decided these functions aren’t right for the business.
💡 Aim: to have a list of items prioritised via must-have, should have, could have and won’t have.
RAID
For projects to be successful and delivered on time, we opt to complete a RAID log which is a project planning technique to identify Risks, Assumptions, Issues and Dependencies. Completing a RAID log helps us to lessen the impact of any problems that could arise during the project.
This is a crucial step in our discovery phase as it ensures all teams are aware of any potential issues and the actions being taken to solve them. It also ensures that should these risks materialise and become issues, we have a clear action plan to resolve them. A RAID analysis follows the following four steps:
- Risks – potential issues or threats that may have an adverse effect on the project.
- Assumptions – areas of the project with incomplete information, where assumptions are currently being made – which could be found to be incorrect at a later date.
- Issues – events or risks that have arisen during the project, and should be recorded and mitigated against any negative effects thereof.
- Dependencies – events or tasks that are linked together (ie. when something can only be started on the basis that something else has been completed).
This RAID log becomes a living document. It is updated and refreshed on a fortnightly basis with the client throughout the project.
💡 Aim: complete a RAID log to mitigate potential project issues and risks.
UX and Journeys
From the data and research gathered above, we now look at specific areas of UX interest on our websites. For most small and medium-sized websites, exhaustive UX research isn’t usually desirable. Instead, we focus on key areas where UX questions may exist. Depending on the size of a project, this could be numerous sessions, but for most medium B2B websites, there are usually 2-3 key areas of UX focus where decisions should be made against practical wireframes, thinking about the journeys a website’s users will take.
We’ve written a detailed article on what user journeys are and why they are essential to your site.
💡 Aim: to have a set of defined user journeys mapped and optimise the touch points of each journey.
Content Production
Now that the bulk of research and thinking has been completed, we focus on content – a project area that Crucible isn’t as often asked to own, which can therefore be overlooked. There is no ‘one size fits all’ when it comes to content but Crucible aim to work with our clients to provide the support they need to work on reorganising their content, and getting it up to date and published on their new website.
We’ll discuss any additional content required and introduce you to our talented team of copywriters and digital marketers who can help you with Copy, SEO, PPC and SEM. Where asked to provide more support, Crucible can spearhead content production from start to finish.
💡 Aim: provide support and direction for any additional content production required for the project.
Discovery Report Production and Feedback
At the end of any discovery phase, we produce a detailed report with the findings and outputs from the process. Before we can begin work on the project, we ask our clients to read it through in detail and give feedback on our findings or sign off on the report we’ve produced.
The aim of this report is more than just recording the inputs – it means we can be assured that our clients have understood the process ahead and what we’ve taken away from discovery. In some cases, it also allows the client to seek additional competitive tendering at this point, with a full, detailed creative brief formed by this report. More than anything, though, this report is to instil confidence that we understand the client’s business and are well-equipped to dive into the subsequent delivery phase.
💡 Aim: to have answered any questions or concerns off the back of the discovery and to have in place a set of approved next steps.
Crucible is committed to delivering successful website projects on time and within budget. We ensure this is done by implementing our extensive discovery process as the first step. The next stages of website development involve designing sitemaps and wireframes; you can find out more about what’s next on our blog.