Words by Piers TincknellSeptember 26, 2018
At Atomic Smash we pride ourselves on the fact that we spend a good amount of time at the beginning of each project working with our clients to determine their requirements. We love working with clients who have big ideas and want to build something that hasn’t been done before. However, if something hasn’t been done before is that because no one has thought about it or is it not a viable idea? Part of our requirements gathering process can often involve working with clients to ensure that their big idea is a good one.
Once we have worked with our client to understand their needs and the needs of their users / customers and we have the big picture, then it’s time to start working together to define the specification of what we will build.
We have a thorough process that we run through with our clients to work together to understand what will be the requirements of the new project. This process works well for websites, digital products and also small projects within a larger website. The programme of work flexes depending on the complexity of the project.
Our main aim of running the requirements gathering piece of work is to understand a few things:
It might sound strange but you do not know what you do not know. This is critical to remember when working on a new piece of work. As soon as you start making assumptions it can really cause big problems further down the line. We always approach a new project with a real thirst for knowledge. We need to know as much as possible about everything to ensure we are not assuming anything.
Our ideal programme of work when working with a client to identify their requirements for a project contains the following. If you follow these steps and processes then you are likely to come away with a much better understanding of the requirements for your next big project.
This is an initial meeting to discuss the brief generally and explain the project in more detail. You need to involve the key decision makers in the project in this meeting. Starting off on the right foot is critical to the success of a project.
Here is an example of how a kick off meeting could run.
Our kick off meetings usually last around 2-3 hours. They are a great opportunity to field any questions and generally get excited about the idea of building something new.
After the kick off meeting then you can move into a more exploratory phase. This next stage involves running interviews and workshops to understand the specific needs of the users.
The next step is to start talking to people. After the kick off meeting you should’ve identified who you are designing for. You are best running a series of interviews to gather anecdotal evidence from users about what their requirements are.
If you are designing a new website for a museum then you need to interview the existing website administrators as well as people who use the website to visit the museum.
If you are designing an app to help elderly people order their shopping easier then you need to interview a typical user of your app, as well the shop owners who will need to interact with the app and the delivery drivers who will also be using the app.
It is best to speak to these people as soon as possible and be armed with some good questions to help you find out what you don’t know.
The questions for these interviews will always need to be tailored to your project. An example is if you were working on the previously mentioned shopping app aimed at older people:
We would suggest to try and interview between 3 – 5 people at a minimum to avoid any bias. We also suggest that you keep the interviews down to around 1 hour in length to avoid fatigue.
When you interview people be sure to get their consent and if possible make an audio recording as well. This will help you to reflect back on the conversation and make extra notes if required.
The aim of the interviews is to try and gather as much valuable information from everyone who might be a user of the project at some level. Of course you can’t interview everyone and you also only have a limited amount of time so be tactical about how you go about the task. Things you want to be making a special note of are any pain points or familiar stories that come out of the conversations.
After completing a series of useful interviews and you feel you have a good level of insight into your users, both customer side and organisational/business side, then it’s time to run some workshops to uncover more insights.
We love running workshops with our clients because it is a much more interactive and thought-provoking way of uncovering insights that just sitting around a table talking. Workshops get people up and moving about, interacting with each other and help keep people engaged.
Workshops can be run a number of ways but for us this general format gets the best out of people.
Typical workshop format:
Task 1 – Energiser. This task’s main goal is to break down any awkwardness and help get people used to the format of a workshop. Usually, during a workshop we will ask people to write things down on a post-it and stick it up on a board, so the energiser needs to get people to do this.
A couple of examples could be:
“Think of the last time that you had a negative experience online and write it down”
“Break your morning routine down into 3 steps and write them on 3 post it’s and place them chronologically”
The energiser should take no longer than 15 minutes total and ideally get people talking/thinking.
The next stage involves understanding the participant’s likes/dislikes.
If you’re redesigning an existing website or product then you can start to ask questions around this. Asking people to write down their top dislikes/likes and add them to the board. If you are working on a brand new product/idea then use this time to try and understand their feeling towards similar products/systems.
After the points have been noted down then spend some time again grouping these ideas into themes and discussing as a group to make sure you are clear of any recurring themes.
The next step in this workshop is to work with the participants to understand their goals. If you are running a workshop with the user group then it’s important to understand what they require from your website/product. What are their pain points? What do they really want to achieve by using your newly designed digital solution?
If the workshop is with the business/organisational owners then it’s critical to understand their goals and needs. Where do they want the organisation to be in 5 years time? What is their 10 year plan? Do they need to raise more money? Are they likely to change their model in the near future? Will they be exploring different countries quite soon? The amount of information you can uncover is limitless so again be tactical about the questions you ask.
The outcome of this part of the workshop is to collect a large number of goals, then as a group decide on the most important ones. It’s worth collecting all the goals because these can start to form the basis of the requirements for your project.
As with any good project it is useful to have a bank of user personas to work with. If you are not familiar with these please check out Megan’s blog post.
Once you have all the information above you then can start to paint a picture of your users’/organisation’s needs. User stories can form the basis for requirements of a project. User stories are great because they don’t limit you too much and allow the design/technical team to use the tools they deem necessary to complete the task.
The general formula for a user need is:
“As a (user) I need to (achieve something)”
Here are some examples of user needs.
“As a customer I need to be able to review my order after I have placed it”
“As a new subscriber I need to be able to edit my email address”
“As a staff member I need to be able to run an export of all users from the software every Friday at 4pm”
User stories are an evolution of user needs, to give more context.
The general formula for a user story is:
“As a (user) I need to (do something) so that I (can achieve something) therefore (extra requirements surrounding the task that are important)
“As an order fulfilment officer I need to run an export at 4pm on a Friday so that I can meet the deadline set by my publisher at 4.15pm therefore the export can’t take more than 5 minutes.”
These user needs and stories can really help you to get to the requirements of your project without the need to write an overly in-depth technical brief. As long as the user needs have been thoroughly explored then this group of tasks makes up the requirements for the project. It’s worth considering using a number of personas/users to generate these stories. If you just follow the stories laid out by the organisation then it’s likely the users won’t be satisfied and if you just follow the user needs then the business/organisation won’t be satisfied. Great work happens when both parties have the majority of their needs satisfied.
This is amazing, you have a huge list of requirements for your shiny new project. Everyone is super-excited and can’t wait to get started. However, reality hits and you realise that you don’t have an unlimited budget or infinite development resources to do everything that’s been noted down. (Both clients and design/development teams often forget that they don’t have unlimited time/money) This is where projects can go very wrong. Some people. The next step in the process is the one that really makes a difference when working on a digital project.
It’s time for a very critical part of the process, prioritising the requirements. We like to use the MoSCoW method for this. This is a simple system:
Must have – Mission critical, the project cannot complete unless we do this.
Should have – Very important but not 100% essential
Could have – Nice to have if there is time / budget
Would have – Not essential, the project can easily launch without this
We also like to add to this list an extra W for Won’t have.
We call it the MoSCoWW format.
Once you have listed all your requirements out into these labels then you have a really good format to approach your development/design team with and say “Here is what we would like, these features are essential.” The design team can then spend time putting estimates next to your tasks and then you can see what fits with the time/budget you have available.
If you would like some help / advice about planning your next big digital project