Paging
- Next:
- None
- Previous:
- None
Referenced Concepts
- none
Referenced Techniques
- user interviews
- consolidating information
- learning in context in an apprenticeship style interview
- consolidated
- Interview these subject matter experts
Page Information
- page count / word count: 5 / 1460
- Last changed on: 4/13/2007
- Grade: D
- Type: concept
- comment on this page via email
User Profiles
Given and actor or user role we can profile that type of user by adding information about a variety of characteristics such as number of users, age ranges, computer expertise, or frequency of use. A user profile helps supply more relevant information from which to base design decisions and to better communicate that information to others who need to understand decisions made or make their own detail decisions. Build a profile from information acquired through research or captured from assumption.
An actor or role may be profiled by adding relevant information about the types of people occupying that actor or role.
Given an actor and goal or a user role we know a little about the user of our system, but likely not enough to run through a subset of design choices and make some decisions. It may help to add some details to our user such as age range, computer expertise, experience with the software they're using or process they're engaged in, the place they're likely using the software… and the list of information relevant to your design could be endless.
When we start to identify characteristics of our user, we begin to build a profile that helps us better understand that user.
Consider profile characteristics relevance to your design
There are a huge number of details we might consider about any type of user. Some of those details are more relevant than others to the design of your software. For example when designing software to support a business process, a characteristic like gender is likely not relevant. I suppose there's always an exception, but whether our user is male or female may not have much baring on their goals when using the software or how they might use it. However, if we're designing a consumer product that caters to specific market segments, how we design the product for stay-at-home-moms might be different than how we define it for sports-fanatic-men.
Most characteristics may have some baring on design, but some have more than others. For example frequency of use is a characteristic that is very relevant to an information kiosk in a museum that's likely used very infrequently by its target users.
For each characteristic you profile, consider it's relevance to the design choices you need to make.
For characteristics that have big impact, make sure the information you have regarding that characteristic is comprehensive and reliable.
Consider a variety of characteristics
There's a variety of characteristics you might consider. Here's a list, not comprehensive, but useful as a starting point.
# of people in this user constituency
How many people occupy this user constituency? This helps us understand the possibly diversity of opinions in the role and the impact of our design choices. Do our choices impact ten people, or then thousand?
General responsibilities or activities
What general responsibilities or activities might this person engage in when using the software? How frequently are some activities done relative to others? This helps us understand what activities the software might support, and which of those activities are more relevant. If you started personifying a user role, you might should find the role implied some activities this person engaged in order to meet the goals indicated by the role.
Computer skills
How skilled is this person using computers and software in general? Knowing this helps us select specific user interactions that will be learnable and usable by this user type and what tradeoffs we can make. For example if one possible interaction is inexpensive to implement but would be hard for beginners to use, knowing the primary user profile is expert allows us to use a cheaper to implement interaction.
Domain or subject matter experience
How much can the software assume this user knows about their business domain or the subject matter the software deals with? Is the software responsible for "teaching" the user and can we freely sprinkle the software with jargon and concepts understood by experienced people? For example "rack rate" is a term used in the hotel industry to refer to the published full price of a hotel room. You likely won't find that jargon used prominently in your favorite travel site since the site hopefully assumes we're not hotel industry experts.
Success goals
How does this user evaluate success? What success goals motivate this user to user our software? If we know what our user considers as success, we can evaluate if the software is helping this user achieve success. Software that helps the profile succeed will ultimately make them happy. During interviews I'll usually ask the interviewee to "tell me about a good day." I'll usually get a feel for what constitutes success from that answer.
Pain points
What causes this user trouble outside the software? What common trouble does the user hope to avoid by using this software? If we know this about our user we can evaluate whether the software is helping the profile avoid or more quickly resolve issues. During interviews I'll usually ask the interviewee "tell me about a bad day." I'll usually get an idea of what's painful from that answer.
Usage locations
Where will the user likely use this software? Is it a single place, or a variety of places? On what kind of device - desktop computer, notebook, iPhone? What constraints does this location bring to the software? For example travelers won't have always internet access. Users who spend a lot of time away from their computer won't have the ability to get on-screen notifications timely.
Software & tool ecosystem
What other hardware or software products does this user consistently use? Knowing this allows us to leverage usage patterns they may already be familiar with. For example if I use Excel all day, if you give me an application that works much like Excel, I may learn it faster than if it were more like something I'm unfamiliar with.
Collaborators
Who does this user work with or speak with on a regular basis? Does this user need to collaborate with someone to achieve their goals with the software? Knowing this we can evaluate how the software could help this routine collaboration.
Expected frequency of use
How frequently do we think this type of user will use the software we're considering? Given an understanding of the users’ likely frequency of use, we can determine how learnable the application needs to be. Applications used more frequently become familiar and users become proficient faster. Proficient users often need speed-keys or alternative faster was to perform frequent and familiar tasks. Alternatively users with infrequent use may be constantly re-learning the application. This means the software should be learnable and certainly not rely on training or memorization.
Profile characteristics come from research
If you've read this incomplete list of user characteristics you may be wondering how you're going to get all this information. There are a number of ways.
The most sound way is through research.
We might learn more about our users by conducting a series of user interviews and consolidating information across interviews.
Information can also be obtained by observing user during usability tests, conducting focus group discussions, or by learning in context in an apprenticeship style interview with your users.
We can also get information by conducting studies or leveraging studies conducted by others. You might get usage details by examining logs from existing software. You might also conduct surveys of your target users directly asking them questions.
The persona lifecycle lists some sources for research data - find those.
What does the research based usability guidelines say - are there details relevant to profiles - or mostly just interaction and visual design?
All of these approaches, and many I likely haven't thought of, yield valuable information that can be consolidated, distilled, and placed into relevant profile characteristics.
Profile characteristics come from assumption
Making choices based on assumption is often considered a bad idea. But we do it all the time. In fact our assumptions are often based on our past experience and observation. It's just that we may not recall the specifics of the observation well enough to label it "sound research." If your company is in the business of writing software for a specific business area or market, there's likely people in your company that know quite a bit about it. You may be even one of them. Interview these subject matter experts, or talk to yourself if you're the expert, and collect assumptions about your users to populate your user profiles.
When using assumptions to populate user profiles, make notes about those assumptions and the profile characteristics you've used them. For each characteristic, consider how relevant that characteristic is to the design. From here you can make a determination of how risky it is to use an assumption. For an important characteristic, one that might have big impact on your design decisions, you might want to replace assumptions with research.
Leveraging assumptions to create profiles is a quick way to get started. Replacing assumptions with research later helps you reduce the risk of bad design decisions without sacrificing pace too much.