This post is for developers who are required to make user interfaces but it isn't their prime focus.
As Software Developers we don’t always have the luxury of working alongside a designer and despite our best efforts there is often a communication barrier between us and the users we are ultimately responsible for.
This isn’t helped by time pressures forcing us to release half-baked prototypes as production-ready.
I’m not going to tell you how to design better interfaces, there are enough posts on that and every situation is so unique it is very hard to generalise. You may not even be interested in designing but do it out of necessity, which is fine.
What I would like to share is some simple things you can do that go a long way to improving the experience of your users without adding much work.
Note: You may not agree with everything here, that is fine, not every tip applies to every situation.
1) Keep text human readable
More than likely, your users are human; More specifically: Non-Technical humans.
Remember that as developers we are used to reading short variable names and codeStyles: LSTM, sigma, k_value…
But you can’t assume your users are able to follow along, sure perhaps all “current” users are, but new users will just get bogged down in all the techno-mumbo-jumbo.
Where possible, keep text written as it is read, no camelCase, snake_case or half vars, use spaces and full words, spell it out for them.
If you have to use a long acronym (like LSTM), then add a quick tooltip explaining it’s “Long-Short-Term-Memory model” or whatever it may be.
Of course there are exceptions to this, some acronyms are so common that to spell it out would just create clutter, use your best judgement and if unsure, just leave the acronym there and put the full version in a tooltip.
Learn more about writing human readable text here
2) Tooltips are cheap and easy
Of course I’ll always advocate for a well formed interface without ambiguity alongside beautiful documentation, but time is scarce and the client needs that UI done yesterday, so tooltips are your friendly stop-gap measure.
Tooltips give not only the user a quick instruction, but also any future developers that pick up where you left off, no-one should have to read through code to figure out what the “vBufDir” input field does.
Places to use a tooltip:
- When your text/variable is an uncommon acronym
- If it is not clear what the text/variable implies without any prior knowledge of the application
- When the text/variable is a mathematical or technical term (eg: Sigmoid, Random Seed, Weight)
- Anywhere you feel needs a little more explanation
How to write a tooltip:
Some of us are a little “Linguistically Challenged” and struggle to write non-technical documentation, fortunately there are tools for that now.
Visit a site like ChatGPT and simply ask it to write it for you:
Now I would like to point out that I find ChatGPT is often incorrect or includes some inaccuracies in it’s response, but given you should already understand the topic you’re asking it to explain you will be able to pick up on these and adjust as necessary.
3) Go easy on the colors/effects
Now I absolutely don’t want to deter you from experimenting and having fun with designs, if you have the time to explore designs and gather feedback then by all means go for it. But if you are on a strict deadline or not in a position to consult end users, it is better to keep it plain and simple.
Your users are likely using your UI to meet some end goal and animated effects and off-key colors can really throw them.
If you do need to add color variation, visit a site like Coolers or ColorHunt, pick a palette and only use colors from that palette.
Learn more on color theory here.
4) Animations are meant to be distracting
Animations are another pet-peeve of mine. They are a distraction by design, when used well they can help guide the user by temporarily taking their attention to the motion (Oh this popup came from over there, so it is probably related to it) or by giving them something to look at while the software loads (eg: loading spinner)
They temporarily take the users attention for a specific purpose.
But if things are just moving while they are trying to work, it starts to detract from the user experience.
Of course there are exceptions to this, particularly in the field of marketing, but generally that should have a designer involved that understands the theories lest you venture into dark ux land (we don’t go there..)
Learn more about animation techniques in UX here.
5) Validate data up front
One of the most frustrating things you can do to your users, is make them enter all their data, wait for a process to start and then have it fail because their inputs were incorrect.
Sometimes this can also leave their workspace in a bad state with no real recourse as to what they need to do to clean up.
The best thing to do is to validate as they go by validating on key press or on focus lost.
But if that is too much then just make sure the first thing you do once they press the button to start the process is validate as much as you can before you start, it will save a lot of headaches down the line.
Learn more about up-front validations here.
6) Tailor your error messages to your users
Too often error messages require actually reading the code to understand:
IndexError: Index 42 out of range
KeyError: ‘k_value’
RuntimeError: Connection lost on port 8012
We know what that means, but the users sure don’t.
Fortunately developers can understand errors made for users, so by writing user friendly errors we all benefit.
If you want to take it to the next level, tell the users what they can do to alleviate the issue
Error: Option 42 is invalid (38 options) Confirm plugin is loaded and try again.
Error: k_value is missing in “/path/to/model.json”, unable to load.
Error: Server connection lost, check your internet connection and try again.
Learn more about the error handling UX here.
7) Inclusivity matters
Often it feels like no matter what we do, someone will be offended, so why bother trying.
I’ll admit I wasn’t sure whether to include this given it can cause rigorous ‘debate’, but let’s face it; Inclusion is a thing, like technology language is also evolving and if we as developers are not sensitive to that, we risk alienating our users.
I’ve heard several developers say: “The minority somehow create the majority of complaints” and I’m not going to go into a spiel on inequality and injustice; as important as that is, this isn’t the place.
But there are a few easy things you can keep in mind to be more inclusive to your users
- Don’t just use green/red to imply success/fail, at least have some text or icon.
Some color blind users cannot differentiate between green/red – Read More - If possible, add a font size or scale option to your UI under an accessibility menu.
Sometimes I have just added a menu that maps to setFont(currentfont * (+/-)1.5), not ideal but works in a pinch. This is not just for users with poor vision, but also those on 4k/retina displays. - Try to avoid terms with “oppressive” origin:
Blacklist > Blocklist
Whitelist > Allowlist
Master > Primary
Slave > Secondary
These are the most common words worth replacing and easy to do so – Read More
I feel obliged to at least mention there are also concerns around non-binary genders, pronouns and the like. But if you are collecting personal data of that level in your interface you start to encroach on a legal minefield.
It’s best just to not collect any personal information aside from name and preferred language (for translation options) unless you really know what you are doing.
Conclusion
Hopefully this was helpful, the tips here are largely my own opinions based on experience and feedback I have had over the years, there is of course a ton more that goes into designing a good user experience but these tips can be used as an absolute minimum.
Regards,
Mr MinimalEffort