Secret to Effective Software UI Design
Trying to establish a digital product development pipeline from scratch, which involves UI design, is hard. More often than not, you have lots of unhappy participants: clients who complain about things not looking as good as promised; designers who get their hearts broken at the sight of their meticulously thought out work getting deformed and broke apart by the day; developers who get overwhelmed with changing requirements and feel lost on how to respond to them; and product owners who have to make judgment calls and sacrifices that they come to regret to keep things on the schedule. Doesn’t sound like a nice place to be in, to be honest.
Not that things are always dandy in huge, mature working environments. But suppose you already found the time and space within your workflow for things like doing user research, using user personas, coming up with a consistent design language for aspects like look & feel, UX patterns, terminology & tone, and themes, colour palettes. In that case, there’s a better chance that most actors involved know what is expected of them, and the results are not coming off as surprising to anyone. Compare that to when you are starting, when budgets are tight, and role definitions are vague, and things have a tendency to get messy and chaotic too easily.
Wouldn’t it be great if there was a secret rule of thumb you can apply at the beginning to keep things simple and effective? There sadly isn’t, but only because it’s not actually a secret and everyone already knows about it.It’s just that they are not doing it. In this article I’m going to talk about why getting leaner with your design process, delaying the details, and using mock-ups in your actual product for as long as you can is a good idea. I’ll talk about what these mean, what they entail in practice, why they usually take a little bit of dedication to follow, and finally go over the individual benefits to be had when we do.
Considering how straightforward it is, this commitment has an unexpectedly significant impact on the effectiveness of your software development life cycle. So I hope by the end of this post, you’ll feel a lot more confident about making it.
DELAY THE DETAILS
Let’s start with detailing what I mean by “getting lean with UI design”. I admit that it sounds abstract and fluffy from a distance. But it is simply about embracing the virtue of iterations, very similar to what it meant for the rest of the software development life cycle in the past few decades. It’s about letting things mature at their own pace, and not constantly coming up with pixel-perfect pictures until the very end when the end-users get involved. Agile methodologies have a very high adoption rate in the industry for a really long while now. It’s pretty standard for user stories to be written based on the stakeholders’ feedback of the working iteration right before it’s time to implement them. But sadly, designers are still commonly left outside of this iterative flow and asked to come up with shiny and detailed UI screens early on.
What is a mock-up?
“Mock-up is a scale or full-size model of a design or device, used for teaching, demonstration, design evaluation, promotion, and other purposes” per Wikipedia. For our purposes, I’m going to use the term to mean anything that can communicate its intent to give a sense of the experience and functionality and not trying to be pleasing to the eye. Anything that would let us iterate on things without much effort and doesn’t get bogged down in the finer details.
The thing is, when we’re developing and designing an emerging product, it’s a pretty bad idea to skip steps. Trying to give all the answers in one go is a fool’s errand because if you’re not learning new things about what you’re doing as days go by, you’re either a very stubborn person or pretty much a visionary operating beyond time and space. Of course, none of this means we shouldn’t think about the looks of things until they need to be more presentable. It’s more about not falling in love with any of your ideas on how your app should behave, and finding the time to re-think and refine what’s on the screen with the knowledge and insight of a more mature feature-set.
Why is this not an industry standard too then? From what I can tell, there are a few reasons for that.
The first is that it works against the habits and instincts of the stakeholders. We all like pretty things and sometimes this leads us astray. Everybody wants to get their stuff to look as good as possible as soon as they can, and there is constant pressure on your product to look the part from the very start. Usually, the design aspects are how we get to impress the onlookers early on at the showcase meetings, so we keep spending time on how things should look even if they’re temporary.
The second reason is that it works against the habits and instincts of the UI designers who had most of their experience on design applications other than software. Unlike logos, promotional materials, or even buildings and bridges, digital products are living things. The success of your work being tied to the process in which you’re working, rather than just your design chops and intuition, is a new situation for such people. Sometimes they can’t contain their creativity and want to jump into Illustrator to put all the pretty ideas popping in their head to the screen, since that approach worked great all their lives.
The final one is the lack of mainstream methodology specification on the topic. There is no established software development life-cycle that specifically makes assertions about where to find space for UI design, or how to approach it. Obviously, UI designers have quite a bit of internal guidelines for what they do, but software people mostly seem to lack interest in the area and how it relates to their craft. For better or worse, most big companies are just winging things when it comes to their process. For the small ones, with the lack of definitive guidance on the matter, the problem usually falls on their blindside.
Note that none of these reasons actually make getting high fidelity designs out early a good idea. But on the other side of the equation, there are actual good arguments for committing to using mock-ups in your working product and having a more iterative design process, so let’s talk a bit about them.
1. More Informed Design Decisions
If you’re iterating a lot, you would probably want to make the big, overarching decisions which impact the totality of your designs towards the latest iterations. These are the ones relating to your design language, which determines each pixel’s shape and colour.
Unless you are stealing it from someone else, a product’s identity would usually take shape as you go along. This rule applies to visual identity the most. If you insist on deciding on the finer details of the look of your applications very early on, you’d be doing it blindly. The most crucial factor in determining the design language would probably be what your designer dreamed about the night before working.
The more appropriate point to decide the look & feel, colour palette, terminology, tone of your product is when you have a much tighter grasp on what you or your customer wants to do — and waiting until then increases the chances of you liking what comes out at the end.
2. Managing Stakeholder Expectations
While this is a topic that could have its own article, the secret of having satisfied customers is managing their expectations, whether they’re the stakeholders of your company or the clients with a product that you’re helping with. And the thing is, even if we’re doing it unknowingly, every time we talk about where we are going, what we are making, or paint a picture of the future we’re building, we are continuously setting the expectations of our partners. Every detail that we are transparent about is treated as a promise that we have to keep. And what are all the UI designs that we share early on, if not pictures of the future?
When the delivery of a project is rated, more often than not it’s not rated just on its merits. Whether you’re presenting things to your investors, or demo users, they grade the work more like a professor grading an essay. You lose precious points with every little mistake. And if what you presented at the beginning was only a simple wireframe, then the only thing you have to do for a perfect score on your showcase is to actualise that simple wireframe. But if it was a shiny, colourful, detailed illustration, then you would have to waste a ridiculous amount of time to make those temporary things perfectly beautiful. And unless you do, you can’t blame them for feeling like a disappointed kid who saw the actual burger of a brand that they’ve only known from the commercials.
3. Easier Responsibility Segregation
One of the key tricks to productivity and efficiency in a team-based environment is lowering the responsibility and agency of your resources on the subjects they are not experts of. You need to segregate responsibilities in such a way that people have the time and space to exercise their creativity on the things they have expertise on, and yet things are still dumbed down in every other area when it comes to figuring out what they have to do.
In dynamic environments where requirements are continually changing in minute ways, if you’re trying to keep up the polished, ready-for-customer-use look throughout these turbulent times, the developers of your product will constantly have to make minor decisions on how things should look. They’re going to spend lots of time on things they probably know little about, and it’s not going to be their fault when things look less than ideal at the end. Or you’re going to bother your designers for every little change, so they can describe what should be done in exhaustive detail in written form at every step.
But in practice, since each of these iterations is quite expensive, it’s one of the first to get the cut when you are in a rush (tip: you always are). The result is everyone doing so much work and trying their best, but your product still looks like an inconsistent mess. Those are the moments you will wish you were working with mock-ups all along, and treating the application of UI elements as stories of their own that are explicitly described by the designers.
4. Saving Time & Effort & Money & Sanity
Everything comes down to this. All products and projects have a bottom line. Usually, their success is gauged by how little they cost and how much they make. And they are deemed failures when they run out of budget or out of time.
All of the reasons above create financial problems on their own. But not using mock-ups pretty much outright increases the effort that you need to spend to develop your product at every turn. This one is pretty straightforward and obvious but let me try to sum it up all the same: If you are trying to be lean, you have to embrace change. Change is expensive. And the more comprehensive your change is, the more expensive it gets. Go easy on yourself and don’t waste money on details that you know for a fact will change.
Wrapping Up
So while there are lots of things to say on the topic, the conclusion of this article is pretty straightforward, and there is only one lesson to take out. It’s the same idea from the very beginning: don’t try to get things right in one go, save everyone’s sanity, money and time by keeping things plain as long as you can. It should be simple enough.
To conclude, once again, let me thank everyone for reading. If there were parts that you did not agree with, please don’t hesitate to respond. If you enjoyed it, here are some of our earlier pieces on subjects ranging between technology and business.
Or you can just follow us at https://blog.refineri.co.uk, and if you got anything on your mind you want to talk about, you could always ping us at contact@refineri.co.uk. Cheers!
A. Berat Daglar
REFINERI Consultant
https://refineri.co.uk
