When constant consistency can be a big design downfall
As a designer, it’s my job to create consistencies between nearly everything. Text and images; products and their devices; conceptual models and the user's mental model; designs and functionality.
And as I’m always striving to create something I can be proud to release into the world, I want it to be consistently, well, consistent. I’ve never sent anything off with padding misalignment, or one button height of 48px and another at 50px.
It’s just not something you do.
Of course, it’s easy to quickly bang something out that meets the Minimum Viable Product needs, but that’s sloppy and cuts corners. For example, you might not take as much care when reusing elements. You might think it’s quicker to just draw a new button than dig out your old one, and therefore you lose the consistency of the styles.
“Was it 50px high? How wide was it? What are the margins and the padding? What’s the exact hex colour? Font? Font size? Kerning? Character styles? How far away is the icon from the text? Which icon? Ahh sod it, it looks similar.”
No. For me, that attitude won’t do. I’d rather spend a little more time doing it properly the first time, than a) output subpar work and b) risk having to make huge changes later on. It sounds like far too many considerations for even a simple button, but if any of these are inconsistent you hit major problems further down the line.
Agile
Unfortunately my approach tends to clash with Agile. Those who strongly and vehemently follow the Agile approach are, in my mind, doing it wrong. To be ‘agile’ means to be flexible, in all aspects of your professional life. It’s also good practice in regular life. If you’re following the Agile textbook to the rigid letter, you’re by definition not being agile.
My approach: Follow the agile guidelines, and when you need to be flexible, be flexible. That’ll foster greater relationships with your clients, colleagues and ultimately, create better work.
Agile preaches “ship it fast, light, and with quick iterations. MVP all the way.” While I agree with most of that, I don’t think the Minimum Viable Product should therefore be substandard because it has been rushed. When you rush, you create inconsistencies without a good reason. They’re just there, and they’re sloppy.
I think in terms of design, the Minimum Viable Product needs to still look good. Even if it’s just a wireframe at MVP. It needs to be clear, and consistent with the rest of the wireframe styles, sizes, and layout.
However. Inconsistencies for the correct reasons trump consistency.
Just like following a the Agile methodology blindly and to the letter can lead to massive problems, so can blindly creating consistent designs that don’t suit certain contexts.
When Inconsistency is a Good Thing
In some contexts, you may (and probably will) need to break consistency.
Nobody using the live product is going to get upset over this. No regular user is going to think “Hang on a minute. They’ve used size 15px Regular font everywhere, and here it’s size 17px Semibold! HANG THEM FOR DESIGN TREASON”
Ok, that’s a little silly. But my point stands:
“Your average user isn’t going to notice inconsistencies in the design, if they’ve been made consciously and for good reason.”
They will notice if things are inconsistent due to being sloppy. And as soon as they do, you lose a user. If they identify that you’ve been sloppy with your spellchecking, your alignment, your development, or anything… You immediately lose credibility with them and they’re likely not to return. They may even form an immediate distrust of your site due to your sloppiness/carelessness.
Sometimes it’s vitally important to break your consistency in favour of highlighting the prominence of an element over others. Imagine you’ve got a large page of text (I know, gross) and you need certain elements to stand out over the rest. Say on that page, it’s vitally important that the user sees one particular element, but functional restrictions mean you can’t change the layout much. You might want to break the consistent styles and make these elements slightly larger/bolder/a different colour, to draw the eye.
Visual or Mathematical Consistency?
Being mathematically consistent is usually a very good thing. It means your designs can be developed to a standard, a standard that's agreed with the developers and allows repetition of elements and components. When you say to the developer "Put a button there, please". They can then immediately use the mathematically consistent styles to place the correct size/colour/font/style button, in the correct place, with the correct margins and padding; because they're consistent.
But mathematical consistency at the cost of the visual hierarchy is a very, very bad thing.
If there are some unusual elements that aren't likely to be reused, or elements that need to stand out from the norm, then consider this. If your guidelines dictates that the element must be either 20px or 40px from another element, but it looks wrong at both of those - then don't be afraid to change it. Putting it at 30px, so it's visually correct, is more important than making it look incorrect but matching the standard. If the standard doesn't look good - you need to be inconsistent (or change the standard).
Taking Feedback
I try to always be approachable to change requests and feedback. When the client says ‘I don’t like it, why is it like that?” I discuss calmly why certain design elements are the way they are, and why some can’t be that way depending on context.
If the client notices the inconsistency, they might say something like this:
“If I noticed (pick a thing), my customers will too”
I’m sure that’s familiar to many of you. It certainly is to me. However I respectfully disagree with the client. It’s in their best interests to go over the site with a fine tooth comb, because it’s their site. They want it to be perfect, and understandably so.
But their customers don’t have the same agenda. They want the site to be nicely designed and more importantly, very easily usable. They’re not going to care if you create inconsistencies. As long as they're done with purpose, and make the site prettier or easier to use.
— — — — — — — — — — — — — — — — — — — — — — — — — — —
Start with a Minimum Viable Product...
Click here to read a good article from App Development Co.
Many thanks to Dilbert Comics in this article. If you liked this article, I’d greatly appreciate you tweeting or sharing this ❤
