Refactoring UI with examples

I recently read Refactoring UI, which was excellent. It’s chock-full of practical advice, and you can feel that a lot of hard-learned lessons were condensed into the book.

Here are a few small takeaways with examples of how I applied them at work.

Balance weight and contrast for icons

What makes bold text stand out? The answer is that even though it’s the same color as regular text, it’s got more “Pixels per cm” than regular text.

This is important when we think of icons. Icons can accidentally feel bold because like strong text, filled icons have more “Pixels per cm” than text. This can draw attention away from text, and onto icons, which is probably not your intention.

Take a look at these two screenshots:

In the second I’ve reduced the contrast of the only “filled” icon on the page, next to the text “onboarding checklist”. Before, it stuck out like a sore thumb even though it was the same color as the others due to its high color density.

It’s not a huge difference, but the principle is powerful. I’ll be looking out for “overpowering” icons now that I know how to pull attention away from them by tweaking their contrast.

Communicate hierarchy, not just semantics for actions

What’s wrong with this component?

On one hand the color helps make the semantics clear for the buttons. Red reinforces the destructive action, green the happy path, and blue the additional option. On the other, the design completely fails to capture their heirarchy.

Every action on a page sits somewhere in a pyramid of importance. Most pages only have one true primary action, a couple of less important secondary actions, and a few seldom used tertiary actions.

Primary actions should be obvious. Solid, high contrast background colors work great here. Semantics are secondary.

Secondary actions should be clear but not prominent. Outline styles or lower contrast background colors are great options.

Tertiary actions should be discoverable but unobtrusive. Styling these actions like links is usually the best approach.

This is an approach we’ve taken in AirManual, as you can see here.

Rather than using color to confer semantics, we’ve focused on conveying hierarchy. I think the result looks great.

Use as much of the screen as you need, no more

You don’t need to use the whole screen - if you only need 600px to show something, just use 600px.

This is something we’ve been successful with in some designs, but not globally across our application. Take the workspace navigator view for example.

Look at that, nailed it. Noticing and then applying this rule consistently, take a look at the effect on the team members page. Much less dragging your eyes from left to right is needed to review members and their permissions.

In summary

If you’re a software engineer who designs user-facing features, it’s worth learning about design. Refactoring UI is filled with advice, some of it nonobvious, about how to improve every aspect of your web app design. I have read more than a few books on UX and UI design, and I still came away with a good selection of tools to use in the future.

If you get the chance, pick it up!