What Makes a Great Usability Person?
A few years ago, I needed to integrate a batch of new hires into our existing usability group. I wanted to start these new employees off successfully and make our now larger group work most effectively. With apologies to Stephen Covey, I drafted my advice to those new hires as a riff on his “Seven Habits” concept. Based on my years in the industry, and what I’d learned from many skilled colleagues, these were the skills that I’d seen serve usability professionals well in a variety of situations.
The Seven Habits:
- Know your customers.
- Know your group’s mission.
- Always start with tasks.
- Know core usability methods.
- Work collaboratively.
- Don’t slow down development.
- Reduce organizational whitespace.
Habit 1: Know Your Customers
Obvious, right? We do user-centered design, so we had better know our users. But, I’m intentionally using the word “customer” and not “user” here in order to make a point. Every usability person has two sets of customers:
- External customers who may include users, purchasers, and other adjacent stakeholders
- Development teams
A usability person can do the best possible job of collecting perfect user information, and designing a beautiful interface that resolves every possible pain point, but still fail to have an impact unless they understand the development team that has to consume their usability data and implement solutions. If the development team doesn’t understand or value your contribution, your ideas won’t make it into the product.
Every company varies in how they approach development. For a usability person to be effective, it’s crucial to apply your analysis skills to the problem of what your teams need. The following are some of the questions you should answer:
- What’s the company culture? (What motivates employees? What are people held accountable for?)
- What are the key business drivers? (Do we want a perfect solution that ships in two years or a pretty good solution that ships in six months?)
- Who really decides what ships? (Is it the person developing the beautiful spec? Or the junior engineer who is the last person to tweak the code before it goes out the door?)
Why does all this matter? Learning about your teams and who you need to influence helps you think through how to communicate effectively with those teams.
Habit 2: Know Your Group’s Mission
Usability groups often provide a spectrum of services from user research, usability testing, and design. When faced with the in evitable problem of too much work, you will be better able to prioritize if you know what your organization expects are your core responsibilities.
In most companies, usability groups share responsibility for some work with other groups. For example, interaction design can be done by user interface developers, product managers, or business analysts. It’s really critical to know if you share responsibility or if you own it, and not confuse your role. Why? If you own the design, you need to focus your efforts on making sure you have communicated your design effectively so teams can do it right. If you are a contributor or reviewer to a design, then you need to make sure that you know when and how you get to influence the design so that you can maximize your impact.
Sometimes, usability groups lose sight of the fact that they are almost always the only group that does usability testing. Because we know that testing is often too late to influence design, we rightly work to get ourselves upstream in the design process, and sometimes that means we run out of time for testing. But the organization depends on us to do testing, and if we don’t do it, it generally doesn’t get done.
I think most usability professionals agree that failing to ensure a product gets some testing is doing a disservice to both their companies and their users. But please don’t lose sight of the incredible value the visceral experience of testing has on convincing teams of the value a usability professional can bring. In many cases, skeptical developers become your biggest advocate after seeing a usability test. Don’t be too quick to give up this opportunity.
Habit 3: Always Start With Tasks
What’s a task? It’s usually a simplified goal statement that sounds something like “the user needs to compare images from two different satellites.” Another way to think about (and use) them is as high level usability testing tasks.
Tasks can ground all user-centered design work. Every usability activity should start with a consensus discussion about who the users of a feature are and what their tasks are. If the team can’t name users or tasks, they don’t know enough to start designing. If you don’t have consensus on these issues at the beginning of a project, every subsequent discussion will deteriorate into an argument over these points.
Tasks are cure-alls for problems throughout the user-centered design process.
- What features should you include in a prototype? (If you can’t connect a feature to a task, it doesn’t belong in the prototype.)
- Don’t know where to start a design? (Go back to the task, and think about the first thing the user needs to do.)
- Stuck on a design? (Remind yourself what the user is trying to do, and think about their next step.)
- Is the team arguing? (Review the user and the task and make sure the problem isn’t a fundamental disagreement about what you are trying to accomplish.)
Habit 4: Know Core Usability Methods
While every good usability person should have a variety of methods in their virtual toolbox, certain methods will become standards at each company. Over time, having a set of “regular” methods you use has two implications:
- You don’t have to re-teach the basics to each team. They’ll develop a level of skill of working with you on that method.
- Teams will come to expect that those methods are “usability.” If you decide not to use the core methods, you’ll need to educate teams about why you are recommending different options.
At MathWorks, we rely heavily on methods that are quick, cheap, and collaborative. Our most basic core methods include paper prototyping, team data collection with Post-its® notes, and affinity diagramming for test debriefing and prioritization.
In addition, we have a generalized process for user-centered design that includes the following steps:
- Answer these questions:
- Who are your users?
- What are their tasks?
- Why are you building this?
- Use these design tools:
- Sketch and design review
- Paper prototype and usability test
- Usability test close to final code
With this shared understanding, most of our usability staff bring a consistent approach to their method choices. In turn, teams develop a similar mental model that shapes their expectations of what to will happen when working with usability staff. This can save time for usability staff, who then don’t have to start each new conversation from scratch.
You’ll need to think through what methods work well for your company.
Habit 5: Work Collaboratively
It’s a rare usability person who actually codes their design. If you don’t code, then someone else is taking your advice or implementing your designs, and you depend on a cooperative and collaborative relationship with your development team. To be effective, you need to ensure that you are getting buy-in from your team at key stages in the development process.
The development team should be involved in
- researching users (so they understand and agree on the more important users),
- identifying design goals and user tasks for the project (so you and the development team are working toward the same goals),
- writing or reviewing usability tasks (so they agree you are testing the right things the right way), and
- participating in design activities (so they feel ownership of the design).
Most usability people have a set of great collaborative research and design methods in their personal toolboxes. Activities like sketching, paper prototyping, workflow analysis, and usability testing are all well suited to be conducted collaboratively with a cross-functional team, and especially key developers.
Collaborative tools yield a number of important benefits beyond the created design. Involving multiple team members in the design provides a means to get more ideas from more people, and draw on technical insights from the team, who may have more specific knowledge of the domain. Team members working together on design get to hash out their ideas about requirements and design during the design activities, and not after implementation has started. Finally, active participation in design creates a feeling of ownership in the outcome of the design process.
In this context, it’s worth considering the cost of high-fidelity prototypes. Fireworks or Illustrator prototypes often look amazing, but they get in the way of collaboration. Most times, design with these tools is done by one or two people working alone. The tools don’t lend themselves to collaboration. Having one person develop a design means that you lose the benefit of multiple team members sharing knowledge and developing a sense of ownership. It’s often difficult for anyone other than the original author to modify the designs, which again, keep other team members out of the design process.
It’s a great idea to start with sketching, and stick with collaborative methods as long as possible.
Habit 6: Don’t Slow Down Development
Skeptical development team members claim usability “takes too long” as a way of creating barriers to participating in our activities. Effective usability people find ways to work efficiently and fit in to available time.
Start with Habit 1: Know your customers. Understanding how a team works and the goals of their project gives you critical information for scoping your effort.
Make yourself easy to work with. Relentlessly improve your communication skills. Hone your active listening skills to make sure you are hearing what the team is saying, and do what you can to test if team members understand what you are saying to them.
Look for techniques that work for a particular team. Most teams are busy: showing empathy for their limited resources and conflicting priorities will help them believe you understand their constraints. It’s also helpful to look for low-hanging fruit (easy design fixes) in relevant parts of the product to address, and focus your efforts on those (for example, if there is no plan to fix the installer in this release, don’t spend time working in that area).
Don’t make teams wait for you. Be very sensible about slowing down meetings to make a team explain something to you. Choose carefully about when to push a topic (“now when would the user do that?”) versus when to take the issue off line (because you don’t understand some technical detail).
Finally, remember you are a service provider, and a great service provider does what their customers need, not necessarily what they ask for. Team members tend to ask usability people to deliver specific solutions. It’s the usability person’s job to push back through that request to understanding the real, underlying need. Imagine for a minute a patient approaching a doctor and asking to have their appendix removed. If the doctor removed the appendix without doing their own diagnosis they wouldn’t be doing their job well (in addition to the fact that they could kill the patient). You need to do the same thing: diagnose the real problem, then help the team understand why your proposed solution will solve the problem for them.
Habit 7: Reduce Organizational Whitespace
Most companies have organizational whitespace: areas that are not the responsibility of a specific group or department. Inevitably, problems come up in those areas, and usability people are well suited to identify and help resolve those issues. Demonstrating our skills at driving these ill-defined problems to successful conclusion can help broaden our impact in our companies.
What’s an example of a whitespace issue? Recently, a usability specialist in our group was having trouble helping a developer define requirements for a project. When she looked at the problem a little more broadly, she realized the underlying problem was that multiple teams were working on similar solutions, but no one was responsible for making sure the groups coordinated their efforts. Working with senior management, she got all the relevant teams together for a few hours and facilitated a discussion about shared issues and concerns. The result was that all the teams felt better able to move forward, and her specific team had a more clear set of requirements.
How can usability people help resolve whitespace issues? We can use our workflow skills to recognize whitespace issues, and our communication skills to help teams notice and work through these issues. Often, solutions require getting cross-functional teams together, and we can use our facilitation skills to help these teams brainstorm and evaluate solutions. Finally, our ability to ask great questions at the right time can help both expose and resolve these issues.
How Does This List Help?
Originally, I created this list to integrate new staff into our group. At the time, our usability group at MathWorks was in the happy position to double its size over the course of two years. It was awesome, because we got to bring in talented folks with lots of experience. It was challenging, because we found that our newly diverse group had a variety of ideas about priorities, and we didn’t have a common framework for making decisions about what work was important.
After lots of thought and conversation, I realized that as manager I needed to articulate my philosophy about what kinds of activities made us effective. I thought a lot about what I had seen work at MathWorks and what I had learned from collaborating with Usability Professionals’ Association (UPA) colleagues. Putting these ideas on paper gave me a tool for setting direction within our newly expanded group and gave our management team a tool for helping to coach staff. We continue to use our “7 Habits” presentation when we orient new staff.
A few weeks ago, I looked at the list again to help resolve some issue and was struck that the list has held up well over several years. Why? Well, like Stephen Covey’s original, this list focuses not on technologies and specific tactics, which change over time, but on habits that become essentially a map for behavior.
