The Biggest Usability Issue with Enterprise Applications
There is a disparate mode of feeling that one gets when designing enterprise applications. If we look at UX Design through the lens of an enterprise project, all our typical activities are magnified significantly. Dozens (and sometimes hundreds) of user journeys need to be identified, architected, re-architected, and nurtured. Then you have to consider important metrics such as task efficiency, which can positively or negatively impact your bottom line. Overall, there are a lot of moving parts, and things can (and will) become complex.
The Culprit
When we conduct a Heuristic Analysis of an application, we identify common usability issues. This is typically done for existing applications that need a refresh or can serve as a learning moment for the business. The outcome of this exercise is a report that identifies what usability issues can be resolved or what to watch out for if a re-build is occurring. What we’ve learned through these exercises is that the most prevalent usability issue overall is consistency.
Consistency refers to the congruent words, designs patterns and interaction patterns of an application. When someone performs an action in one place, that very same action in a different place is not the same. Let’s look at this with a simple real-life analogy. You’re walking through a building and as you make your way through it every door you use pushes inward. Inconsistency would mean that 1 out of 5 of the doors requires you to pull instead of push. That interruption of flow would cause you to pause and affect your experience because it breaks the pattern.
Why Consistency Matters
Creating an inconsistent application negatively impacts learnability. If users cannot easily learn the application, gloomy themes emerge such as task errors and abandonment. Usability issues impact the bottom line, especially if users completely abandon a system.
Consistency can manifest during virtually any phase of a build, but to provide more context, it’s primarily most impactful in the following two areas:
Ideation Phase
Larger enterprise-level projects typically span multiple development teams which represent different aspects of the business. Subsequently, there’s a UX team that provides design solutions for user testing and acceptance. During the ideation phase, the nature of these larger UX teams means they will have many different designs in-flight being considered and tested.
When there are multiple streams of design work taking place, it’s easy for a disorganized design team to deviate from patterns, especially when user testing and feedback generates new ideas that are inconsistent with patterns that exist in other parts of the system. If you’re not careful, those pattern deviations can multiply, which is felt more for projects that take longer.
The Build Phase
Build produces more design inconsistencies that any other project phase. The primary causes are poor planning and impatience. If a development team is looking to complete features that lack a referenceable design, there is a good chance it will result in a pattern deviation. There are three general ways in which a developer could handle completing a task without a design.
- They will implement the feature without any visual vibrance but will leave the UI code in a raw state.
- They will pull a component or pattern from another part of the system, even if it’s not intended for the task at hand.
- They will create something completely custom to solve the problem.
In all three scenarios the work being completed will negatively impacting your ROI. You either push ahead, ignoring inconsistencies, or you have to go back and resolve the inconsistencies. In one instance you are creating usability issues which impacts user acceptance and efficiency (or worse). In the other scenario, you are adding more technical debt to the project since development has to re-visit features previously thought complete.
The Fix
Start design as early in the process as you can. Stagger design work ahead of development by at least two sprints in an Agile environment. This allows for all the proper activities and rituals to occur which require design reference. Sprint planning without having a design to reference is a nightmare for Developers and it should be for Product Owners too. Additionally, that two-sprint gap allows the business to change its mind and enables design to properly react and test changes.
With that said – starting early is not enough. You must also establish a style guide early as well and religiously keep it updated. The style guide should consist of color palettes, component patterns, animation patterns and any repeatable item that will be referenced by development. There are great tools that help organize style guides and component libraries, such as Storybook and Docz.
Lastly, implementing a good process to handle adherence and testing of the style guide is critical. Starting design early, creating important design artifacts and having the right tools is great, but if you don’t have a good process to manage the execution and adoption of said items, you won’t see good results.
