UI/UX design best practices we learned from our experience

We’ve been creating custom web and mobile apps for more than 13 years. In all of that time, it’s no surprise that we learned a few tricks. And our focus has got more specific as we’ve headed towards design-driven development.

What is design-driven development, you might ask? Simply put, it’s a way of developing apps by designing them first. Less simply put, it means putting a lot of time and effort into outlining all of an app’s user flows, and then designing every page of the app the exact way it’ll look when it’s fully coded. All so that the coding portion will be much more efficient. Everything is structured and outlined, and the clients get to see most of the app before it gets to the most costly stage (code).

With all of this, we’ve learned a lot of important lessons about making designs suitable for code. After all, we’re creating apps, not art - it’s great if they look pretty, but they also gotta work. No use in investing in looks but not functionality.

So in this article, we’re going to talk about some of the biggest lessons we’ve learned about design, and hopefully you, too, can also learn from our experience, or from our free UI/UX assessment.

Ask all the questions.

Design projects often start with kickoff meetings. And these kickoff meetings can decide how well the project goes: inefficient communication, lack of questions and relying on your own intuition can lead to an app design that won’t actually be used (in other words, a waste of time and resources).

So here’s the thing: in our activity, we’ve learned that the key to leading successful UI/UX design projects is getting as much information as possible from the clients and their customers. After all, we can’t possibly have all the information right from the start. Especially if the client’s business is part of a more complex industry that we might be hearing about for the first time.

The best way to do that is to act like children, by asking “why” to everything the clients say about the app we’re building for them. Why do you do what you do? Why should people use your app? Why is your current workflow like this? Why do you want to build this app? Why do you need these features? And so on.

Of course, a lot of these questions are contextual. We let clients take the reins and freely talk about their business and what they need in the app we’re building. Depending on what they say, we’ll ask as many questions as we can, to fully understand their idea and thus figure out what they need. This is even more important if they’re building an internal business tool.

After we understand the client’s business and industry, we usually ask for a few more things to get us on the right track:

1. Do you have any visual branding guidelines we should follow? When working with established businesses, we often expect them to be able to provide a logo, some brand colors, fonts, illustrations, or any visual materials that represent their business and which can be used in their app. This, unless they’ve specified they want it to look different than their current branding.
2. Do you have any preferences on what the app should look like? A lot of businesses find us through our work with Creative Tim, specifically, through admin dashboard templates. So we often ask new clients if they liked specific templates and want to go for that style. Or if they liked any other styles, if they prefer certain colors or fonts, and so on. A less official visual branding guideline.
3. Can you provide us access to your current app? We work with a lot of businesses that have an app already. And if we’re doing redesigns, or user flow improvements, we of course have to be able to see their current app with our own eyes. 

Of course, our communication channels with clients don’t end after the kickoff meeting. There’s no way we can know all we can ask right away. A lot of stuff comes up during the designing process. So what we do here is establish a consistent line of communication with the client’s team, especially with those who hold all the useful information (like product owners or project managers).

Sit down and brainstorm

Great apps and user flows can’t be created instantly. Especially if we’re talking about a more complex project, with a variety of user types and required features. It’s easy to unintentionally build a clunky app, and it doesn’t mean you have to.

In UI/UX design, you must never neglect one for the other - that is, don’t sacrifice UX for a pretty UI, or the other way around. You can totally do both, and we’ve managed to pull it off many times. Use submenus instead of creating clunky sidebars, hide advanced options under other menus, and keep contextual help simple and concise, would be just a few of our tips.

When starting a new UI/UX design project, after gathering all data you need to map out user flows, it’s best you take your time and brainstorm ideas. This is especially useful if you work with an entire team: everyone will have their own ideas and you should sit down and put them together. In our experience, some of the best ideas come out of team brainstorming sessions.

So gather your team members and:

1. Put all your info together. Make sure, this way, that everyone in your team is on the same page and you all have the same understanding of the app concept and requirements.
2. Map out the app user types and differentiate them. Start from the role with the most permissions as you’ll only have to remove them as you move onto the other user types. You’ll have to divide users this way anyway, so it’s best you do it from the start.
3. Create a visual board of your UI ideas. This will help you picture how the user flows and the UI will blend in together. Maybe decide on a final navigation structure, to be able to place features within the app.
4. List the main goals the app is supposed to achieve. Once you know what the end road for a user in your app is, it’s easier to map out how they should get there.
5. Discuss the best ways for those goals to be achieved, while keeping account of what you know about the users. This is where the most important brainstorming work is done, and let yourselves really think about it. Rushing this process can lead to sloppy work, or features that don’t properly fulfill what the app users need.

