Refactoring UI

Refactoring UI by Adam Wathan & Steve Schoger notes

Starting from scratch

Start with a feature, not a layout

  • Never start a new design for an idea from a layout. It would be the easies way to get frustrated and stuck. Many do the mistake of thinking about the shell when thinking about the design of a new app idea. Don't be like that
  • A new app or feature is a collection of smaller pieces, at first you will not have the information you need for a design. So don't design for the nothingness
  • Start with a piece of functinality, and the requiremetns it would have (data input, cta, ..)

Details come later - Build low-fidelity first

  • In the earliest staging of designing, it is very important to not get hung up on low-level decisions, it will matter eventually but not right now
  • Tip: Use a paper and a thick sharpie to ignore such small details when designing. It will be impossible to obsess over such small details with a sharpie. Great way to explore different ideas.
  • Hold the color ,doing this will force you to use other resources (spacing, contrast, size..) to do the heavy lifting. Will end up in a clearer interface that can be easily enhanced with color.
  • Use low-fidelity to move fast. Sketches and wireframes are disposable, use them to explore ideas an leave them behind before building the real thing. This will exponentially increase the ETA for the real thing

Don't design too much

  • You don't need to design every single feature in an app before you move on to implementation; in fact, it's better if you don't
  • Work in cycles instead of designing everything upfront. Start with the simplest version of the next feature. Complexity will come your way but it is a lot easier to fix design problems in an interface you can actually use than imagining every edge case
  • Build the real thing ASAP so thtat your imagintion does not have to do all the heavy lifting, avoiding getting overwhelmed by working in the abstract.
  • When designing a new feature, expect it to be hard to build. Designing for the smallest useful version reduces risk of not having it at all due to complexities along the way.
  • It is nice to have = design it later

Choose a personality

  • On the surface, giving a design a particular persoality might sound abstract but a lot is determined by a few solid, concrete factors

  • Typography plays a huge part in determining how the desing feels

    Font choice

    • Elegant and classy -> serif

    • Playful -> rounded sans serif

    • Plainer look leaving other elements provide personality -> neutral sans serif

    • There's also a lot of science on the psychology of color. How do different colors feel to you?

    Color

    • Safe and familiar -> Blue
    • "Expensive" and "Sophisitacated" -> Gold
    • Fun and not so seriuous -> Pink
    • However, trying to choose a color just based on psychology is not practical but can be helpful to think why that color is the right fit.

  • As small as border radius might sound, it can have a huge impact on how the overall app feels. Whatever choosen, stay consistent mixing does not look good.

    Border Radius

    • Small -> Neutral, does not really have much personality
    • Large -> More playful
    • None -> Serious/Formal

    Language

    • It is not a visual technique per se but the works used can define the overall personality and have a massive influence. less personal tone might feel more professional while fiendlier will make it, friendlier

Limit the choices - Avoid paralysis by analysis

  • Having millions of colors, fonts, images, etc might sound good at first but can turn into overwhelming, paralyzing curse.

  • When desiging without constrains, decision-making can become torture (there is always +1 right choice)

  • Define systems in advance. Don't hand-pick values from a limitless pool. Start with smaller set of options

    • Define a small set of colors or a restrictive scale for font size or border radius
    • This way the hard work is just done once (initially) instead of every time a new piece of the UI comes into play

  • Using a defined system makes decision-making easier as there are "fewer" choices. It also helps in the process of elimination

    • Picking the best option for a button might seem trivial but can be difficult. Start with one option and try other values in comparison (outer and inner). If outer or inner look better, keep reapeting until satisfied

  • Once you have defined everything, systematize everything (font, color, width, heigh, shadows, ..). You'll work faster and have less second guess decisions. Not everything should be defined ahead of time but having a system-focused mindset will help easing the task.

Hierarchy is Everything

Not all elements are equal

  • One of the biggest factors in making something look good has nothing to do with superficial styling at all. Visual hierrachy is much more important, it makes something feel designed.
  • Try to emphasize sedcondary and tertiary information and highlight the most importat elements. this will make the result more pleasing.

Size isn't everything

  • Using size to determine hierarchy is a mistake as it often leads to content being too large or too small. Try using weight or color before playing around with sizes
  • However, don't overcomplicate colors, a primary dark, a grey for secondaryt content and lighter gray for tertiary suffices. Additionally, normal font weight (400-500) as well as heavier (600-700) should be enough as well.

Don't use grey text on colored backgrounds

  • Using lighter gray to demphasize content is great but does not look good on colored backgrounds as it reduces the contrast.
  • In that case, making the test close to the background color is what gives the hierarchy.

Emphasize by de-emphasizing

  • Sometimes you may cross a component that does not really stand out with respect to inactive elements. Even emphasizing it does not do the work, so instead of that, just de-emphasize the rest (ex: navbars)

Labels are a last resort

Using labels to present data makes it difficult to present data with some sort of hierarchy as every piece falls into having the same emphasis.

This way interface will look more designed and be easier to use. Just use labels when data migh not be understandable on its own.

In this cases, data is what matters so labels should be secondary, reduce size, reduce contrast or use a lighter font.

Howver, when the UI would require user to look for the data, it is recomendable that such lable is emphasize

Separate Visual hierarchy from document Hierarchy

When creating a new web it is crucial to use the correct markup h1, h2, etc for different parts of the view. However, this document hierarchy should never be confused with visual hierarchy. Meaning that even though a page might have an h1 due to its purpose, that h1 does not necessarily need to be the biggest text in the page. Sometimes even hidding those sections might make sense as the document could talk by itself.

Balancing weight and contrast

What's the reson behin bold text feeling more emphasazed that regular text? Well, bold covers more area. This relation between surface area and hierarchy has more implications on other UI elements. This fact is important when working with icons, even though and icon is not the same as text, it feels more heavy as it covers more surface area, thus emphasizing the text it goes next to. There is no way to change the weight of an icon, but we can use contrast or opacity to demphasize it, thus catching less attention

Same can apply to borders, while for icons weight can be counter productive, wider borders can be a good solution for stablishing hierarchy in a document.

Semantics are secondary

When there are multiple actions a user can develop on a view, it is quite easy to fall into the trap of designing purely based on semantics . However, hierarchy should also be taken into account. when addresing these actions:

  • Primary actions should be obvious: High contrast baskcground color and solid
  • Secondary actions should be clear but not prominent. Outline styles or lower contrasts
  • Tertiary actions should be discoverable but not unobtrusive. Using link styling is usualy the best approach.

One special mention should go to destructive buttons. Despite of their meaning, these does not mean it should be big, red and bold. If destructive is not the main action on the page, it might be better to give it a secondary or tertiary treatment However, treat it as primary when it is the main action

Layout and spacing

Start with too much white space

It is easier to clean up a design by giving each elemnt enough room to breathe. White space when designing shoul be removed, not added. If it feels to crowded, add margin or padding. The problem with this approach is that we end up with something that does not look too bad. To solve it, give tons of blank space, then start removing. It might look like the recipe for too much white space but you will end up with just enough

Establish a spacing and sizing system

One should never nitpick when finding the perfect size for a UI element. Arbitrarily choosing a value will slow you down and end up with an ugly UI.