Skip to content

Collection of notes and examples of good UI/UX practices

Notifications You must be signed in to change notification settings

gubisim/design-notes

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

51 Commits
 
 
 
 
 
 

Repository files navigation

UI/UX Notes

A place for me to dump all my things I am learning about UI/UX

UX

Forms

  • Avoid multi-column forms

    • If a form has horizontally adjacent fields there are so many varying ways that the form can be interpreted. There is not a single understood way of completing the form and this can even cause users to lose confidence on whether all of the inputs need to be filled.

    Multi column form pitfalls

    • Single column forms have a very established and very clear path to completion that is well understood by users.

    Single column form layout

  • Break long forms into smaller pieces

    • When designing forms general rule of thumb is that the less fields the better. Less effort on the user or percieved less effort results in higher completion rate.
    • Displaying 5-7 inputs in a group is a good goal to aim for and is considered common practice
    • A few different ideas for breaking up forms
      • Grouping forms into logical groupings.

        • Breaking forms into smaller, logical groupings can not only increase user completion (by making a seemingly endless form feel more doable), but also give insight to the user as to why these fields are necessary.

        Group inputs logically

      • Stepper (a more modern approach to a wizard)

        • This can make large forms feel more managable by breaking a large form into smaller, more managable tasks while giving them visual feedback on where they are at and what steps still need to be completed.
        • Studies show that providing the total amount of steps up front to the user increases form completion significantly.

        Form Stepper

  • Placeholders

    • Avoid using placeholders as description for the input

      Placeholder as description

      • Using placeholders as description is bad practice due to losing your description when you input anything. If the the user wants to refer back to the description the only path is to clear out the input and start over.
      • Instead place the description below the input, making sure to keep visual hierarchy. This allows the user to refer back to the description at any given time during the form completion.
    • Avoid using placeholders as the input label

      Placeholder as label

      • When using placeholder as label you lose the input label and can easily forget what the expected input was supposed to be. In order to get the label back you have to clear out the input data. This causes problems not only during filling out the form but reviewing your input, the user is either forced to guess what the input was asking for based on context clues from the data or to clear out the input data.
      • One way this can be okay if you are using floating placeholders (placeholder moves to label when there is input). IMO floating labels do not really get you any benefit because the real estate that you were initialy saving by using the placeholder as the label is taken away when it floats up. In this sense floating labels are purely a stylistic choice.

      Floating Label Input

  • Labels

    • Put labels above input.

      Label visual fixations

      • Google’s UX researchers found that aligning labels above fields on the left-hand side increased form completion time. This is because it requires fewer ‘visual fixations’.
      • By placing the label above the input you can look at both the label and input without any additional effort.
    • Have proper spacing between input and label

      Label positioning

      • Having a label that is too close to an unrelated input or not close enough to the intended input can cause confusion on which input that it is intended for. Doing this breaks the a common UX law called the Law of Proximity (Objects that are near, or proximate to each other, tend to be grouped together.)
  • Input should be sized according to the size of the expected input

    Input size

    • Having the input larger than the expected input makes users second guess what they are expected to input and lead to lower form completetion rates.
  • Action Buttons

    • Avoid generic text on buttons

      • Using words like "Submit" instead of "Create Account" or "Place Order" can lead to less confidence in the user that clicking the button is actually performing the task that they are intending to perform.

      Descriptive button text

    • 99% of the time it is the wrong choice to include reset buttons.

    • Primary vs Secondary actions

      Primary vs Secondary actions

      • When there is no visual difference between the primary action and the secondary action this can both lead to confusion and increase rate of failure in a form. Secondary actions should draw less visual attention, this will reduce liklihood of accidental error and gives a more clear path to completetion.
  • Validation

    • Validation is all over the place with implementation but the Reward early, punish late paradigm I tend to agree with the most
    • Reward early, punish late "Inline Validation in Forms: Designing the Experience"
      • If field is empty or valid only show validations on leaving the input.
      • If field input was left at an invalid state and returned to, validate during input.
      • Implementation described in the article above looks like
        • The validation library must keep track of the dirty fields.
        • If the field was in a valid state, perform the validation on the blur event
        • If the field was in an invalid state, perform the validation when the field value is changed (using the combination of onchange, onblur and onkeypress events)
        • When the field goes from the invalid to valid state, treat it like a valid field
  • Dynamic Forms

  • Sign up Form

    • Avoid second input for confirming password.
      • Asking for this a second time leads to lower user conversion and frustration.
      • Instead you should have a single input for password with a "Show Password" option for them to verify that they typed the password correctly.

Type

  • Font size
    • Body text 16px you can not go wrong with
      • usually header should be around 2.5x the size of the body text (40px) in this case
      • that should be 1rem vs 2.5rem
  • Prefer smaller line height on larger text, increase line height on paragraphs to make more legible

UI

  • Do not use high contrast borders they draw unecessary attention from your eyes
    • using the law of proximity can aleviate a lot of the problems that borders are trying to solve.
    • using borders can be fine in some cases when they are low contrast
  • Religious Debates
    • People think everyone on the web thinks in the way that they do, if I dont like it nobody will
    • You can sit and argue design decisions but the only thing that will really help is user testing
  • The landing page should generally consist of a Hero Section which are made up of:
    • Headline
    • Sub-headline (optional)
    • Call to action
    • Usually some art or and illustration

Mobile Design

About

Collection of notes and examples of good UI/UX practices

Topics

Resources

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published