Everyone loves finding a great deal. Who can say no to a good two-for-one special? Every store has a bargain rack that’s full of unsold clothes and slashed prices. But have you ever considered these racks as a whole? Plaid with dots, coats with swimsuits, brown with black?! Madness! Imagine you only wore clothes from that rack—would anyone take you seriously?
If you’ve been using a similar method for building your web app, it’s probably starting to look a little, well… dissonant.
This post is a continuation of our “5 Signs Your Product Has Outgrown Its UX” series. If you haven’t already, you might want to start at the beginning with “Does This Make My App Look Fat?”
Due to the complexity, a long life cycle, and large teams, enterprise products are at a huge risk of inconsistent user interface design. And the more time that passes and the more the product scales, the greater this risk. That’s why this is a clear sign that your product has outgrown its UX.
What Leads to UI Inconsistency
Don’t worry, no one is judging you for wearing that Hawaiian shirt over the leopard t-shirt. Well, maybe they are. But sometimes you don’t have a choice. Those decisions were made in the past for the product and you simply inherited the ensemble.
What got you here? There’s a lot of factors, but these are some of the usual suspects to a miss-matched UI:
- Designers or teams working in silos
- Too many third party resources and libraries
- Developer improvisation
- Shifts in vision throughout the lifecycle
Why It Matters
Believe it or not, an inconsistent UI isn’t just a visual problem. It’s about more than whether your app looks good or not. It actually has a big effect on your end user’s experience as well as how they perceive the product’s value.
A user interface is a lot like the rules to a game. The more the user understands those rules, the more intuitive the app will feel to them. That’s why as designers we try to leverage existing UI elements and patterns as much as possible.
But if your UI is made up of miss-matched components and styles, it’s like adding more rules to the game. It’s going to lead to confusion and lower engagement. You might reason that the user can “figure it out,” and you might be right (anyone can play Monopoly on a Chess board, after all) but the app will feel unfamiliar and get in the way of what would otherwise be a natural user experience.
It Feels Cheap
As consumers, we always want to feel validation when making a purchase; this is especially true for expensive or important items. If something feels like it was made by piecing things together without much thought of the big picture, a user is going to pick up on that.
A product that doesn’t feel valuable will be easier to discard or abandon. If your users don’t feel validated when they use your app, they’ll be more likely to entertain a competing product.
Lack of Trust
Was your app made overnight by a guy living in his parent’s basement? No? Then why does it look like that? Users may not be conscious of it, but they have deep rooted instincts built around whether something is trustworthy. Software is no exception. If a product looks like it was built quickly and unprofessionally, it will trigger these warnings in a user’s mind.
Now, if you’re building a to-do app that’s probably not an issue. But for the enterprise? Trust is a big deal. People will be relying on your software for their livelihood. They will use it every day. Their job performance will be impacted by it. If it doesn’t feel trustworthy, they’ll resort to another tool. It’s just not worth the risk.
A Design System – Your Solution
So what’s the solution to this Frankenstein’s monster of UI? The best thing to do is start marching toward a standardized design system.
Design systems consist of rules, guidelines, and common components that can be followed across your application, or even several applications. By standardizing around a single system, multiple teams can operate autonomously while still maintaining consistency in their UX and UI.
If you’re interested in seeing how some other companies work with design systems, here’s a few examples:
- Google’s Material Design
- SalesForce’s Lightning Design System
- Mail Chimp’s UX Patterns
- Yelp’s Styleguide
These companies are led by massive groups of people with different roles and initiatives. Regardless, each of those people can use the provided design system to both save time and ensure compliance with the brand.
Where to Start
If you look at some of those examples, they can be a bit daunting. Those design systems are the culmination of several teams iterating and working on those libraries for years. If you don’t have that, it’s ok. Really. Your design system doesn’t need a manifesto. It doesn’t need every component. It doesn’t need meticulous documentation. It just needs to be useful.
“I don’t have time to wait for a design system.” You might be thinking that to yourself. But design systems don’t have to be designed and implemented all at once. Start with the most common component or piece of UI that’s shared across your application. Even if that’s just a submit button. Standardize it. Reuse it. Then move to the next component. If you include this with the web development work you’re already doing, you’ll have a library of reusable objects in no time.
If you’d like to read more about this approach, you can read Enterprise Application Redesign: From the Bottom Up.
With a little vision and teamwork, you can kick that bargain rack UI to the curb. You’ll be left with a consistent and intuitive user experience that your users will love.
Need a Little Fashion Advice?
Have you been shopping the bargain rack a little too long and need some help? Our designers thrive on creating robust design systems for applications of all types. Let’s Talk about how we can help you implement a design system.