I figured out that I was implementing the user interfaces in the wrong way!
As a front-end engineer, most of my work is developing user interfaces.
In most startups I worked for, I may find a designer who designs the interfaces but sometimes I become a Designer and a UI Developer at the same time.
Besides that, I was struggling to design these user interfaces when I developed my side projects.
It’s not about tools that should I use like Figma or Invision!
But it’s about these questions that come up each time when I develop a new feature or an application:
1. How can I make the interfaces achieve the goal of the product?
2. Which kind of element (component) should I use for this interaction?
3. Should I start with the header or with the Signup form?
However, I found that I didn’t have any knowledge about Design Tactics and I decided to learn it not as a designer but as a frontend engineer.
As you know, there are thousands of resources to learn UI Design but my goal was not to know everything or every detail.
My goal was to learn Design Tactics from a front-end developer’s perspective.
I started reading books and blogs from experts in UI Design but I was focusing on those who have a piece of technical knowledge and understand a little bit of HTML, CSS, and JS.
Meanwhile, I was at that time reading a book You Don’t Know JS book to learn JavaScript in-depth.
I spent at least 6 months reading several books about user interface design and the ones I loved most were:
- Refactoring UI by Adam Wathan and Steve Schoger.
- Don’t make me think.
- Practical UI by Adham Dannaway.
But why these books?
I found that these books focused on what I want to know about UI Design and Adam Wathan the author of Refactoring UI is an engineer. He’s the creator of TailwindCSS.
I learned a lot of topics such as :
- Design hierarchy.
- Color philosophy.
- Layouts.
- Spacing and Sizing strategy.
But guess what the book `You Don’t Know JS` inspired me to create an open-source documentation and recipe with my style to share what l learned and let other frontend developers benefit from it.
I named it You Don’t Know UI.
I define You Don’t Know UI as:
A collection of tips for frontend engineers to avoid mistakes when the build their user interfaces.
Let’s start with the first tip which is :
Think in a feature, not a layout
I remember my self how many months I wasted when I was creating an MVP ( Minimal Viable Product ) for an idea.
I spent nights and nights refactoring the user interfaces by changing just the places of the components and the layouts. Don’t be stupid like me!
When you start designing a new user interface for a web or mobile application, most of the time you think about the structure or the position of your components, so you start designing the Header or the Top Navigation as your first component in your UI.
Me too I was making this mistake!
Do you know why it’s a mistake?
Because you’re limiting yourself from the beginning.
Because you’re seeing the App Design from Top-To-Down or Down-To-Top while the App Design is a collection of features.
You’re not building a house here using LEGO bricks! But you’re building a car and you can start designing the engine or the wheels, right?
Most folks try to copy & paste from popular websites and apps, without knowing the Standards or the Design Decisions for each product. This is the easiest way to find themselves frustrated, and limited and they figure out that they overthink only on Generic Things.
They focus on the shape of their app but not the core features, and they start asking frequently these questions :
Where should I put the Logo?
How many items should I have in the navigation bar?
Should I have one or two sidebars?
Should I have a Grid Layout or a Table of items?
But, what you don’t know ( maybe ) is UI Components or elements are made to solve certain problems that are related to:
- user interaction
- data displaying
- or new device screen invention
And you may have noticed that the Humburger element has started to be well-known in mobile devices.
We are not designing user interfaces but we are designing and implementing features, and Top Navigation is just a common feature that helps users to do quick navigation for certain and most important pages.
So, don’t care about common features or what I call them Generic features or layouts.
Instead of starting with a layout, start with a feature or a specific functionality, and not any feature but the core feature of your product.
Let’s say you’ll build the next-gen social media app for sharing videos. You could start with this core feature: Share a short-form video.
The UI will need :
- A field for uploading a video
- A Field for the caption
- A field for the description
- Button for posting or sharing
- Button for saving in draft
These are the requirements to design your UI.
Design few, Implement few, Repeat
I have this question for you:
Why do you need to design a perfect user interface with all the details and then implement it?
I have another question for you:
Did you feel frustrated in the stage of implementation of a new feature because the design does not consider programming limits?
My last question is:
Why do you focus on details in the early stage of the design?
Ha!
I know you’re thinking in Agile but you’re working with the Waterfall approach.
Indeed, people get confused when they switch from one task to another per day even in the same domain, it happens to me usually, especially when it comes to designing different concepts of user interfaces per day.
Furthermore, people want to start a thing and finish it one time.
They want to make it perfect from the beginning!
Even with low resources and in limited time. It happens most of the time in early-stage startups.
So, let me tell you something:
Details do not matter when you start from scratch.
The hard thing about the design is when someone asks you:
Why did you make this decision?
Why did you choose this palette of colors?
Why did you choose this type?
Why did you choose this style of icons?
If you don’t have a Design System in place, creating consistent user interfaces is very hard, and focusing in-depth on details will lose time, effort, and of course the consistency of your user interfaces.
So, what’s the solution here?
As I mentioned in the title: Design few, Implement few, Repeat.
In the earliest stage of the new design or new feature, you don’t need to stick to the high-level decisions about the foundation of your design ( Spacing, Color, Typography, Iconography).
I know they matter but not in the beginning, right?
Let’s say, when you were having a shower you came up with an idea for a new killer feature, and you want to make it more tangible for your teammates and the stakeholders to get buy-in.
Adding new features means a new investment of money and time and what matters later for any company is: Revenue.
The first thing, you need to do is ignore all details ( nice-to-have ) and just focus on the requirements ( must-to-have ).
So, I recommend this workflow to get quick both internal and external feedback:
Create a hand-drawn version.
As you see here, there are zero details about your user interface in production, but why does this step matter?
This hand-drawn activity may take between 5min and 20mins if you want to make it a high-fidelity drawing!
In fact, this step will help you to see other teammates' and stakeholder’s opinions and gather individual recommendations from each member of your team.
People cannot recommend changes when they see a well-done thing.
But they can tell you how can you make it better when you deliver it clean but incomplete and ugly.
It’s human nature.
Ignore colors.
When I was a kid, I remember my Dad when he was buying a paint book for me. The content was grayscale images and my mission was to colorize these images using wood colors. Sometimes, I and my friend have the same image but when we colorize we end up with different looks! After that, we go to family members and ask them which one is better.
But how can we adopt this workflow in our design?
The idea is to hold the color even if you refine your design in higher fidelity. Let people tell you how are the shapes, sizes, spaces, and the position of your elements.
Implement the UI.
Modern frameworks and libraries such as Vue, React, and Svelte were created for Rapid Prototyping which means you can implement one component and use it with different looks in different positions. So, you don’t need to have a full prototype with all user interfaces to start the implementation.
It’s a little bit challenging, but I can say that you don’t need to regret the time you spent designing the perfect UI that you’ll never see in production.
The goal of this step is to test the back functionality ( How it works ) of the UI without sticking to how it looks for users.
Colorize.
If you don’t have a color palette in place, you can try several colors and see the consistency between them based on color theory rules.
Repeat.
Our purpose here is to prevent over-investing and move fast by doing parallel iterations on both design and code in a short time, so you can build real thing as soon as possible. In the end, what matters is your UI in production.
Details Matter, But Later
Which option will delight the users?
This is the frequent question I ask myself in my work basis. Hope I’m not the only one!
Designers and engineers waste more time on details and minor decisions in the early stage of designing and implementing new UI but they should realize that designing UI is an iterative process.
In fact, it’s better for you to not stick to minor details in the early stage of any task. You don’t want to hear from me how many hours or maybe days I spent changing the font size by adding or reducing 1px.
Do you think that users will notice these changes?
Do you think that adding 1px will add more revenue to the company?
Please, don’t waste your time on these changes in the early stages.
From Speed Dating Decision Making — Why Less Is More:
Yet new research does point out a different dating problem: being confronted with a large number of choices can make it harder to make a good decision. In fact, it can even prevent you from making a decision in the first place.
When you’re designing without constraints, your process will be very slow, and you will never end up with a choice. Let me clarify with this example:
As you see in the above image, the first scenario is for a buyer who wants to choose a flower for his wife but he’s seeing flowers with different colors and they are almost similar which makes the decision so hard for him.
The second scenario is for a designer who gets confused between these buttons where it’s almost impossible to see the difference between their background colors.
The fact is when there were too many choices people became confused and didn’t make a choice when there were too many options.
People who had few options chose more often and were happier with their selection. So, you need to stick this rule in your head: Limit your choices.
So how can we limit our choices for our user interfaces?
Systematize colors
When I was a student, I remember when we were working on the design of the website with my teammate, and because we did not have a system for the colors, we picked a color randomly each time from the color picker and we saw how the color looks in the UI.
However after I discovered and read Material Design, I figured out how companies choose their colors.
So, instead of hand-picking values randomly, create your palette from the beginning, dozens of online generators can help you to make your decision. You can choose from 6–8 shades and expand when you need more colors.
Choose one or two font families
It’s hard to achieve consistency in UI and most of the time over designing is the reason behind losing it.
Having more than two font families will make your brand less-memorable like the logo and the content becomes more inconsistent for the reader. Obviously, choosing the font family is very hard in the early stage and my recommendation is to choose the one that fits the personality of the product.
Systematize font size
Similarly, don’t do what I was doing by adding or reducing 1px until it looks perfect. You may waste 2 hours without making a decision. Instead, create a stylesheet for your typescale in advance.
Systematize icon sizes
Defining a system for the sizes of the icons in advance will save you time later.
For example, you can constrain yourself by a 4-based or 6-based scale. Your options will be :
12px, 16px, 20px, 24px, 36px, 48px, 64px.
Systematize opacity values
Opacity values confuse me a lot because it’s so hard to see the difference between them.
Personally, I choose a 5-based opacity scale and I limit myself to 4 values:
12.5%, 25%, 50%, 75%.
In CSS3, this is equivalent to:
opacity:0.125;
opacity:0.25;
opacity:0.5;
opacity:0.75;
Having some choice is better than having no choice at all. But there is a limit. As it turns out, having more choices isn’t always a good thing.
Create design systems, not pages
Please continue reading this tip at: https://github.com/MenaiAla/You-Dont-Know-UI?tab=readme-ov-file
Don’t hesitate to share your thoughts.