Once you’ve come up with enough concrete ideas (and don’t stop if you haven’t), start designing the app. Don’t rush into it and don’t be afraid to contact app stakeholders if you realize you don’t have all the info you need to map out all the flows. As we mentioned previously, ask all the questions you can.

The right way to get started: setting up your design file

Okay, there’s no serious rule out there on how you should begin a new UI/UX design project. It’s everyone’s choice, after all. One way is starting out with the first page right away, using it as a way to figure out the app’s overall visual style and appearance. It might not include all design elements right away, but you’ll get to them one by one.

Another way to get started is what we like to do: setting it up first. What does that even mean, you might ask? Setting up a new design, with the software we use, Figma, means creating our own little UI Kit. Colors, typography, shadows, icons, and even a few run-of-the-mill components like buttons and inputs. 

That seems like a lot of effort right away, but it’s worth it down the road: starting without this foundation can lead to pure chaos. Having 20 different shades of gray. Finding colors you’ve used before with the eyedropper tool. Copy and pasting text from one page to another. Scrambling to find one visual element you’ve created that you want to use again. 

You might not be able to foresee these at the beginning, but with projects that can branch out into long term endeavors, not having a stable base will make the design crumble down throughout time. You’d be working through chaos - and that’s not just for the designers. A chaotic design file will be difficult to code as well. Worse if it gets passed down from a developer to another.

So now that we’ve told you why you should start by setting up, here’s how we actually do it.

Typography

A lot of your design will be centered around text, so it’s best you start with this. You’ll need to pick a font (sometimes the clients you work with have a visual branding guideline, so if it comes with a font, go with that one) and then you’ll have to create a scale of text samples from big to small, in different font weights. 

The font weights will depend on the font you choose, but for variety, your typography scale should provide the following: regular, italics, medium, semibold, bold, extrabold. If the font you pick doesn’t offer this many font weights, no worries, just use the ones you have.

In terms of the font size scale, this is pretty standard. We’ve taken Tailwind rules as an example, as following these makes it easier for the developers to implement our designs.

Source: Flowbite Tailwind Cheatsheet

Do I really need this many, and so big, you might ask? Not really. It depends on what you’re building, but if it’s an app (and not a presentation website) you don’t need the biggest ones. It’s highly unlikely that you’d use text bigger than 64px. Even that is quite a lot.

Here is the typography scale we usually go for:

1.) Display 1: big titles for presentation pages, especially hero elements, at 64px. In admin panels, the display elements are suited for log in, sign up, help, 404 error, and other pages as such.

2.) Display 2: a smaller version of that, at 40px

3.) Heading 1: the biggest type of body text, mostly for page titles, at 30px

4.) Heading 2: second biggest body text, for headlines within a page, at 26px

5.) Heading 3: the middle child of body ext, for subheadlines, at 22px

6.) Heading 4: a smaller title, at 18px

7.) Heading 5: a more regular-sized title for smaller elements like modals or input labels, at 16px

8.) Paragraph: regular body text, at 14px

9.) Subheading: smaller body text that can be used for bits of information or small buttons, at 12px

We usually put all of these together into one page, and then we set them up as styles in Figma. Each text size in each font weight is a unique style, so they have to be separate text elements. To set them up as styles, select your chosen piece of text, head to the right side menu, to the text portion, click on the 4 dots icon, and in the dropdown that opens, click on the plus icon. A new dropdown will open, in which you can name your style.

Naming is very important when setting up styles in Figma. Why? Because Figma allows you to split styles into parent elements and child elements, in other words, you can easily sort text styles by size. All font weights for H1, for instance, will go together. 

The way you do that is by structuring the style names like this: “Text size/font weight”. So a bold H1 text would be named “H1/Bold”. A semibold H1 text would be “H1/Semibold” and so on. As you’ll see, this naming convention applies to a lot of elements in Figma.

You can arrange everything prettily on its own page, but it’s not mandatory. What’s most important is having them set up as styles.

Colors

Here’s another fun element that relies on an app’s branding. The colors you’ll use in the app you design not only represent the client’s business, but also the app’s own identity. In other words, it would be a bit weird to use pastel pink tones in an app for oil engineering.

But that’s not really what this is about. When you get to setting up colors, the most important thing is being a minimalist. No one needs 30 shades of gray in a design. Especially if they all come in different tones. And plus, that makes development more difficult as well.

When starting a new design, setting up all the colors from the beginning will make it much easier down the road. You’ve already got a starting point, and if you set them up as styles (in Figma), you can go back and change them without having to manually edit all the elements you applied color styles to.

