Please enable JavaScript.
Coggle requires JavaScript to display documents.
Chapter 6 - Finding the voice of the user (The Product Champion (When does…
Chapter 6 - Finding the voice of the user
User Classes
What is user classes?
Rather than thinking of “the user” in singular
spend some time identifying the multiple user classes and their roles and privileges for your product
most products of any size appeal to a diversity of users with different expectations and goals.
Classifying Users
Differences of User Class
Their access privilege or security levels (such as ordinary user, guest user, administrator)
The features they use
Their application domain experience and computer systems expertise
Their native language
The tasks they perform during their business operations
Whether they will interact with the system directly or indirectly
The frequency with which they use the product
The platforms they will be using (desktop PCs, laptop PCs, tablets, smartphones, specialized devices)
Way to identify user classes
To think about the tasks that various users will perform with the system
Certain user class could be more important than others
Each user class will have its own set of requirements for the tasks that members of the class must perform
User classes need not be human beings
Identify your User Classes
technique :point_right::skin-tone-6:“expand then contract”
Start by asking the project sponsor who he expects to use the system.
Then brainstorm as many user classes as you can think of
Don’t get nervous if there are dozens at this stage; you’ll condense and categorize them later.
It’s important not to overlook a user class, which can lead to
problems later when someone complains that the delivered solution doesn’t meet her needs.
Next, look for groups with similar needs that you can either combine or treat as a major user class with several subclasses.
Try to pare the list down to about 15 or fewer distinct user classes.
Document the user classes and their characteristics, responsibilities, and physical locations in the software requirements specification (SRS) or in a requirements plan for your project.
User Personas
What is it?
A persona is a description of a hypothetical, generic person who serves as a stand-in for a group of users having similar characteristics and needs.
a description of a representative member of the user class
What does it used for?
You can use personas to help you understand the requirements and to design the user experience to best meet the needs of specific user communities.
A persona can serve as a placeholder when the BA doesn’t have an actual user representative at hand.
What does it include?
preferences
annoyances
behaviors
social and demographic characteristics
What does it based on?
ethnographic research
demographic
market
Make sure the personas you create truly are representative of their user class
The Product Champion
Who is product champion
Each of projects included a few key members of user community to provide the requirements.
What does he do?
Each product champion serves as the primary interface between members of a single user class and the project’s business analyst.
Ideally, the champions will be actual users, not surrogates imagining themselves to be users
Product champions gather requirements from other members of the user classes they represent
and reconcile inconsistencies.
When does the approach work best
The product champion approach works best if each champion is fully empowered to make binding decisions on behalf of the user class he represents.
If a champion’s decisions are routinely overruled
by others, his time and goodwill are being wasted.
However, the champions must remember that they
are not the sole customers.
Problems arise when the individual filling this critical liaison role doesn’t adequately communicate with his peers and presents only his own wishes and ideas.
External Product Champions
Product Champion Expectation
Multiple Product Champions
Connecting with User Representative
Who is User Representative?
Every kind of project needs suitable representatives to provide the voice of the user
These users should be involved throughout the development life cycle, not just in an isolated requirements phase at the beginning of the project
Each user class needs someone to speak for it.
Resolving Coflicting Requirement