锁眼里看世界

天下5912

GET IN TOUCH

你好!

UX basic pattern

notes taken from 《strategic writing for UX》chapter 4 —classic UX pattern

Titles: Provide immediate clarity of context and action to be taken

  1. Brand name
  2. Content name —screen based on content
  3. Ambiguous task —screen with multiple potential actions (eg: dashboard …)
  4. Single task —verb phrase as instructions to reinforce the correct action

Buttons, Links, and other commands: allow the person to advance toward or commit to action

  1. Buttons
    1. one or two words long
    2. word that person says
    3. use icons
  2. buttons that directs action need to match title that directs action

Descriptions: help people more forward in the experience knowing what to expect, establish the brand, and reduce liability

  1. three lines or fewer for users to linger on
  2. 3 to 6 words wide (40 characters wide, scannable chunks)
  3. used with titles, buttons, or whole experiences

Empty States: to set expectation and build excitement while indicating that the empty state is intentional

  1. use text like “to do X, do Y” (eg: To access your membership, sign in)

Labels: minimize the effort required to understand the experience

  1. related to passive screen elements like icons or sections and limited to that local context

Controls: inform people of the extent and state of possible customizations

  1. eg: toggle switches / checkbox
  2. composed of two text elemnts
    1. name
    2. state

Text Input Fields: help people enter accurate information

  1. label or hint text option
    1. name of the info to be entered
    2. eg of the info to be entered
    3. verb-first instructions about entering info
    4. guidance for how the person can be successful

Transitional Text: confirm that an action is happening (an experience “hangs”)

  1. not requiring any additional action or taps from users
  2. use verb like uploading or sending… (to build confidence that it is working on …)

Confirmation Messages: reassure the person that the progress or results they expect are complete

  1. verb pairs: sending/sent, removing/removed, deleting/deleted, posting/posted (use past tense for confirmation)

Notifications: inform or remind a person to engage with the experience

  1. get on
    1. lock screen
    2. notification center
    3. banner
  2. include first action person needs to take
  3. provide value and timeliness at a glance
  4. begin with verb
  5. convey information necessary to create success

Errors: help people get where they want to go and, if necessary, indicate that there’s a problem getting there the way they intended.

  1. verb-first, brief instructions
  2. errors types
    1. inline
    2. detour
    3. blocking
  3. ⭐️ “invalid” has been used in US to describe people with disabilities and is viewed as an ableist word

Similarities And Differences Between UX Writers and Programmers

I’ve found it helpful to explain UX writing in terms of programming. Software engineers write in one or more software languages. There are specific grammars and techniques to use in each language to get the best results from the hardware, firmware, and the services on which the software will depend. Those languages are compiled into programs to push the electrons, at the right moments, to the screens and speakers that people will use.

UX writers write in one or more natural languages. There are specific grammars and techniques to use in each language to obtain the best results from the people and their content. Those languages are compiled by each human as they connect with those screens or speakers to transform those sights and sounds into the right synapses, firing at the right moments to create a useful, entertaining, or necessary part of their lives.

Therefore, both software engineers and UX writers use the grammars and commands specific to their language to meet the goal of the organization and the people who use the experience. Both groups work in a process of design, writing, cycles of review and testing, and publishing. Both groups need to be flexible to adjust to idiosyncrasies in the languages, the compilers, the architectures, and contexts the experience lives in. If our teams can work with software engineers, our teams can work with UX writers.