Does your company merely build functions and features or do you build knowledge into those products? Features and functions alone don’t make users successful. Users have highly variable levels of skill and knowledge and any design that relies on that variable level of skill and knowledge can only achieve equally variable success. Success is highly dependent on user knowledge and if your users aren’t expected to have all of the requisite knowledge, then you must design that knowledge INTO your product.
But what does built-in knowledge look like?
Example: You need to change the spark plugs in your car’s engine. Your developer buddy invites you to use his garage full of tools. To your surprise he has a whole stack of professional tool chests with labels identifying each drawer's tools (screwdrivers, wrenches, sockets, pliers, etc.). Handy, you think, until you start looking for the tools you think you need. Though the drawers are labeled, having never changed spark plugs, you have no idea what tools you actually need. You are even further confused as you start opening all the drawers and find more tools than you have ever seen before. You grab a socket handle, but the spark plug socket doesn’t fit. Unbeknownst to you, you grabbed a 1/2” drive and the socket uses a 3/8” drive. Who knew? This garage is highly dependent on the user knowing exactly which tools they need for each job. Unfortunately, you don't know which tools you need.
Then, your UX designer friend calls and invites you to use her garage. She, too, has a garage full of tool chests, but those drawers are labeled by the type of task one needs to perform (change tire, change oil, etc.). You quickly spot a drawer that says change spark plugs. You open it to find just the tools you need for that job - socket handle, spark plug socket, socket extension (for those plugs way in the back), torque wrench (preset to 15 lb/ft), and gap tool (you didn’t even know you have to gap the plugs).
This drawer only requires the user to know what job they need to perform. By using her knowledge of which tools are appropriate for each task, she provided a design based on her expert knowledge and relied less on the highly variable user knowledge. Instead of opening all of the drawers to find the tools they need, the user only has to open one. By her “design,” the designer dramatically increased the success rate for even the most novice mechanic.
Avoid automating current frustrations!
Most companies conduct little, if any, user research. And when they do, its usually a time and motion study. Just because something is done a certain way, doesn’t mean it’s the right way. More often, designers merely mimic existing processes without any consideration for how to improve that process.
When a developer sees 100 users performing the same task 100 different ways, they design a system that allows the users the flexibility to perform the task any way they want. When I see 100 users do the same thing 100 different ways, I realize that they are all doing it differently because no one knows how to do it the “right” way. User skill and knowledge are highly variable. Great designs do not rely on user knowledge. They provide the knowledge users need. They bridge the gap between what users know and what they need to know (but won’t).
Horizon of Observation
Customers only know what goes on within their own four walls. They cannot easily see what others are doing and often have no idea if they are performing better or worse than anyone else. As a product or service provider, you see beyond the four walls of each customer. This expanded Horizon of Observation (Hutchins, 1995) allows your team to identify what works and what doesn’t. This is the type of insight that makes the difference between a product that relies on user knowledge and one based on your knowledge. By applying your knowledge of what works, you create a design that guides users to their desired outcome without relying on their own knowledge.
$500M Example
When we started on the Proflowers project, we did NOT watch users buy flowers online. That would have resulted in yet another copy of the typical (unsuccessful) online flower shop design. Instead, we observed people buying flowers in flower shops. We quickly realized that most of the people buying flowers were men buying flowers for women. What do men know about flowers, especially bouquets? Pretty much nothing, right? What did they know? They knew the reason they needed the flowers, which was usually centered around a specific occasion.
For men to succeed at this task, they would need to purchase bouquets that were right for their occasion. This suggests that we needed to organize the task around occasions (what the users knew) and suggest flowers appropriate for each occasion (what users didn’t know, but Proflowers did). Thus our knowledge design strategy was defined as “Proflowers doesn’t sell flowers, they sell occasions.”
The result was a website that organized bouquets by occasions. Naturally, Valentines and Mother’s Day are Hallmark occasions that take over the home page, but the remaining occasions are the next ones in the navigation bar. Specific flower selection is available towards the middle of the nav bar. We designed that almost 25 years ago, and its still one of the most successful e-commerce sites today (worth about $500M).
The point is that our research helped us understand what knowledge the average users did have, determined what they would need in order to succeed (but likely wouldn’t have) and then identified a way to utilize Proflowers’ knowledge to bridge that gap.
Instructions are a symptom, not a solution!
All too often, I see designs were its obvious users don’t know what to do, so the designers added instructions. Countless usability studies have proven that instructions don’t work. How many times have you been walking out of a building and when you reach that glass door with the chrome handle you grab the handle and do what with a handle? Right, you intuitively pull on it. But the door doesn't open. Then you see it. A little sign that says Push. There’s something inherently wrong when something as simple as a door requires instructions.
Instructions are NOT the same as designing knowledge into your product. Do you think instructions would have helped users select the right bouquets on the Proflowers site? The more instructions your design requires the worse it is.
How do you build knowledge into a product?
Simply by optimizing user tasks and incorporating best practice approaches.
Your user research should include a fair amount of user observation and task analysis. Once you’ve completed the initial task analysis, you should be able to identify areas of the task flow that could be replaced by your best practices knowledge. In every project I’ve seen, this optimization has identified new product opportunities that have addressed largely unmet user needs. In some cases it has helped my clients dominate their markets.
One trick I use is to identify the users’ desired outcome and work backwards to the trigger that initiated the task. I look for steps that require specific knowledge and skill and determine the likelihood of the user having that knowledge. Where the users are not expected to know something, I look for ways to make the system do that step for them.
So, instead of just looking at how the users do something now, look to find ways to improve their processes and replace many of the user steps with automated system actions that follow a best practices approach.
Death by a Thousand Cuts
Avoid the “what if” rabbit hole. Don’t get distracted by trying to satisfy any and every way of doing something. There may be more than one way of doing something, but focus on doing it just one way, first. You can always add other options, one click away, later. I’ve seen countless examples where somebody starts asking what if... and they add something, then something else and so on until the product is a tangled web of “what if” features that no longer resembles a best practice approach.
Focus on a single approach and optimize as many steps as you can towards delivering the desired outcome. Accept the fact that this approach isn’t for everyone, but you’ll find that it satisfies over 80% of your users and brings in new ones.
One client was worried that they might alienate their existing 6,500 customers, which were hanging on by a thread as it was. We redesigned their product focusing on a best practices approach and now they literally own 99.9% of their market with over 650,000 customers.
Create, Use, Edit
Users perform the worst when given a blank page (create). Its highly unlikely that any sample will be a perfect fit, so users are not apt to use a sample as is (use). However, it’s a well-known fact that users perform better if you give them a sample to edit (a template). Some basic methods that help guide users are templates and intelligent defaults. Applying these to your design significantly improves user performance.
Just say no to reports.
Almost every type of software I’ve worked on initially included a requirement for a report generator. If there was ever an opportunity to optimize the users’ tasks, report generators are it. Think about it. Is printing the report the last thing that a user will do with it? Certainly not. Users always do something else with that report. Your opportunity lies in understanding what the users should be doing with that report.
When users run reports, they are typically looking for two things, trends and exceptions. Trends are proactive artifacts plotted over time that suggest and guide user actions. Exceptions are reactive anomalies (usually with respect to some threshold) that require attention, right away.
Exceptions and trends are actionable insights.
A well-designed system should include these as standard display artifacts and not require users to know to run a report to find them. Given all of the variables (usually 1,000+ permutations), how will a user know which variables to investigate? Again, the difference between what users know and don’t know is critical to the success of the task.
Most dashboards suck, plain and simple. They typically display a few meaningless data points that were determined, not by what the users needed, but merely by what the system already provided. Using the trends and exceptions approach and incorporating the client’s knowledge of the domain, you can replace these meaningless dashboards with actionable alert lists and charts.
What’s your knowledge strategy?
Does your team have a process to capture domain knowledge and fit it into your products? Do you know how to identify and codify best practices in your domain? Can you think of designs you could change given this new Knowledge Engineering concept? Answer these questions to identify your knowledge strategy.
About the Author
You would be hard pressed to name another UX Design expert that has the training, experience, and design successes as Larry Marine. He’s been consulting on UX matters for over 25 years and has designed some market dominating products and websites in just about every domain. He is one of the lucky few that earned a Cognitive Science degree under the tutelage of Dr. Don Norman, the Father of User Experience. Larry provides a different perspective based on his rich UX design experiences.
Ed Hutchins (1995), Horizon of Observation, Cognition in the Wild (p268)