Jan 15, 2021
Iterating on a Design Component
Solving key problems to enhance clarity and readability
Iteration is an integral part of the design process. It’s how designers work toward building a solution that meets customer needs and business objectives.
Recently, I received feedback on one of the projects in my portfolio. The feedback was in regards to a specific design component in one of my mockups. In order to incorporate and learn from this feedback, I thought it would be beneficial to walkthrough how I would approach iteration. Although this process may be unique to this specific component, it will help me focus on some key concepts that I might have been neglecting while designing interfaces.
Hope you enjoy!
Component Details
The component I’ll be redesigning in this article is called a navigation bar (Google Material Design Guidelines) or a tab bar (Apple Human Interface Guidelines) and it usually sits at the bottom or top of an app screen depending on how it’s designed.
Purpose
A tab/navigation bar allows users to seamlessly transition between different sections of an app.
Best Practice
This component works best when it contains 3–5 items (at least on mobile devices). According to Apple’s Guidelines, “A tab bar may contain any number of tabs, but the number of visible tabs varies based on the device size and orientation.”
Current State
With some baseline info out of the way, let’s now look at the current state of my component.
Questioning and Identifying Areas of Improvement
- Does readability take a backseat here? Both the icons and text are rather small
- The icons look to be incorporating a two-tone style, but is that the right decision?
- Is there a clear differentiation between Active and Focus states? Doesn’t look like it.
- Are there any systems in place here? Let’s incorporate a grid, consistent spacing and a clearer layout.
- Is this consistent with interaction and UI patterns seen in other apps?
Iteration Process
Now that we’ve identified what could be improved, let’s iterate.
Step 1: Set up guides/rulers (I’m using the iPhone X/XS/11 Pro dimensions of 375 x 812 here)
Step 2: Configure grid (I’m using the 8pt system)
Step 3: Since we’ll have 3 tabs in this example, lets create bounding boxes for each tab
We can do this by dividing the screen width by 3 (375 / 3 = 125). This means the bounding box for each tab has a width of 125.
Step 4: Above, we mentioned consistent UI patterns between apps. Let’s do some research into how other apps are laying out information.
My favorite place to go for this is mobbin.design.
Here’s what I found through my research:
- A common pattern is to have an icon with a label
- Some apps opt not to use a label, but I think we’re better off using a label to add extra clarity to our tab bar
- The inactive tabs are hard to read and present accessibility issues. To solve this, some apps highlighted the active tab with a brand color while maintaining a successful color contrast for the inactive tabs.
Example: Google News
Moving forward, I like Airbnb’s implementation of the tab bar. There seems to be sufficient spacing between the icon and the text label.
Step 5: Now that I have a good idea of how I want to redesign my tab bar, let’s move on to picking an icon set.
There are a ton of icon sets out there, but one I always gravitate towards is Google’s Material Icons. To keep things simple, we’ll use those. There are multiple styles we could use (filled, outlined, rounded, two-tone, sharp) so let’s turn to the Material Design Guidelines to look up some best practices.
After analyzing some of the other elements and brand principles of the app I’m designing this tab bar for, I decided to go with the filled + rounded material icons because not only is my interface dark and heavy, but it contains circular elements and curves.
Step 6: Icon + Label Size
Icon Size: We’ll stick with 24 x 24 dp, since that’s the standard size for icons in Google Material Design.
Label Size: On mobile devices, 16px is the default font size, so we’ll use that. You can also play around with font weight and casing. Since my interface is already dark, I think sticking with sentence case for my tab labels will be best.
It’s also worth it here to look into Keyline Shapes in Google’s documentation. Here’s how Google defines them:
Keyline shapes are the foundation of the grid. By using these core shapes as guidelines, you can maintain consistent visual proportions across system icons.
This is a term I originally missed while perusing the documentation. I’m pretty sure Keyline Shapes are guidelines for creating icons from scratch, so I don’t need to worry about them here (but correct me if I’m wrong). Just to be certain, I found these Figma files to help me line up my icons with keylines:
- Icons & You — Fundamentals Worksheet by Noah Jacobus
- Icon Keyline by Ragnar Freyr
- Icon Template by Gavin McFarland
Step 7: Remember those bounding boxes we created above?
It’s now time to place each icon and label in the center of those boxes.
Step 8: Customize as necessary
The last step is to tweak the colors and vertical spacing in between the icon and label to your liking, but be careful not to ruin the center alignment.
I also like to further prioritize systematic practices by aligning labels to the baseline grid. And, as often as you can, work in spacing, padding, and margin increments of 4 or 8.
Last, feel free to use Figma’s auto-layout and variants features when making components. And don’t forget to properly group and name your layers.
Results
Before and After
Looking at this design, I could also use the volt green brand color to make the Active State more noticeable.
Regardless, this tab bar would definitely take some user testing to perfect.
What other iterations would you make?