What we usually do here is we pick 2 colors, one will be the primary color and one will be the secondary one. These 2 colors have to work well together, so we usually pick complementary or analogous shades. This, of course, requires knowing a thing or two about color theory - YouTube is a great resource for this.

Then we pick a dark neutral color, the darkest one we’ll use (usually for text). We make sure it goes well with the first 2 colors we chose (by literally placing them next to each other) - but since we’ll set everything up as styles, we can always come back and make adjustments. Then we pick a red and a green, for success and failure elements (alerts, buttons, messages - anything that points to a process that can go well or not).

For all of these colors we usually set up 10 shades, from dark to light. To determine what those shades are, we use this tool from Google’s Material Design. We put in the main color in the small input from the top right panel, and the tool generates 10 shades for that color. We repeat this process for all the colors we pick for a design.

Similarly, if you’re given a color palette from your clients, it’s best you use a tool like this to get 9 more shades of each color. This is especially important for neutral colors which you’ll use for text, shadows or borders.

And of course, a crucial part of this is naming them strategically, especially if you’re working in Figma. Just like typography, color names will help split them into categories and subcategories. For these, the first half of the name will be the name of the color, and the second half will be the specific shade. 

In web development, shade names are usually represented by numbers: usually from 900 to 50, from darkest to lightest. And since it’s kinda weird to name shades “kinda light”, “lighter”, “much lighter”, it’s best to follow this strategy in design as well. 

So in this case, colors can be named following this template: “Color Name/Shade Number”. So the darkest primary color will be named “Primary/900”. This way, when accessing all color styles, they’ll all be sorted logically (by color and from darkest to lightest).

So what’s the benefit of doing all of this? 

1. Being organized. Using random colors and shades gets messy really quick. It might seem faster at first, but after 10-15 screens you’ll realize it’s pure chaos. What color is used for what? You’ve no idea anymore.
2. An organized color system, especially with 10 shades per color (or 5), can be easily transferred into code. Your design won’t look like an entirely different thing when it’s been coded.
3. A more efficient designing process. All colors are set up, you just have to apply them to items. No figuring out shades on the spot any time you want to make something darker or lighter. Changing the main styles automatically updates all the colors throughout the design.

Icons and some basic components

You’ll use a lot of icons when you begin a new design, especially if it’s an admin panel. You’ll have a sidebar menu and a header, both of which usually contain icons for the menu items, search bar, notifications, user settings, or others. Some of these icons you’ll probably reuse.

So our strategy for this is picking an icon pack right at the beginning (after setting up typography and colors, of course!) and importing as many of them into our Figma document, then turning them into components. This way, they’ll be easy to find in the Assets panel and they’ll be swap-able.

And most importantly, setting up icons this way makes it quicker to add icons to a design later on. Otherwise, everytime we need an icon we’d have to stop in our tracks and head to a website, search for an icon, download it, and add it to the design file.

Something else we’ve learned to do through our experience is creating a few basic components right at the start. This is crucial for apps that have a lot of forms in them - outlining what inputs will look like right at the start will make it so much faster to build those forms.

Here are some items we usually create as components before making any full screens:

1. Buttons - we’ve set up typography and colors already, which are the main 2 items that go into buttons. They’re some of the most basic and fundamental design elements, so it’s a good idea to create them from the start. We usually create a primary and secondary button, with additional states if we know we might use them. For instance, active and disabled buttons.
2. Inputs - a lot of apps we work on are admin panels with lots of forms. Since we often know that from the start, we create inputs as part of our set of basic components. Especially in multiple types and states. This speeds up form creation by a lot, since they become easily swap-able.
3. Toggles, checkboxes and radio buttons - these are also very common form elements, so having them created straight off the bat will speed things up down the line (like all elements we’ve talked about so far). We also make these in multiple states (selected/unselected) to easily swap them.
4. Table components - this is especially useful for admin panels with lots of tables. Nowadays, we build tables cell by cell (as if it’s an Excel spreadsheet, if you may) as they’re easier to group, rearrange and edit using auto-layout. So we’d create a standard header cell and a standard row cell, then head into variations of those, if needed. So maybe a header cell with a sorting option, one with a checkbox, one with both - all of which will be easily swap-able after being turned into components.

Auto-layout everything

What was life like before Figma’s auto-layout? Honestly, we don’t remember. This tool is so crucial to our design process that we never go without it. It speeds everything up immensely, and it makes it so much easier to edit design elements. Add a full comment section to a dashboard card without having to move everything around. Add an extra table row and everything moves down by itself. Sounds great, right?

