What is Front-End Design, and most of all: Why is it important?
To better understand this first we’ll have to break the concept into parts.
So, what is front-end? In layman’s terms it is the main contact surface between your business and your customer. Without it no user, and more importantly no potential customer, could access and benefit from your product or offer. To make it sound simpler think of it as the portal or doorway to your business. Suffice to say it is important.
Then what does the design part stand for? It is what differentiates one business from another. Think of it like clothing. All clothing – in essence – satisfy the same necessity of keeping the wearer warm and not exposed, in more ways than one. But take one look around you or flip the channels on the TV and the differences in clothing styles and Design are staggering, with some more successful than others.
What makes Front-End Design good? And if there is good front-end design then there must be bad front-end design as well. What separates them and how can we distinguish good from bad?
The easiest way to make the distinction is by having the end goal in mind, by keeping your eye on the figurative prize. For most businesses this means converting a user into a satisfied customer. For others it might mean increased add revenue. Whatever the end goal is, so long as your ROI is worthwhile and you turn a profit then that means you have good design.
That is good and all for existing businesses but what about those who want to start off a business or even branch out into new fields. How can they recreate previous success or at least learn from other people’s experiences.
First and foremost apply the KISS principle. If you are unfamiliar with it, it is a design principle and it stands for “Keep It Simple Stupid”. So keep your design as simple and uncluttered as humanly possible. Confused users are frustrated users. And frustrated users do not buy, they click away, off in the wide wide web, possibly lost forever for you. I need not state why this is bad. So keep it as simple and as unconfusing as possible. But remember, it has to be unconfusing for them. For you as the chief architect of your own design it might seems crystal clear as to the intent and functionality of your business portal. But for a first time user it might make absolutely no sense at all. If they cannot figure out what they want to do on your site in 60 seconds or less chances are you’ll lose them.
To better drive this point home I will share a personal experience with you. Back in 2016, together with my brother I worked on a NLP focused project that scraped and parsed legal information for the content team of the company we were working for. The back-end part of the project worked as expected and after several design experiments we settled with a simple style that focused on as few possible choices for the content team as possible – all in an effort to better help them understand the capabilities (and more importantly the limitations) of the software solution.
The initial team of 4 had just 1 button that reiterated the action in case the desired result was not achieved automatically. The weeks passed and their work flow shot through the roof. We were quite pleased with the whole process. Some time later my brother gets a email where an issue was brought up. It seems that some of the times the action button did not yield the desired result on the first try. For reasons that were out of our hands, it returned an unsuccessful alert message. Our reaction was quite normal. We asked what was the problem since all they had to do was hit the button again to reattempt the action.
As it turns out, what was crystal clear functionality for us left the content team totally confused. It never crossed their mind that they could “refresh” the action and try again. They just gave up after the first attempt. These are normal day to day people. People that – just like us – do not yield after the first undesired result. Think back to yourself. If a browser page does not load or seems to be unresponsive what do you do? More often than not you refresh the page – same as us. This seamed like obvious for our custom build service but to our surprise it was not.
Long story short we just had to instruct the content team on how to properly use the interface, a simple enough matter since the application users were few in number and we could contact them personally.
But what if it had been a publicly offered service, accessible to thousands upon thousand of users? What would their experience had been like if they gave up (as lots of people unaccustomed to a new service would) after the first try. How would that affect the business?
Had it been a publicly offered service to “anonymous users” we would have probably changed the button to say “Refresh Action” or anything else that would be more descriptive. But we would have done that only if by some stroke of good fortune we would have been made aware of the problem. Chances are we would have remained oblivious to the issue. And, just like you, we would have started questioning the value of the service all together.
Not one week passes without me having to access some service or site where I am left totally lost. More often than not I just “click away” towards the competition, but ever so often there is just one provider, one portal of information or service, just one business that has what I need. And I know they have what I require, but the accursed process of getting that which I need leaves me so frustrated, so angry and so down right furious that if I do not give up and keep trying until I get what I want I will go to great lengths to avoid having to come back. So much so that I ended up making changes in my life to avoid some such issues.
Nothing worse than offering a great deal to a great – and highly motivated to buy – customer and not ending up making a sale all because the customer got lost or frustrated accessing your business portal.
And do not think this happens only to the little guys. Even some of the biggest and most used internet services messed up in epic proportions. Take for example Yahoo and their mail services. Way back when I started using Yahoo mail – and for a very long time after – each day when I was browsing my incoming mail – like all of us do – I used to sift through my inbox, then open multiple tabs with all of the emails that seemed relevant or important to me. Then I would take my sweet time and read them one by one in order of personal priority. I had a system, a lovely system, one which I deeply enjoyed. Then a couple of years back they changed their UX design. They took something great, and for reasons that under no circumstance could you sale to me, they made it so that you could only read one email at a time. I deeply hate this. So much so that if I did not have such an old email address, one which is known by lots of important contacts, I would have changed my email service provider to another one. Even one that does not offer the old style functionality which I adored all just to “punish” the business that took away what I liked and found “unconfusing”.
Maybe it’s just me that is like that, but in my personal experience most users will often “punish” businesses that frustrate them. All this equates to lost revenues – from sales or otherwise – and lost bottom line profits. What a shame.
Adhere to established practices. There is no success to be found in reinventing the wheel. Some things are so commonplace and so ingrained into the general consciousness that changing them would not only be counterproductive, but down right stupid. For example the way links look like. Since the dawn of the internet it has been a non-written rule that, for the most part, a link is an underlined portion of text of a different color (usually blue). It has got to a point that the color blue is the most trusted nuance by the users, and offers the most credibility to your site. Why do you think facebook uses it.
Another very important place where it is an absolute must to adhere to established practices is fonts. Yes, text fonts. Something so simple as that has massive importance towards your business image. One simple way to “shoot yourself in the foot” would be to implement “comic sans”. If you have a hard time wrapping your head around what I have just said just do a simple search and your results will be full of “why I/We hate comic sans” and such. I do not care what service you offer, no one in their right mind will take you seriously if you use comic sans to “drive your point home”.
Think about it. The biggest – and often most overlooked – design element is the text font.
Text is massively important. So much so that you could scratch off all other design elements all together and still drive your point home, so long as you have text on your business portal. But the pretties, most business orientated, most uncluttered and sales focused design will yield diddly squat if comic sans is the font you use. This example is the most obvious but make no mistake, there are hundreds of other fonts that will drown business visibility and lead to unsatisfied users.
So what fonts should you use. Like I said, stick to established practices. Choose from the most common ones. One choice could be the bootstrap default font, sans-serif. Or check out heavy usage sites that have hundreds of millions of users and use the same fonts as them. As a tip, one sure fire way to notice if you use the wrong kind of font is if you or your users spend more time noticing (admirably or otherwise) the text font you use rather than the information it offers.
Text font is an instrument. And it’s only job is to offer the user the desired information in an undistracting and undisruptive manner. That’s it. Anything short of that is bad design.
Another nugget of business wisdom is the use of Drop Caps. A well sized drop cap will work simmilarly (but in a complimentary fashion) like a good header. It will attract attention to the initial proposition, the first line of copy on your site. That’s it. It works like a reminder that nudges the user to start reading and more importantly where to start from.
I keep reminding you to adhere to established practices, but you need not just take my word for it. This is an established and well known software design paradigm. For those of you that come from a Ruby on Rails background you might have noticed that it basically means Convention over Configuration, a very important step in what is affectionately called “The Rails Way”. But when it comes to front-end design, it is known in the whole programming community by another name, the “Principle of least astonishment” or POLA for short. What this principle boils down to is: “If a necessary feature has a high astonishment factor, it may be necessary to redesign the feature.”
In Rails we adhere to Convention over Configuration as a life line when it comes to codding.
One well established practice is to name the Model in the singular term, and the controller in the plural. So for example if you have a User model then you would have a properly named UsersControler.
Now Rails is a tool. It cannot stop you from doing otherwise. You can (and I have seen examples) name your model User and then have a SubscribersController and nothing can stop you. Now why this is bad boils down to:
a). Any other programmer that will come work on the same code, whether concurrently or later on if you leave the project, will be confused as hell. He knows that a User model has a UsersController but he cannot find it – chuck this to time spend being frustrated and unproductive.
b). Weeks, months or even years later you will have to revisit your code. Now it is you who is confused as hell, frustrated and unproductive.
Now this is the most simple example, but the paradigm applies to all facets of the code, from top to bottom, from the most used and core functionality all the way to secondary or tertiary design functionality, both back-end and front-end.
Please refactor your code. Yes you read that right, no I am not referring to your back-end code, I am still talking about your front-end code. Why should you refactor?
You refactor or “clean up your code” to make sure it is in-line with the guiding principles of good programing. To make sure it ends up being SOLID code.
This might sound good and all and I’m sure you can agree it applies to programming in general. But you might ask yourself “What does that have to do with front-end design”.
Everything. Front-end design is coding, period. The same programming paradigms and principles apply in one measure or another. Which brings me to my next point.
Specificity. More exactly Cascading Stylesheets (CSS for short) specificity.
Ever wonder how you can possibly do so much with so little? In essence CSS can and only works with a hand full of elements yet does so much it is mind boggling. And it doesn’t do it in a segmented fashion. Any good site loads fast and loads all together. You do not get the banner first, then the company logo loads, then the authentication, the top body of text and maybe the footer.
No, you get it in one big slice, all together, all at once – at least when good front-end design is applied and the internet is broadband.
So how does CSS do the magic that it does. Well one hint lies in the name: Cascading. Style is seemingly applied all at once but in order of importance. And the way the machine does this is by extracting and analysing specificity. It works like a points based system. It determines which rules get applied by the browsers.
You can think of it like this (although in truth the machine calculates specificity differently).A basic tag element gets a simple point of 1. A class gets 10 points and then the mother of over achievers – the id – gets 100 points.
You have a paragraph and you put it in a <p> tag. You want that paragraph to have be written in bold. So you declare that the p { text-style: bold; } ( in your style sheets of course, never inline, but more about that later). All is good until you decide that the body of text on the whole page needs to be perfectly styled. You place it in a <div> with the id=”container” and declare that is should have container { text-style : none }. Now you are in trouble. The largest portion and arguably the most important part of the site needs to be written sans text styling. But an inlaying paragraph must be in bold. What do you do?
Most beginner programmers (and some older ones too) will just give the paragraph an id=”important-paragraph” and style it p, .important-paragraph { text-style: bold; }
These examples are puerile but the importance they hold is not. It does not take allot of guess work to understand that the first problem you solved with adding a new id, will endlessly repeat as the application grows. And then change occurs – as it must – and you find yourself in the impossible situation of adding anything without breaking something else.
This touches on another programming principle: Decoupling code to avoid making it brittle and prone to “breakage upon change”.
So adding more id’s is bad because it leads to brittle and tightly coupled code. So when should you use id’s in your front-end design.
Never. Never use id’s for styling. The only situation when an id needs or should be placed in production code is when the back-end side of the application requires it. Not for design but to iterate a boatload of information in one specific place of the interface.
When it comes to design, stick to classes. And use as many as you need.
If you find that hard to believe, then just take a look at bootstrap, arguably the most loved and widely used front-end design library available on the market. It weighs exclusively on classes, and only classes. And when it comes to specificity, it just chains classes together.
In bootstrap a table gets basic table design by adding the class=”table”. A table with two differently styled rows, one with lighter and one with darker background color is created by chaining the table-striped class like so: class=”table table-striped”. Truth be told the order in which you write the classes has no relevance to the machine or the end result it outputs but neither did different named Models and Controllers in Rails. It matters however to the programmers who use the code since it improves readability, making it as unconfusing as possible.
A good design working practice is to implements new features on the way using small snippets of code. So you might start with just a working model that only has the layout implemented, namely how the screen is portioned and what elements go where. And everything works. Then you decide that some freshening up is in order. Do not make big changes all at once, do it in an incremental fashion. And remember to improve your code by refactoring every step of the way. Think of your design as a jigsaw puzzle. No matter how hard you want to do it all at once, the best, most straightforward and fastest way is to do it one piece at a time.
You finished doing the sidebar navigation, complete with drop-table functionality, links with hover actions and such. Take a short break and 30 minutes later read the code top to bottom and decide how can you “unclutter it”, what can you change to make it more simple, more straightforward and uncoupled from the rest of the site design. This is when having a fresh pair of eyes pays off. Ask a colleague to spend 5 minutes and check it up, then improve on it together.
Doing it one simple step at a time ensures that you won’t have to take giant leaps (and often blindfolded) later on.
Some other very good practices to adhere to will be discussed on a later date