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

Session notes: Designing for Media platforms [Drupalcon 2012]

Presenters: Dave Leonard and Samantha Warren, Phase II Technology

What does it mean to design for media?

  • Designing for a site that is meant to reach a large audience with a daily content cycle
    • Newspapers
    • high-traffic blogs, etc.
  • What makes it different is the sheer amount of information
    • Photos
    • Videos
    • Lots of body copy
    • Organizing lots of information in a way that works for the user
    • ADVERTISING
  • Designing for a frequent publishing cycle
    • How do you design for content creators?

Case studies

  • Take Part
    • Digital media organization and cause services agency that provides content, products and services that inspire, empower, and ignite people to take daily action in making the world better.
    • Visual Design goals
      • Exhibit great storytelling
      • Compel users to take action, get involved in the community
      • Promote sharing: make sure the content doesn’t just live on that site, but belongs to the entire internet
    • UX Goals
      • Take action in the context of a story
      • Support the ebb and flow of topics
      • Make sure that editors have a good UX too!
        • Too many designers don’t take into account the process that editors have to deal with; focus too heavily on end users.
    • Visual Design process:
      • Conduct interviews with stakeholders about their brand and needs
      • Thematic Analysis: find adjectives
        • Engaging, action-oriented, personality
        • usable, present, depth, spacious
        • circulate, community, editorial, content focused
      • Use style tiles to help establish visual priorities
        • Offer one that’s “specifically what they’re looking for”
        • But also offer ideas that speak to the adjectives and themes you’re hearing.
    • UX Process
      • Content strategy
        • Types of content
        • Clasification/tagging
        • Embeddable content types: Put one node in the body of another node
        • Curation requirements: What are the requirements for analyzing and curating content? Are there expiration dates?
        • Curation capacity: What staff and other resources do you have to manage the requirements?
        • Campaigns of varying scale
      • Pair wireframing
        • Flush out misinterpretations early
          • How much fidelity do we really need?
          • Are we being over-specific?
        • Minimize revision cycles
          • Style tiles are done concurrently with wireframes
          • No conflict between UX and visual designer
        • Avoid over-designing
  • Washington Examiner
    • Regional newspaper that covers news, politics and sports in the DC area. The logo was created by William Randolph Hurst and it has a rich patriotic brand.
      • Visual Design goals
        • Feel modern
        • Stay true to history of the brand: wide and loyal readership
        • Promote ease of use: Readability is major; need content to shine through
      • UX Goals
        • Demonstrate breadth and depth of coverage
          • Section based
          • Cover a lot of local news for DC metro area, but also very respected nationally for political coverage
          • Set hierarchy; not all sections are the same
        • Promote top-quality curated content
          • Provided challenges in image handling
          • Challenges in creating hierarchy and ratios
        • Showcase the talent they have in house
          • Challenge: many sources of content coming into the system
            • Feeds
            • Direct to Drupal
            • Imports from AP
          • Need to define how authors are treated depending on where content is coming from
      • Visual Design Process
        • Adjectives:
          • Local, political, regional
          • Opinionated, scrappy, speedy, focused
          • ease of use, decluttered, visual balance, simplified,
          • polished, clean, fresh
          • Flexible, dynamic, Interactive
        • Had done a smaller site project beforehand; had some data on what the client liked and didn’t from the first site.
        • Work elements of the paper (print edition) within the website.
      • UX Design process
        • Sketch session: group brainstorming of UX concepts for a project
          • Got the entire team involved
          • Timeboxed to an hour
          • HAND-DRAWN sketches
          • Come up with ideas, no matter how “crazy”
          • Alleviates the “where do I start?” feeling
        • Wireframes were more high-fidelity because of the collaboration
          • heavily annotation of wireframes to make notes of interactivity, content, etc.
  • Common themes
    • Design a system, not individual pages
      • Clients think in terms of pages; it’s really easy for designers to think of things in pages as well
      • Because of the way Drupal (and other content management systems) handles media, content, etc. you have to think in systems rather than individual pages
      • Create style guides for clients to use and adapt as the site grows
    • Dealing with the author experience
      • Authors can be Drupal users, or they could be organizations
      • Have to consider how different types of authors will need to be treated or highlighted
    • Cross promotion of content is a common theme when designing for media
      • Want multiple page views
      • Make sure people can see additional or related content
      • Helps users find related info; helps the organization get more views on their content
      • How to distinguish between “articles” and “actions” — what’s the different treatment between requests for action and related articles?
    • Lifecycle of Topic
      • How to build a set of tools that lets editors evolve the content and its treatment/important on their own without needing extra developers
    • Commenting
      • Drupal core commenting vs. Disqus or FB comments
      • How to make things visually consistent with third-party integrations?
    • Advertising
      • Designers often have a fear of advertising; it “ruins the layout”
      • How to make it part of the design, and find subtle ways to make it less obtrusive?
      • You can’t get around the need for advertising; it’s the bread and butter of the media industry
      • part of our work as designers is solving problems, and this is part of it.

