Session Notes: Tapping into the power of user narratives [Drupalcon 2012]

Presenter: Michael Keara, MyPlanet

What is a user interface systems architect?

  • equal parts listener and software developer
  • Listens to users and finds pain points
  • Understands software and how to build the technology
  • Focus: how to bridge the gap between the two.

Two doors:

  • The user happy place, where they understand the user interface they’re dealing with
  • The development environment, where people need to understand how to make the system work
  • Opening both doors opens new conversations, and leads to new insight

Three UX Fundamentals

  • Usability is a lack of suffering on the part of the user
  • Usage context: Functionality has no meaning outside of a usage context
  • Primary questions:
    • Who is the user?
    • What are their tasks?
    • These are “simple” questions, but very difficult to answer.

Case study: a registration system for music exams in US and Canada

  • Two websites, two separate usage context
  • Examinations are key to their business model
    • Registration must be easy
    • Multiple types of users involved in the system
  • Design and testing
    • Started with “pilot” for US school
    • Prototyped the solution in a rich HTML prototype, then created a testable site
    • In user testing, discovered:
      • Structural issues: how to improve the location and function of key components
      • “Language” issues: issues around the language being used to navigate around

User narratives:

  • Role-oriented UX design
    • Is about supplying the right tools at the right time
    • Don’t throw all the tools the user will ever need into one space
    • Provides a way to trace the path from end user to the engineer
    • Roles = a set of tasks
    • Tasks require specific elements on the screen to facilitate completion
    • Has an impact on:
      • Layoute
      • Information Architecture
      • Data Retrieval
      • Data Structure
    • Connecting the dots
      • Handle idioms/terminology used
        • Different cultures have different terms they’re used to
      • Handle roles (mindsets and usage contexts)
        • Student
        • Parent
        • Teacher
      • Applications and tools try to mimic mindsets, but it doesn’t always work out
      • Role-oriented designs handle mindsets comfortably
  • idioms (language beyond “language”)
    • Unfamiliar terms don’t fit
    • Generic terms have rough edges; don’t resonate
    • Familiar terms are comfortable; help achieve “invisibility.”
  • Real-life narratives
    • Life is a sequence of roles, and those roles need tools
      • I’m a cook at breakfast {stove, toaster}
      • I’m a commuter {train, car}
      • I’m an emailer {computer or smartphone, fingers for typing}
      • I’m a [insert role here]
  • How words get to the screen
    • String: set of words that arrives on the screen
    • We all have words that resonate with us in terms of different roles, tasks, mindsets
    • Thoughts come in clusters; so do the words that describe those thoughts
    • Drupal thinks of strings individually and not in clusters
  • Drupal excludes UX designers
    • Drupal defines “roles” differently (as a set of permissions that’s fixed depending on roles)
    • Doesn’t support the ability to express things idiomatically
  • Organization of words for UX
    • Strings have two lives:
      • The ones the user can’t see (internal code)
      • External ‘user’ strings (human names, what users see)
      • Code strings should never change unless there’s some kind of functional change intended by the developer
      • User strings should adapt to users
    • All of the strings (user, internal code) exist in code!
    • The t() function handles user-facing language
      • You can find them and change them, but not to role or idiom-based terms
      • Translation (from English to German, etc.) is there, but not when thinking in terms of different idioms within the same language
  • Inclusive alternative approach
    • Have to go beyond the t() function to fix this issue
    • Extract the user-facing strings from the code using semantic keys
      • ‘name’=>$sm->t(‘LABEL_BLOG’)
      • $_string_array = array ( ‘LABEL_BLOG’) => “Blog entry”
      • Role oriented key: $sm->t(‘LABEL_BLOG__’.$role)
      • $_string_array = array ( ‘LABEL_BLOG’) => “Blog entry” LABEL_BLOG__STUDENT’ => “student’s blog entry”
    • Do this through the user narratives module
      • It’s about organizing strings
      • Takes a custom “adapter” module (uses form API) and routes it through the user narratives module into a different place that the uX designer can evaluate and change to accommodate new needs/mindsets

Leave a Reply

Your email address will not be published. Required fields are marked *

*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>