Pick My Brain #004: Defining Project Scope

Today’s question comes from Vik Sharma, who is one of the 6,268 (!) students taking my User Experience Design Fundamentals Course via Udemy:

Q: I’d like to know how to go about defining scope appropriately: the “how” to explain the “what” discussed in this video. Are there specific techniques such as context diagrams or other examples?

A: Hi Vik, and thanks for the great question. The reason I stay away from showing concrete, absolutely specific examples is because despite what the self-proclaimed UX experts would have you believe, there is no one right way to do any of this. Project scope is dependent on more than just the mechanical nuts and bolts of what’s being designed or built. It’s more than technical or functional requirements. Project scope is affected greatly by multiple factors that don’t neatly fit into established processes: stakeholders’ emotional states and political stances, for example. Differences in departmental opinions, procedures, and risk levels. Industry regulations and changes in the law. The list goes on and on.

This complexity is what causes most UX folks to get stuck: They often try to use one specific method or process or tool that really doesn’t fit the situation at hand. Or they feel like they don’t know the right way, so they don’t deal with scope at all. The point I am trying to make clear in the course, and in everything I do, is that there is no right process or tool or method. It’s infinitely more important that you learn how to think and analyze all aspects of your situation and how it affects project scope. It doesn’t matter how exactly you do that: it just matters that you do it.

Here’s the thing I want you to keep in mind: every client, every project is very different. And as such it should be treated differently, right down to your approach, your method, your tools. The minute you say I’m going to apply this ONE process or method or tool to everything I do, that’s the minute you start failing. Because the information and insight you gain that way will often be more specific to the method or the tool than it is to the complexities of the user, the client, the competition, the environment, etc.

I have always maintained that formal methodologies and processes go right out the window when the rubber hits the road, so to speak. If for no other reason than the fact that every organization has its own internal processes, allowances, rules, regulations, etc. — all of which affect what you can do and what you can’t. Who you can talk to and who you can’t. What you can look at and what you can’t. That’s been my experience over the past 25 years.

Project scope is dependent on all the variables inherent in the situation, so don’t get attached to one tool, one method, one process: research multiple options in each area and adapt them to the situation at hand as needed.

Hope that makes things clearer — I wish you much success, and GIVE GOOD UX!