Session Notes, Sessions 7–9: Agile UX Summit, 2/25/12

Anders Ramsay: Learning to play UX Rugby

  • Feeding the beast
    • Whole team of devs and they’re building shit faster than I can design it
  • Half-baked UX
    • PO’s under pressure to deliver the next release and signing off on crap
  • Sprint-tunnel vision
    • Yes, we delivered all the features we were supposed to deliver this sprint, but the design is an incoherent mess!
  • Why the dysfunction?
    • Playing the old waterfall game on an Agile playing field without knowing it.
    • Lacking the thinking tools to understand how the Agile game is played.
      • Scrum is not an acronym; it’s related to rugby.
      • “stop running the relay race, and take up rugby.”
  • Relay race
    • Team members run alone
    • Collaboration isn’t built into the game; the baton is handed to the next person
  • Rugby game
    • Intensive and continuous collaboration is core to the game
    • Reach the goal line again and again to win the game
  • Rugby in design
    • Team communication
      • Workshops, not meetings
      • Intensive passing game across roles/perspectives
      • Iterating towards shared understanding
      • Move away towards “debugging,” more towards a collaboration-centered design process
    • Collaboration-centered design
      • Shift towards facilitation as a core skill set
      • Cardstorming
      • Collaborative Chartering
      • Dot-voting
      • Story mapping
      • Card sorting
    • Ideation clearinghouse
      • Capturing the imagined final product.
      • Complete in an hour or less
      • There is a tremendous cost to not knowing what’s in the head of your project’s stakeholders (i.e. cutting off the project because you didn’t “get the vision”)
      • Step 1: Set focus/boundaries for the workshop
      • Step 2: Do a warm up; introduce people to the raw materials
        • 4-5 minute time window
        • Write every feature you expect on a separate sticky
        • Becomes a feature palette for sketching
      • Step 3: Sketching timebox
        • Give 5 minutes
        • Ensure safety; it’s okay if you “can’t draw”
        • Everyone in the room sketches SOMETHING
        • Sketch individually
        • No rules — someone wants to write text, they can
        • Clarify that this is research, NOT design.
      • Step 4: Critique
        • 2-min round-robin where people explain the vision/design
        • Take careful notes, attach to respective sketches
        • Look for and work to resolve differences in vision among stakeholders
    • Designing with workshops
      • Learn, apply and recombine workshop patterns
      • Cardstorming + dot-voting + sketching, etc.
    • Pairing
      • an intensive one-on-one passing game
      • Continuous problem debugging and knowledge distribution
      • One person “drives” and the other “navigates”
      • Use to debug and fix code in a continuous and collaborative way.
      • Change partners each day
    • Cross-functional pairing
      • Designing in multiple dimensions at the same time
      • Better collaboration means less/lighter documentation
      • Move from whiteboarding/sketches straight to building things together.
      • Developers can help with the transition from talking about building to actually building
      • Each medium/perspective informs the other
      • Move from wireframes to building the structure to HTML/CSS in a simultaneous process.

Todd Zaki Warfel: The Design Studio Method

  • Borne out of architecture and Industrial design
  • Three phases (charette):
    • Create: generate and prototype the concept
    • Pitch: presenting the design concept
    • Critique: talking about the design concept
  • Approach: 6.8.5
  • Tools:
    • Butcher paper
    • Sharpies (rougher feel; it’s about generating ideas)
    • Personas
    • Design challenge/scenarios
    • Templates, e.g. 6-up or 1-up grids
    • STOPWATCH
  • Teams should be CROSS-FUNCTIONAL. Represent 3 viewpoints:
    • Design side
    • Business side
    • Development side
  • Each team gets a different persona, and ONLY focuses on their persona for the duration of the studio
  • Design studio kicks off the design process
  • Step 1: Create
    • Create 6-8 concept sketches individually, within 5 minutes
    • Give templates with 6-8 blocks (like a storyboard) with grids and space for notes
    • Either storyboard a flow, or use the time to sketch multiple approaches to the same screen
    • Don’t forget a warmup session
    • Use paper and pencil to get people out of their element/comfort zone
    • Don’t worry about details; just get the elements down
    • Goal: get just enough of the concept on the page to be able to pitch your idea to the team
    • Don’t create more than you can pitch in 3 minutes
  • Step 2: Pitch
    • Put all sketches on the wall with personas, “inspiration gallery”
    • Everyone gets 3 minutes to pitch their idea:
      • What did you intend to achieve?
      • How does your idea achieve that goal?
  • Step 3: Critique
    • While someone’s pitching their concept, nobody is allowed to speak.
    • Once the 3 minutes is over, team gets 2 minutes to critique the concepts.
    • This is NOT feedback, i.e. “I don’t like this” or “I like this.”
    • Critique based on the goals for the design: where it achieved or failed to achieve the goals.
      • 2-3 ways it achieves the goals, EVEN IF YOU HATE IT (green markers)
      • 1-2 ways it can be improved upon, EVEN IF YOU LOVE IT (red markers)
  • Step 4: take feedback and iterate on designs
    • Stealing is highly encouraged; if another team does something you love, steal it and make it better.
  • Benefits
    • Generate two weeks of work in less than six hours (420 different design concepts)
    • Instant buy-in from team members: since team members help create the designs, they’re already buying into the concepts
    • Get team members to own and invest in the concepts
    • Engineers said their estimates on time were 50% more accurate
    • Having five minutes as a rule means you don’t have time to worry about it; just execute
    • Everyone gets to vet concepts as they go: it’s not as good as usability testing, but the benefit is that only the strongest concepts survive

