This content originally appeared on DEV Community and was authored by Juan Emilio
Hello everyone, I'm Juan, and today I want to share some of the things that I've learned while reading Refactoring UI. It's amazing how much you can learn from the right book.
Not so long ago, I started working on a new project of my own, and to my surprise, I found myself trapped and blocked with the UI that I was designing. I couldn't decide on colors, sizes—basically anything important for a UI was escaping me. So I decided to do what I always do when I don't know how to proceed: find a book that I think has the answer to my problem. Worst case scenario, I'll learn something new. To my surprise, Refactoring UI wasn't just the solution I was looking for; it also rekindled my interest in UI design. So if you need something like that, prepare yourself, because we are going to check out the most disruptive and interesting lessons I learned from this book.
From now on, I invite you to check out the book and buy it because there's no waste. With that said, let's proceed.
1 - Do It and Do It Fast
Probably the reason why this lesson struck me as so interesting is because lately, I've been talking and writing nonstop about the importance of finishing a project before obsessing over the details.
In the earliest stages of designing a new feature, it’s important that you don’t get hung up making low-level decisions about things like typefaces, shadows, icons, etc.
\ - Page 10
I found this reaffirming, and not only that, but the book proposes an exercise to make this process even easier. Take a sharpie and draw on paper; it's really hard to obsess over the details.
2 - Not the Layout but Instead the Feature
What is an app? Try to come up with an answer before moving on. An app is a collection of features, at least that's what Refactoring UI tells us:
The thing is, an “app” is actually a collection of features...
\ - Page 7
This answer was a breakthrough for me. It made perfect sense—we are designing an app, not a layout. So we shouldn't waste so much time starting the house by the roof because the details will be clearer once we have a collection of features to fill that layout.
The easiest way to find yourself frustrated and stuck when working on a new design is to start by trying to “design the app.” When most people think about “designing the app,” they’re thinking about the shell.
\ - Page 7
3 - First in Scale of Grays
This is something that most of us probably know but ignore, I don't know why.
We are still in chapter one, and the book keeps telling us to stop worrying so much about things that can be polished once the features are ready. The aspect that we are "neglecting" now is color, and I couldn't feel more at peace about it. I can't even count how many times I found myself stressing over the colors of my application. So instead of spending so much time thinking about the colors, the book suggests developing the features in a scale of grays, always keeping in mind the hierarchy that we are transmitting with contrast, size, and space.
4 - Get Some Personality
Every design has some sort of personality. A banking site might try to communicate secure and professional, while a trendy new startup might have a design that feels fun and playful.
\ - Page 17
This is something we normally underestimate, forgetting to choose a personality before starting to design. In my case, the application I am currently working on wasn't looking quite right; it didn't have any personality. Finally, I decided to go for something formal, conveying that characteristic sense of "We know what we are talking about."
It's still a work in progress.
5 - Systematize Everything
The more systems you have in place, the faster you’ll be able to work, and the less you’ll second-guess your own decisions.
\ - Page 27
How many times have you found yourself asking: "What size should this be?" or maybe repeating a decision over and over again? The book strongly encourages us to develop following a system. I might add that a good solution to avoid falling into the complicated task of creating your own system is to copy someone else's system, like the one Tailwind is using.
6 - What's the Priority?
Have you felt that you don't know why your UI seems flat? I've asked myself that many times. I used to think it was because of the lack of animation in my app, so I added animations. That didn't solve it, so I thought it was the color scheme; it wasn't. This book gave me the answer:
Visual hierarchy refers to how important the elements in an interface appear in relation to one another, and it’s the most effective tool you have for making something feel “designed.”
\ - Page 30
There you have the answer: visual hierarchy, reducing the noise in our design, helping the user to pay attention to what is most important on the screen. Playing with contrast, color, size, and space—those are our tools to achieve it.
Before moving on
If you are enjoying my content or find it useful, give me a follow and leave me a comment or like—that's always helpful. I don't want to stop you, so enjoy the post, and thanks for reading.
7 - Don’t Use Gray Text on Colored Backgrounds
I've included this because it is an error that I used to make when trying to create hierarchy in my UI.
Making the text closer to the background color is what actually helps create hierarchy, not making it light gray.
\ - Page 37
Just a little hint, worth mentioning.
8 - Balance Weight and Contrast
Have you ever noticed that when you add an icon to your app, especially the ones that are filled, they jump out of the screen? Well, that's because the icon is covering more surface in the same amount of space because it uses the empty space inside it. This can break your hierarchy, and as we saw before, it is probably the most important aspect for a UI in order to look "designed."
To avoid this happening, we are going to reduce the contrast with the background by changing the color of the icon to a closer color to the background.
9 - Start with Too Much Space and Go Down
One of the easiest ways to clean up a design is to simply give every element a little more room to breathe.
\ - Page 56
It may sound absurd, but every time you start to design something, add a little bit more space than you would initially. For example, normally I start with padding-4 on Tailwind; now I'm starting with padding-8.
Increase your gap, increase your padding, and increase your margin. Later, you can go down, but let's start with more empty space.
10 - How Much Width Do You Need?
I love designing for mobile—it's much easier, less space, less content. Just properly position your items on the screen, and everything works perfectly. Try to take that same approach to desktop, and surprise, surprise, your application feels strange.
The book gives us a solution:
If you only need 600px, use 600px. Spreading things out or making things unnecessarily wide just makes an interface harder to interpret, while a little extra space around the edges never hurt anyone.
\ - Page 65
In the same way, just because you shrink your canvas doesn't mean that everything has to behave that way. You might use full width on your navbar, but shrink your dashboard. Play with combining these ideas and remember:
Instead of sizing elements like this based on a grid, give them a max-width so they don’t get too large, and only force them to shrink when the screen gets smaller than that max-width.
\ - Page 77
11 - Hide Actions for Data the User Hasn't Created
Another thing that may be obvious but that at least in my case, I always forgot to take into consideration. Let me show you something from my application again:
This is the customers' dashboard on mobile, and this is what's going to be displayed once the user loads data. But what is he going to see if there is no data?
Not that pretty, right? But that's the default state of the application. What do you say if we contemplate this state?
Much better. That's basically what the book is telling us to do—contemplate these little but important states.
12 - Use Fewer Borders
When you need to create separation between two elements, try to resist immediately reaching for a border.
\ - Page 206
Using borders can add noise to the UI, something that we are trying to avoid. So instead of adding borders, a better approach would be:
What better way to create separation between elements than to simply increase the separation?
\ - Page 209
That extra space automatically causes the visual effect of differentiation between elements.
Wrapping Up
I hope you find this post useful. This was an exercise for myself, trying to summarize a 300-page book into the things that were most helpful for me. Originally, this post was going to have 25 lessons, but I think it's better if I leave it at just 12 lessons because these are the most helpful, at least for me.
Once again, I invite you to buy the book because it has a lot more information and beautiful examples than the ones I mentioned here. So please take a look.
Before You Go
Thank you for reading, and if you really enjoyed the post, would you help me pay my rent?
[---------------------------------------------------------------------------] 0% of $400, let's pay my rent
This content originally appeared on DEV Community and was authored by Juan Emilio
Juan Emilio | Sciencx (2024-07-09T21:16:44+00:00) 12 Lessons for a better UI – Refactoring UI The Book. Retrieved from https://www.scien.cx/2024/07/09/12-lessons-for-a-better-ui-refactoring-ui-the-book/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.