The basis of auto-layout is starting everything off with text - unless there’s no text in what you’re making. If we’re making an input field, a piece of placeholder text comes first. That text gets turned into an auto-layout frame. We give that frame padding all around, then pull on its right end until it’s long enough to look like an input. Then we create another piece of text to represent the label, and we group the input and label using auto-layout. Boom. Not more than 5 minutes and you’ve got an input field.

But by far, the biggest advantage of auto-layout is how easily you’ll be able to move things around once everything is fully set up. The trick here is pre-planning every element on every page piece by piece, creating a logical structure for them.

That sounds really vague, so let’s get into the perfect example: modals. Modals are usually composed by a header area, content, and a call to action section. Those are 3 sections you can build individually via auto-layout.

The header is usually the modal’s title, so we create that piece of text first. Usually the header contains an X icon as well to close the modal, so we’d bring in an icon and group it with the title. The title’s horizontal resizing will be set to “Fill”, via the top part of the right side menu. This way, you can extend these 2 and the X icon will always stay on the right end of the header. Add some padding, a background color, and the header is done.

The content section, of course, depends on what the modal is for. But what we usually do here is focus on the spacing between elements - if everything will be at the same distance from one another then we’ll create each element and group them using auto-layout. But if some items should go closer to one another, we group them by spacing rules: a title and description will go together at 2px apart, and those 2 and a series of inputs will go together at 24px apart (as an example).

Lastly, the call to action section is usually a group of buttons. We’ll put those in, group them using auto-layout, give them padding, and choose a position for them. In our example, we aligned them to the right using “Fill container” as its horizontal spacing rule.

Once these sections are done, simply group them using autolayout. If you haven’t added backgrounds or padding to the individual sections, you can do so here. With this setup, if you choose to add more elements to the modal, place them within one of these auto-layout groups. This way, everything will rearrange itself. Play with resizing rules in the upper right menu until you get the effect you’re looking for.

PS: if you’re making a modal element as a component, think of all variations you might need of it and make them from the start. Figma won’t be as flexible with components, so provide yourself that flexibility ahead of time.

Passing the project onto developers

Once a UI/UX design project is done, it moves onto development. And if the same teams of people do both parts (within the same company), it’s easier to onboard developers onto the project. But only if you do it properly: since we’re all human, there’s a lot of space for miscommunication.

And so, when heading into development, there are a few things you should do to effectively onboard developers onto the project. It mostly relies on communication, so be open to sitting down and talking to the developers until you’re sure they got all the information.

Walk them through the design

The first thing you should do when onboarding developers onto a newly finished design project is to walk them through the design file. Explain the app flows while highlighting the differences between the app user types. Go through each screen one by one and tell them what every button does (unless it’s something obvious).

Additionally, you can also show them the best ways to get code details for all the elements, as developers will not be well-versed in Figma. Specifically, in more complex setups where items are layered and put together into multiple auto-layout frames, it will take several double clicks to reach an individual item. Developers aren’t always aware of that, so be sure to show them.

Otherwise, you risk them going rogue and measuring spacing, padding or font weights by eye - when you might have measured everything meticulously when designing.

This part of the process is of course very useful as you’re explaining the app flows to the developers, and they’ll have the info they need to start coding. It would be hard to code an app when they don’t know what it’s supposed to do, right?

Writing efficient user stories

Another great way to onboard developers is by writing good user stories. We wrote an entire series of articles about writing user stories based on designs, but we’ll give you a quick rundown of how we do this.

User stories are a key part of development projects, as they clearly map out an app’s features and they also serve as a tool for creating development estimates. But they’re also a great way to explain features to developers while linking to the design - they can view these side by side and get a visual representation of all the stuff described in the user stories.

This is best done with a design-first approach, as the user stories would be written based on the final design, and they’ll be easier to understand as they come with visuals.

Efficient user stories are those that give all necessary information, by describing all app actions step by step and covering all possible situations. If a specific flow can end in success or failure, describe how both of these end - if it’s successful, a green alert would show up; if it’s not, an error message would appear. Make sure to explain the flows in simple terms, and act as if you’re telling a story. Like you’re someone using the app and you’re wording out everything you’re doing.

And there you have it, these were some of the UI/UX design best practices that we’re learned over the past years. All in all, you learn a lot by doing, and through mistakes. But the key is putting those lessons into practice and constantly improving your UI/UX skills.

Did you like hearing about our UI/UX design best practices and you want to see them in action? Contact us and let’s see what kind of software we can build together.

If you liked this article subscribe and get an email when we publish new, juicy stuff. We hate spammers, so we don’t spam.