UX — Scope (Part 4)
Scope is the place where we translate user needs and business objectives into specific requirements for what content and functionality the product will offer to users.
This is a long series of tutorials. We are going cover:
Strategy defines strategic goals(both product objectives and user needs), while Scope defines the features and content requirements that will fulfill these strategic goals.
Why to both yourself with defining the Scope
Know what we are building
It gives a clear description about what we are building, and how it related to our goals. and Yes, we can’t define a scope with 100%, and say this is exactly what is going to be, because new things are going to come during the project, but, if we defined boundaries of what you can and can’t do in the Scope, it will be much easier.
Address conflicts
Defining scope makes us to address potential conflicts, and the bottlenecks from implementing the features before design and development.
Reference point
Defining scope gives a reference point for client and developers about the work that’s going to be done. Documentation of the Scope doesn’t have to be a novel, but a common understanding of the features, schedules, and milestones puts everybody on the same page, and gives them a common reference.
It also gives a common language for talking about that work, like when you say “job vacancies search form”, now everybody knows what you are talking about.
Explore connections
Defining scope gives enables you to see connections between individual requirements that wasn’t clear, and organize related requirements, which may help then in determining which structure is appropriate for your product.
Assign Responsibility
Having a defined set of requirements allows you to assign responsibility for the work, so no body will have a conflict about who is responsible for what tasks.
Keep track of new features
More features are coming during the project. Because there is information coming to the light and So, suggested changes or new features should also be documented.
What to tackle now and what has to wait
Having a list with set of features to be implemented can help in determine which features can be done now and which has to wait until the next iteration.
Functional and Content Requirements
We start by generating the requirements, negotiate, prioritize and finally we document the requirements.
Generating Requirements
Some requirements apply to the product as a whole, such as supported browsers and operating systems, while other requirements apply only to a specific feature. The level of detail in your requirements will often depend on the specific scope of the project. The complex, the more detailed.
The source for requirements will be the users along with the stakeholders. The techniques used in the Strategy for research can be used here to help in generating the requirements. The requirements that will be generated will fall into three categories:
Things people say they want
Either people try to remember their past use for the product, or speculate about their future use. And the problem is, people make false predictions about their future behavior, especially when presented with something that’s new and unfamiliar.
Things people aren’t actually want
Sometimes the things people say they want are not the things they actually want, because when people have troubles with a process or a product, they try to imagine a solution, but not all solutions are feasible.
Things people don’t know they want
When people talk, they may hit upon great ideas that nobody said before. These ideas often come from brainstorming sessions.
What users say they need, is not always actually what they need, because maybe they are guessing about something they’ve never tried before. There is no way to know what people actually needs verses what they say they need, unless we try to figure it out, like by observing their behavior in their daily life.
Generating Requirements Takeaways
Requirements can’t be gathered
Requirements can’t be gathered, requirements have to be generated, and created through discussion with users and all stakeholders.
Clients won’t give all requirements
They won’t give all necessary requirements, because they don’t have it, so part of your job is to collaborate with them to generate that requirement.
Requirements shouldn’t be based on opinions or preferences
Much of what provided in requirements will be based on personal opinions or preferences. Even if it’s applicable, it doesn’t mean it’s the right thing to do.
Observe users behavior
Because what people say they want is not always what they really want, and what they say about what they do, is not always what they really do. So, we need to observe their behavior in their daily life, this will give us information about what we need to do a lot more than through discussion and guessing.
You duty shouldn’t be to take orders
Designers, developers, project managers are here because they have a degree of expertise and knowledge. So, it’s our job to apply our experience and knowledge to figure out what the requirements should be. This will help the clients to get the right solution and achieve the user or business goals.
Focus on the need, not the solution
Strategy are needs, features are solutions. Needs are often combined with solutions because people often communicate their need by suggesting solutions instead of saying their actual need. So, focus on the need first then come up with solutions through discussions, because you can’t know if a feature is relevant, appropriate or valuable until you know the actual need for that feature.
Requirements Negotiation
During generating the requirements, we negotiate. The aim of negotiation is to let everybody to say what he think it’s important to be considered, resolve conflicts, and deices on the requirements that will be documented.
The best approach to resolving a conflict between stakeholders is to engage, and look back to the defined Strategy.
During negotiation, there will be trade offs. So, we negotiate on which one is more important, compromising with the one(less important) to implement the other(more important).
Requirements Prioritization
During, or after generating the requirements, we prioritize. Sometimes one requirement can be applied to accomplish multiple strategic objectives, and also one objective will often be associated with several different requirements.
Here, we define what gets included in the set of requirements, and now(for current iteration), and what has to wait. So, to know that, we can ask these questions:
- Does the requirement fulfill a user need
- Does the requirement fulfill a business goal
- How feasible is the requirement, can we design, build and test it under current time constrains, resources and budget.
- Are there any potential conflicts
Any requirement that’s not aligned with project goals(either business or user), is out of the Scope.
Requirements Specification
Requirement Specification is divided into features and content. With no-documented requirements it will be a mess, as everybody needs to have the same understanding about the product, and what we are going to build.
Functional Specification
It’s the requirements about the functions, or features in the product, how features work with each other, and how they interrelate with each other.
Content Specification
Content refers to text, images, audio, and video, and different content types can work together to fulfill a single requirement, like having an article with text and images.
Writing effective requirements
Be positive
Instead of describing a bad thing the system shouldn’t do, describe what it will do to prevent that bad thing. As an example, negative statement: “the system won’t allow the user to do X without Y”, while positive statement: “the system will ask the user to do Y if he tries to do X”.
Be specific
Requirements should be clearly defined. As an example, not specific statement: “the system will display the most popular movies”, while the specific statement: “the system will display videos sorted by the most views”.
Don’t be subjective
Subjective keywords means keywords based on or influenced by personal feelings and definition. As an example, subjective statement: “the site is be cool”, while the non-subjective statement: “the site will have looking according to the company guidelines”.
Things to consider when dealing with Content
Content Source
The process of generating content requirements starts with identifying and validating content sources. Identifying the content source will allow you to identify the inappropriate content, like when the content coming from a source, people don’t care about, or it’s no longer true.
Content format and purpose
Content format is what you want to build(i.e. FAQ), and it’s purpose, which is easily access to commonly asked questions.
When the focus is on the format, the purpose can be forgotten, like when users ask you to make an FAQ, and they forget about why it’s here in the first place, that’s why user may go to the FAQ and it doesn’t really help him to do anything.
The size of content
What is the size of each feature, like word count, dimensions of images, are there multiple sizes of images, what’s the bandwidth for images and videos for streaming.
The resources needed
Identifying all the content types associated with a feature can help you determine what resources will be needed to produce the content.
Who is responsible for what
Who’s responsible for writing articles, taking & editing photos, audio and video, and where we will store them.
Content should support user and business goals
Is the content relevant to the reason that people have to come & interact with out product, Is it aligned with and support the overall goals and needs.
Content should appropriate
Is it appropriate for target audience, and representing who we are, and what believe in, what we offer.
The degree of relevance and appropriateness depends on:
- Method of delivery: is the content just text, animation, audio and video, or combination of those.
- Style and structure: is the style consistent with the message we want to deliver, and for the structure, what’s the way the content is organized, categorized, prioritized, …etc.
- Substance: is the information is valuable, meaningful to the users.
Content should be contextual
People are going to be in a specific context while interacting with out product. So, there are some considerations to be taken into account:
- Physical: What’s the user is doing, or activities while interacting with the product
- Emotional: How is the person feeling while using the product
- Cognitive: What’s the mental ability required to learn about the website
These considerations influence how users absorb and perceive the content.
Content should be user-centered
Content should revolve around the user perspective. So, does the content …
- Reflect what the user care about most, versus what the organization care about most.
- Match our abbreviations with the terms and phrases users usually think about, versus using acronym and abbreviations of the company.
- Focusing more why does this product matter, valuable, for the user, versus Content is all about us, there is nothing to say what’s in here for the users.
If the design and development phases proceed without identifying content and their sources, the product will fail.
Symptoms of not properly defined scope
Slipping deadlines
When you miss a deadline, one after another, that’s the sign of bigger things are going to happen, and you are in troubles.
Too many questions
When people involved in the project are confused, and asking many question, like if they can do or add something(i.e. feature) or not, this is a sign that those people have no clue about what the Scope is, and they don’t have a clear vision for what they are trying to accomplish.
Unimpressive release
When you make a release, and it doesn’t seem that you made a remarkable impact & valuable features, so there isn’t much progress you made. This is usually because the Scope is too small.
Unrealistic expectations
When you will be expected to deliver many features by the next week for example, and there is no way you can do it. This is usually because the Scope is too big.
Avoid scope creep
Scope creep means when additional features, ideas, are not only keep coming up, but, they don’t seem like much extra work.
So, when you go to implement each of these feature, as each won’t require much effort and time, by the time, when you put all of these features together, you will end up having a big snowball hitting on your head, and you will find yourself slipping deadlines, and problems with budget estimates, and you are on way to crash.
Trade offs
Trade offs are the possible choices we have. Identifying trade offs, comparing between them and which choice is critical to the value we provide, and the business needs can have an impact on the overall outcome.
As an example, in the real life situation, you may either continue your education and earn an advanced degree in two years(which in turn increase your chances in finding a good job with high salary later), or find a work and spend these two yeas earning money.
So, it’s clear you may ignore things in order to gain other things.
Product evolution
How the product going to change, evolve over time, and remain relevant. This could be by providing new experiences and impress the customers from time to time. The level of value and usefulness you are providing should grow by the time.
As an example, you may have a product, and you keep adding useful features that adds value, delivering the right thing at the right time, and meet the un-met customer needs.
There is an approach called “The Long Wow”, which is a means to achieving long-term customer loyalty through impressing your customers again and again.