Jonathan Berger, Code Literacy for Lean Teams

  • Coding as literacy
    • gets rid of the binary nature of “you can code or you can’t”
    • If you work in technology, the medium is power
    • “I can get this code to work or not” can be frustrating to those just learning
  • LITERACY DOES NOT EQUAL FLUENCY
    • Just because you can code doesn’t mean you’ll be good at it
    • Getting technical doesn’t have to be a full time commitment
    • Many resources available (books, sites, tutorials, etc.) are geared towards people who want to be full timers
  • More and more shops won’t hire designers who can’t code.
  • How does code literacy help lean teams?
    • More literacy leads to more sustainable projects and more successful outcomes
    • Fine details are important, but often get shoved to the wayside by devs moving on quickly to the next feature
    • There’s a whole class of things that are easier/less time consuming to do than to explain
    • Being able to fix details yourself saves the developers time,
    • Gives team more hands on deck, fewer bottlenecks
    • Builds camaraderie
  • How does it hurt?
    • Time/cost in learning curve
    • Potential for overstepping bounds (humility is important)
    • Harder to look at things with an “innocent” eye (i.e. without thinking about how it can be made)
    • Tunnel vision in devs can skew priorities towards problems that are “easy” to fix
    • DON’T LET CODE OVERSHADOW DESIGN
  • Ways to become literate
    • Use in browser mockups (HTML/CSS/JQuery)
    • Use Inspector (Chrome) or Firebug (Firefox) to inspect and change elements, then import changes into code mockups
    • Align product/development/design
    • Set up a local dev environment (e.g. MAMP, Rails)
    • Get started with Git
      • Designers can contribute small changes, e.g. copy or CSS, and push to production without interrupting the developers’ workflow
      • You can make the fixes that matter to you but aren’t crucial to the developers
      • Watch out for breaking tests (e.g. when copy is changed)
    • Learn JQuery & the DOM
      • Make better mockups—directly in the browser
      • Make more changes for the team
    • Learn the language your team is developing in—PHP, Rails, Drupal, etc.

Session Notes, Sessions 4–6: Agile UX Summit, 2/25/12

Tomer Sharon: Getting out of the (Agile) Building

  • How do you do UX Research in an Agile environment?
    • OLD: Fast Usability testing rounds
  • Tips for Agile Usability testing
    • Make it relevant to what the team is doing NOW.
    • It should be a small thing, not a BIG thing, and do it 3-4 times per sprint (i.e. once a week)
    • Recruit participants in advance.
    • Plan really fast.
    • One-page usability test plan on Smashing Mag: http://uxdesign.smashingmagazine.com/2012/01/26/ux-research-plan-stakeholders-love/
    • Make it a team thing. If nobody was there to hear about it, it didn’t happen.
    • No reports. Try a spreadsheet with observations, and just color or code where observations repeat.
  • “Getting out of the Building”
    • Getting an understanding of what the users actually need;
    • What you find isn’t necessarily going to relate to what the team is doing right now.
    • Bring users in in some way.
    • “Virtual Visit”
      • schedule phone call with potential or existing user of product.
      • No specific goal other than having engineers, project managers, etc. to “see” a user.
      • Use screen sharing software to watch customers using the product.
      • Get the product team talking to the user, asking the questions.
      • If the same problem is noted multiple times, it may turn into a product change/sprint.
    • “Field Fridays”
      • Take some engineers to visit a client for 60-90 minutes
    • “Collaging”
      • Ask participants to use collage to express their feelings about a topic.
      • Collect images around the topic.
      • Gives people a chance to express themselves more easily around the topic; uncover user needs in a less direct way.
  • Getting buy-in for user research
    • Become one with the team. There is ONE team who works on creating something. If you understand that, you can do these things.
    • If we want to get buy-in, our route to work should include stopping and talking with people within the organization
      • Identify what people care about.
      • Identify new research questions.
    • It’s OUR research: Getting buy-in for UX Research projects.
    • Elsevierdirect.com Code MKFLYER for 20% discount.

