Designing for Novices & Experts, Part 2
Back in September 2016, I presented and published at the Society for Technical Communication. This is an amazing professional group of technical communicators and user-focused individuals who gather annually. Since I live only a few miles away from their 2016 summit location in Washington, D.C., it was a fantastic opportunity for professional growth and to share some ideas I’ve been working on regarding designing for experts and novices.
I’m writing this to break that talk down into something consumable for reading. In order to not overwhelm anyone, I’ll be dividing my talk into three separate posts:
- An overview of why it is important to design for experts and novices
- How to design for both (Keep reading, that’s this one.)
- My advice for how to design for both with some common dos and don’ts.
It is an hour’s worth of content that is being boiled down into written, digestible content chunks. These separate sections should make it easier to read. Also, there may be some sections you’d like to skip or spend more time on.
Before I get started, I’ll cover briefly why I’m credible to discuss this topic. I have 15 years experience in Human-Computer Interaction working on 8 to 15 products at one time. I manage a team of 5 user experience engineers and work in a larger product development team of 60 software developers. These programs present real-time visualizations of data being reduced, analyzed, and presented in subsecond-rendered interfaces. The products I work on have domain experts and also experts that have been using the same command-line interface for thirty years. In comparison, I also have to design for people who are fresh out of high school and have to come up to speed in a complex domain with little or no training. Designing for both is a regular balancing act that my team and I design for every day.
View my slides to see the whole presentation.
In my previous posts on this topic, I covered why it is important to consider both experts and novice users when designing. In this post I’ll cover how to do that. The solution is something that if you are familiar with User Experience, is a pretty tried and true method. If you aren’t as familiar with User Experience, have no fears: it is something that even a novice can do. It is…insert drum roll…Personas!!
User personas are fictional descriptions of prototypical users that are being targeted by the design team to ensure that key user needs are being supported. Personas usually include a name, age, gender, expertise, domain knowledge, and workflows. Personas have a way of making the spectrum of user types and background knowledge come to life and allow the development team to properly personalize tasks so that real users are more successful.
Before I get into how to use personas, there are a couple of myths that are worth breaking. It is definitely possible to spend hours and hours crafting personas. They can be very well thought out and crafted beautifully. If you have a product that is well into it’s prime, then your personas may be very detailed. However, in the end, they are just a thought experiment and never truly replace the value of talking with real users who have real values and opinions. With that said, I think that coming up with 3 to 8 personas is plenty. If you spend 5 minutes on each, then you are probably in good shape to start using them. Personas will be crafted, edited, and updated as you use them.
Let’s think about what contrasting qualities may be valuable to track to be able to design for both experts and novices. This means thinking through the types of qualities that are going to be of value when thinking about experts and novices. To do this, there are two types of qualities, binary and linear. A binary characteristic is one where the user is this or that. For instance, is the user color blind or not? A linear characteristic is one that has multiple discrete values. An example might be the amount of time that the person spends on their computer every day. With that in mind, the binary characteristics that may be of value would be:
- Considers self an expert in using the application
- Is a domain expert
- Their job requires them to use this application/website
- Has used advance features
Some linear characteristics may be:
- Number of days/months/years using application
- Age
- Education level
- Technical proficiency (How tech savvy are they?)
- Number of computers/devices/monitors they use, i.e., how distributed is their use across their day
- The number of touch points the application can make in the user’s day
- Where the user is in the learning spectrum. For example, if your application requires training to use, how far along are they in that training?
The qualities of experts to novices are not limited to those I listed above. Those that are listed are qualities I have used myself for different personas. Think about ways to brainstorm qualities that may impact how you would support your unique novices or experts. The purpose is to pick the qualities, and to then vary your personas to reflect those qualities. For example, you may have one user that is a novice to the application but is a domain expert. You alternatively may have someone that is older, but has many more touch points that someone who is younger (e.g., think about financial investment applications). By varying the personas, these hypothetical users can then serve as examples to walk through your workflows. They can allow you to design the entire application to accommodate experts and novices.
When designing a UI, think about your workflows and not your UI features. This is important because to create a user interface that will work for the entire spectrum of expert users to novice users starts with understanding the common workflows that they will both take. For example, all users are probably going to have a similar need to sign up for an account. This would be a common workflow for you to have both experts and novices encounter. However, there may be workflows that only advance users would encounter such as using complex boolean searching. Similarly, novices may be the only ones using your help documentation.
The list of workflows can then be used to assess which workflows are specific to particular kinds of users. The purpose of this step is for you to determine which UI features need to be designed for generic or specific user types. Take the workflows that you have brainstormed and then step through them using your personas. How does the persona of “Candice”, a working mom with only 15 minutes to spend on your application a day, differ from “Leona” who customizes every setting in an application before getting started.
We do this activity because expert and novices users are going to use different features and accomplish different task than “average” users. They are going to approach the UI with different mental models of how to be successful while using the application. The way to accommodate these different approaches to tackling the same goal is with these constructed user personas.
The power of personas is best demonstrated with an example. Zappos, an online shoe store, could have a persona for a first time user and single mom of three with a high domain knowledge of shoes. They could also have another persona of a young male return shopper with little knowledge of shoes. The use of these two dichotomous personas allow the design team to then step those two different users through different tasks. How would the mom search for shoes for weightlifting versus how would the young man search for dress shoes for a job interview?
By stepping through those workflows the team can assess which features have overlapping and conflicting user types versus which features are unique to a skill level. For example, the weight-lifting mom could use advanced filtering and search features and then want to compare two pairs of shoes in a side by side feature listings. In contrast, the young man could casually browse over a series of days and add shoes he is considering to his shopping cart while making his purchase decision. Both users would go through the same check out and quick search tools. However, advanced features such as filtering and side-by-side comparison might only be used by expert users. Whereas adding to and persisting items in a shopping cart may be unique to novice users.
Once the software development team understand the user types, start user testing your user interface by finding users that match your personas. Finding users that match the created personas is as easy as a short survey that can be included in your participation solicitation. Having between three to five users of each user type should demonstrate a valuable set of issues to discuss for improving the software. Rinse and repeat this method until no further design and usability problems are discovered.
I know this sounds easy, but it isn’t. User research is hard and messy… and sometimes it can be expensive. I would encourage you to keep your research light. Spending more than a couple of hours constructing your personas can be wasteful. Additionally, if you have incorporated this kind of user research into the process, this type of activity should be one that you return to regularly. For example, if you already have personas, but you have a new feature, you can apply those personas to that new feature without needing to validate with extensive user outreach. This wouldn’t be possible if you were starting fresh.
Just like healthy living: it is all about those good software development habits. In the end, it is all about recognizing that you are not your user. By conceiving of the spectrum of behaviors and traits that are going to impact your design, and more specifically by contrasting characteristics of experts versus novices, you are going to have a well rounded application that supports all of your users.
If you are interested in learning more about Next Century, please check our website below:
