Enthusiasm can be the death of us. Being a great designer isn’t enough to keep your projects on track and in budget; it’s vital that at some point early in the project – that you define the scope of that project. This is useful for many reasons including: your clients will know when you have delivered what you said you would, you will know when you have finished a project, it prevents “scope creep”, etc.
So how do you define the scope of a project? It depends but there are some simple questions that can help you work towards a scope:
What kind of site/product/application do you need me to design?
It sounds incredibly basic but you’d be shocked at the number of projects that start with no clear idea of the eventual output. If you can’t agree on this; your project can never succeed.
What’s the deadline date for delivery?
There’s only so much you can do in a finite amount of time. Knowing the time constraints helps you explain what can and what can’t be achieved.
What’s the budget for delivery?
If your client wants you to build them a rocket to take them to Saturn but has a budget of $25; there’s a huge disconnect between their expectations and what they can afford. Quite often budget will define what can and can’t be done within the scope of a project more easily than any other aspect of the scope.
What does your target audience look like?
UX pros know that without getting to know the user all design projects fail. If you don’t get the target audience down as part of the scope then you deserve to walk into a room with your client to find a group of angry pensioners complaining about the tiny font sizes you used when you deliver.
What should the project achieve for your business?
What does the client need the project to do? Sell more stuff? Educate clients? Reduce helpdesk calls? All of the above and more? This is perhaps the most important part of your project scope – if you can’t work out what it had to achieve – how will you or your client know if it is successful?
What content will be used within the project and where will it come from?
Products may need external content, they may need a lot of content created, where will that content come from? You may need to create it and that may change the scope dramatically from your perspective.
Of similar products out there – what do you like/dislike about them?
Get your clients to show you what they love and what they hate. It doesn’t matter if the end users love a project if the client thinks it stinks. Colours, design trends, etc. can often seal the deal.
One More Thing…
These questions are a starting point and not an end point to defining scope of a project. You should continue to ask as many questions as you need to in order to get the job done.
Don’t forget to write out your scope. Don’t be afraid to point out what won’t be done in a scope document either (e.g. “the client and I discussed doing XYZ but decided not to because it would be too time consuming/expensive”) as this can also help prevent recriminations at the delivery stage.
Scoping is part of a much larger discipline of Requirements Engineering. Alistair Sutcliffe has made his Requirements Engineering text book available online for everyone to read – check it out if you have time.
Header Image: Author/Copyright holder: Red Pill UX. Copyright terms and licence: All rights reserved. Img