Andres Glusman: Managing your Malkovich Bias

  • Building something isn’t the problem; getting people to *use* what you build is.
  • On track to do 600-800 tests a year
    • Test 2-3 days a week
    • Setup tests prior to knowing what will be tested
    • Objectives are discovered via conversations, etc.
    • Recruit participants from community and through recruiter (compensate for their time)
    • Use GoToMeeting to broadcast sessions to developers
    • Record sessions using Silverback, JUST IN CASE you want to view it again
    • Follow up each session with discussion and notes/video
  • Everyone suffers from Malkovich bias: the tendency to believe that everyone uses technology like you do.
  • Watching people use the stuff you build helps solve the Malkovich bias
  • Experiment then double down;
    • First question: what are people going to respond to?
    • Test the most simple concepts you possibly can.
    • Use A/B testing to test experiments.
    • Know that your most likely outcome is failure; look for the points of heat (where people are staying)
  • Look at short and long-term experiments
    • Short term: trying out new messaging or graphics
    • Long term: creating new service areas, profiles, etc.
  • Lessons learned:
    • Give team direct access to customers
    • Look for the boulders in the road; be comfortable with error
    • Substitute frequency for precision; if one screws up, there’s another right behind it
    • Have discussions
    • Launch and Learn
    • Accept that failure is the most likely outcome
    • Experiment, then double down. Once you’ve found something that works, start working on implementation.
  • Other lessons learned:
    • Don’t buy your coworkers books and expect them to read them
    • Don’t try to sell the process; people don’t want to buy the process, they buy the results
    • JUST START DOING IT and let the results show you how successful it is.
    • Snuggle up to failure
      • We are more often wrong than we are right.
      • What would you do if you assumed you would fail?
      • Go after what will cause you to fail as often (and as FAST) as you possibly can.
      • The longer you put off getting people in front of your work, the longer you can live under the delusion that you won’t fail.

Lane Halley: Quick, Visual, Collaborative and Continuous

  • The old days of waterfall: PLAN-BUILD-TEST-SHIP
    • Based on shipping physical discs that the user would have to install.
  • Then, we started having:
    • Web services
    • Web apps
    • Web analytics
    • Mobile devices
    • “Permanent beta”
  • Things don’t have to be built in one big chunk; you can iterate and learn as you go.
  • Many UX processes are still stuck in the Waterfall “over the wall” mode
  • Changing role of design
    • Design as team responsibility, not a single designer’s responsibility
    • Cross-functional pairing
    • Designer as facilitator, not a lone wolf
    • Team as product owner
    • Bringing things into the entire process: smaller, lighter, more continuous
  • UX finally has a “seat at the table;” but the processes we’re using are causing backlog and distress
  • How to make it “leaner?”
  • Team discussions: who do we want to talk to, and what do we want to learn?
    • Create an interview guide with themes
      • Intro:
      • About you:
      • Collect a story about what you want to talk about
      • What devices do you own, and what do you use it for?
  • Provisional personas
    • Defines user hypothesis
    • Shared visual artifact
    • Evolves over time
  • Get “permission” to interview users: start by asking the team who the users are. What are their pain points? How do we delight them? If the team can’t answer, that’s a step towards getting permission
  • Interviews can give you an insight into personas (i.e. USERS) you didn’t know existed.
  • Team Interviewing
    • Pair interviewing
    • Multiple note-takers
    • Group synthesis
    • Visual radiators, sketchboards
  • Continuous customer engagement
    • Five users every Friday
    • “Talk to us” or “give us feedback” button on the website
    • Just-in-time recruiters
    • The point isn’t how many people you talk to; it’s that you’re doing it regularly
    • Schedule time in advance, EVEN IF YOU DON’T KNOW what you’re going to talk about
  • Use one session for multiple activities
    • Listen, gather context
    • use collaborative activities
    • get product or prototype feedback
  • Collaborative design sessions
    • Put everything on the board
      • “You can only have 5; which ones?” then prioritize.
      • “You can have 5 more; which ones?” etc.
    • Collect everything and start talking about priorities, hierarchy, etc.