How to crush design usability test for enterprise product?
If you’ve ever worked on enterprise product design, you probably know that complexity, and implicit logic is an indispensable part of it. We do not want to talk whether it’s ok or not, just let’s admit that some level of frustration is acceptable. It is challenging enough to provide a result that will not only meet requirements but also will be exceptional from UI/UX point of view. Especially when resources are limited. Honestly, it is never enough resources, however tight deadlines and limitations contribute to better results. It boosts creativity and braveness of decisions.
By excellent product design, I mean — clean and modern UI, distinct and smooth interactions, familiar and consistent patterns, onboarding and error handling on point, etc. Crazy, right? How all of these achievable when working on enterprise product? Is it even needed? Yes, I believe that all these factors important regardless of the type of product. However, let’s focus on how to improve user productivity and reduce the amount of stress while using a complicated system.
Value of usability testing for enterprise product design
It is pretty evident that testing of final product important step. Right? But what about the testing of design artifacts? Well, the general rule here — we want to find problem earlier in a process, so it will be cheaper to fix. One of the objectives is to reduce overhead, another one — not to fail after product delivered to the customer. Even if some part of the product going to fail, it should happen within a controllable environment, and we’ll learn from this failure. There are many articles with accurate calculation formulas, plus elaboration of mistake cost depends on the stage of the process. Nevertheless, even if we’ll consider the design process artifacts by itself — it is cheaper redo wireframe than prototype with high-fidelity mockups.
You can test design artifacts on each of the process stages that your product team follows. Quality of which is not critical as long as you have narrowed down focus and have few hypotheses that you want to validate. Don’t try to cover all possible aspects of a design from a color of controls to interactions you probably wouldn’t have much time for that in-depth session. Try instead to narrow down your focus with a simple agenda and clear goals. However, questions need to be open to collect some additional info as well. It’ll help you better understand some of the contextual aspects and provide a big picture that you can share with your team.
The difference of testing in office and where the product actually being used
There are multiple ways to test design artifacts such as — review with the team or in-house domain experts, customer visit user interview and usability test, etc. Testing of design artifacts shouldn’t be an overwhelming effort if it well integrated and distributed through different stages of a process. We all have a lot of domain expertise in the house. People interact with customers and end users a lot. The thing to be aware of is that sometimes, in-house feedback motivated by personal bias. That’s why end-user usability test important to isolate bias from the decision-making process or evaluating results.
The toll of usability problem under production pressure
Working with in-house domain expertise, you need to understand that the context of usage is a crucial part of the evaluation. Domain expertise provides easy and cheap access to details like workflow, process, patterns, etc., but struggles to deliver that critical part. The severity of usability mistake could be different when you test in a calm office environment compare to chaotic production, especially when something goes wrong and user cracking under pressure. While we could sit on meeting and sip after lunch coffee trying to evaluate the quality of UX copy, meanwhile end-user could be freaking out trying to fix subsequences of problems causing a dent in production that he has zero control over and unclear terminology of UX copies not helping him. See difference? Something that could be clear for us not necessarily will be evident for end-user under pressure. However, how to improve the way we used to test? No matter how hard we’re trying to consider all possible use cases, it’s not enough, because something will slip over anyway. So make sure that unexpected discoveries appear earlier without creating damage. We should test design in a context that close or the same as end-user has sooner in process.
Awareness of user challenges leaves no room for tolerance to issues.
There are many communication layers between the end-user and product team, which makes it hard to request and analyze needed information. Also, it could make the product team members think that somebody else from the top should be responsible for the result and will pinpoint on things that should be fixed anyway. Some kind of crowd philosophy but with a vertical twist. What could we do better here? Building and evangelizing empathy could help. Understanding end-user makes us less tolerant of product design flaws and potential usability issues. Increased awareness contributes to critical thinking while evaluating solutions and implementations. Though try not to get carried away and stick to constructive critique, everybody will be happy at the end.
Task analysis as a starting point for better testing at the office
Test every single aspect of the product design is a tremendous effort. Still, what if we did set quality benchmark too high and now we’re cracking under an obnoxious amount of work. Is it even possible to deliver the outcome without diminishing expectations? It’s possible, but we should be smart and utilize task analysis with prioritization within iterations.
Task analysis as part of UX process
Task analysis exercise is an excellent tool in the hands of UX designer and product manager. You can find much use for task analysis artifacts, but in the context of this article, we’ll focus on how it could help us test design better.
Focus should be on 20% of the product that provides 80% value. Essential part of the product should be exceptional, rest could be acceptable.
Prioritization is a key to get essential functionality on point.
One of my beliefs that we should focus on 20% of the product that provides 80% value. In other words — an essential part of the product should be exceptional, and rest could be acceptable, then you could iterate until you perfect whole product if needed. Using a result of Task analysis and with the product team set priorities of what task is critical for end-user to succeed. You could also validate how your assumption of priority reflects reality during one of your sessions with end-user. Then based on this knowledge compose plan and goals for testing of parts that related to high priority tasks only. That will narrow down an area to polish and give a chance to deliver an outstanding result within a timeline. Gather feedback after each release and don’t forget to fix issues and deliver that with other improvements. Prioritization keeps you on track — easy to get carried away with dozens of small use cases to test.
Importance of well-thought error handling
It’s significant and important enough topic for a separate article, but I’ll try to condense it not to steal the thunder from a testing topic. Error handling is a crucial aspect if you want to bring your product design to the next level. Long story short, just try to answer few test question:
- How critical error?
- Is this error blocking or work shouldn’t be interrupted?
- What happened with unsaved data?
- Who’s this fault (seriously, somebody needs to be blamed for this)?
- What user can do to fix it?
- Did you provide a shortcut to actions?
- What about details and a way to share them with customer support?
- Clear statement if error was reported automatically (if applicable)
It will create a solid base to deliver kick-ass error handling. By the way, you should test this as well ;)
Conclusion
I would like to stress one thing — testing of the product before shipping to customer is not enough for exceptional result. Add testing with real users in between stages with artifacts that you have at the moment to see how the product will be used in the actual environment. That will help to examine product hypothesis earlier and avoid fundamental misalignment of expectations. You will be surprised what findings you can discover while observing how the user is trying to achieve goals by using a product even if it is just mockup or prototype. More often we do observation less likely we’ll have a surprise at the end. Anyway, this is my reflection on the topic of validation of design artifacts in the product life cycle. Further, I would like to share with you my take on UX product strategy and dive deeper into the process and technics to get better results.
Let me know what you think!
Ps. Pictures of UX-man in this post not about to make UX guy in your team a hero, but one more time to emphasize the importance of investing in UX in general. At the end of the day, delivering an exceptional product is what matters most, and it is always a team effort game.
