UX Prototyping:
Misc

Mick McQuaid

2024-04-09

Week TWELVE

Misc

• Empty states
• Heuristic Evaluation
• Affinity Mapping
• Teamwork

Empty States

The source is this URL https://www.nngroup.com/articles/empty-state-interface-design/

Do you see what I did there?

Common Empty States

• User has not designated favorites or opened files, so lists of favorited or recently viewed items are empty
• User has not configured alerts yet but app supports alerts
• App has workspaces or dashboards, but user hasn’t added content yet
• Search result lists when nothing is found, or commands that create empty output

What empty states can do

• Communicate system status
• Help users discover unused features
• Increase learnability of the app
• Provide direct pathways to starting tasks

System status unknown

System status displayed

System status update delayed

In this case, the system displays a misleading message while it searches for records, eventually switching to a display of found records.

Missed opportunity for learning

Message improves learnability

Another message improves learnability

Another missed opportunity

Providing a pathway

Conclusion

• Don’t default to totally empty states
• Provide help cues
• Provide direct pathways
• Use progress indicators
• Show system status if nothing else

Exercise: Design three empty state screens

• One showing system status
• One enhancing learnability
• One providing one or more direct pathways
• Use any existing website or app as the basis

Heuristic Evaluation

User research as described and as practiced

Promotional picture of Jakob Nielsen

Nielsen’s Heuristics

1. Visibility of system status
2. Match between system and the real world
3. User control and freedom
4. Consistency and standards
5. Error prevention
6. Recognition rather than recall
7. Flexibility and efficiency of use
8. Aesthetic and minimalist design
9. Help users recognize, diagnose, and recover from errors
10. Help and documentation

Nielsen developed two sets of these heuristics, Nielsen and Molich (1990) and Nielsen (1994). This is the second and enduring one, still popular after thirty years.

Affinity Mapping

I usually call this affinity diagramming but every online source I’ve found uses the terms interchangeably.

Good affinity diagrams start with good affinity notes

Good affinity notes happen in an interview

Getting there in the interview

• Transition to work focus
• Observe and discuss
• Be nosy
• Take notes (avoid using a laptop)
• Know what to take notes about!

What to take notes about

• The user’s role
• The user’s responsibilities
• The user’s communication types
• The user’s organization of physical space
• The user’s artifacts (get copies if possible)
• Breakdowns in the user’s work
• What works and what doesn’t

Interview activities

• Share design ideas stimulated by events
• Draw the physical space
• Take photos (if you get permission)

Wrap up

• Summarize what you learned, check your high-level understanding
• Ask about pet issues
• Give tips about system use (avoid doing so earlier)
• Thank the user and give a gift if possible
• Be sure you followed the tips in Holtzblatt, Wendell, and Wood (2005) in Tables 4-1 through 4-5!

Views of the CI interview

Interpret the interviews

Intro

• Today usually done via FigJam or Miro instead of on a wall with post-its
• Should happen 48 hours after the interviews (or sooner)
• You should NOT talk to your teammates (or anyone else) about the interviews before the interpretation session
• You should never do it alone
• Must be synchronous
• Usually takes all day

Interpretation session steps overview

1. Create affinity notes from your atomic observations
2. Add 500 affinity notes to the diagram
3. Organize the affinity notes by similarity
4. Add the bottom level of labels above the affinity notes
5. Add the temporary top level of labels and reorganize the bottom level of labels and affinity notes to fit them
6. Remove the temporary top level labels
7. Add the middle level of labels
8. Add the top level of labels

Note that there are three levels of affinity labels and one level of affinity notes. The affinity note copies one thing a participant said. It is the atom of the contextual inquiry universe. For example, a participant might say “I hate the menus because they are hard to navigate.” The affinity labels are top, middle, and bottom. For example, the bottom level label above the note just mentioned might be “challenges navigating the menus”, while a midle level label above that might be “menus” or “navigation”, depending on other affinity notes.

First steps

• Write affinity notes in the first person
• Use words that mean the same to everyone
• Let the meaning emerge from the groups instead of predefining
• Reorganize hard-to-label groups rather than wrestling with unsatisfying label wording

Bottom level of affinity labels

• Start when you can’t keep track of the affinity notes
• Give them design relevance
• Highlight distinctions rather than trying to bring groups together

Temporary top level of affinity labels

• Helps you move the affinity notes around into positions closer to their final positions
• Only half a dozen temporary top labels
• Remove them when this step is complete

Middle level of affinity labels

• Highlight highlevel work concepts
• Steps in work
• Communication strategies in work
• Tool use
• Organizational structure

Top level of affinity labels

• Describe the key issues relevant to the design
• Inform the behavior patterns that will be the basis for personas
• Any break in the chain from interview to key issues jeopardizes the persona milestone, coming up next

Example of the relationship between a top level label and those below it

Different views of the process

Summary

Affinity diagramming or mapping is similar to many other techniques. It’s a summarizing activity, originally developed to support contextual design or personas or scenarios, but eventually adapted to many other uses. The keys, in my view, are

1. Good affinity notes, written in the first person so that they speak with the voice of the user
2. Too many of them to make sense of directly
3. A rearranging and grouping and labeling process

Team Work

Sorry, I can’t show you an example of a successful team, which is what was asked for. Why do you suppose that is?

Instead, I will provide some guidelines for effective teamwork.

West (2012)

Michael West wrote the book, Effective Teamwork, from which this section was developed. We’ll cover two main topics, team development and team leadership.

Team Development

Team Development, Tuckman and Jensen (1977)

• Forming
• Storming
• Norming
• Performing
• Adjourning

Forming

• Anxiety is felt early on
• Members ask testing questions
• Members seek roles
• Members are guarded
• Goals must be clearly stated and agreed
• Optimism at this stage is a big predictor of outcomes

Storming

• Conflict emerges
• Authority of the leader is challenged
• Members question the value and validity of the task
• Hidden tensions surface
• Honesty and openness emerge
• Leader must gain shared commitment, build trust, define roles, and establish conflict resolution strategies

Norming

• Conflicts are resolved
• Positive cooperation emerges
• Work standards are established; plans are made
• Agreed rules or norms emerge
• Team members readily communicate
• Networks for mutual support emerge
• Leader allows team to take more responsibility

Performing

• Members begin to see successful outcomes
• Members settle into an effective team-working structure
• Leader can withdraw from daily involvement
• Systems of regular review are established

Adjourning

• Optional stage
• But all teams face members leaving, projects ending
• Teams may revert to earlier stages through turnover
• Teams may celebrate transitions

Leadership

Leadership tasks

• Create the conditions to enable the team to do its job
• Build and maintain the team as a performing unit
• Coach and support the team to success

Create the right conditions

• Fight for resources
• Clarify team boundaries, identify core members
• Teams should not exceed six to eight members

Build and maintain the team

• Ensure the right mix of skills and abilities
• Ensure adequate diversity
• Nurture good decision making, problem solving, conflict management
• Develop new ways to work together

Coach and support the team

• Directly interact with team members
• Help team members coordinate and work effectively
• Intervene with direction and support
• Be sensitive to team mood and quality of interaction and communication
• Encourage meetings or exchange of information
• Shape a supportive approach to suggestions
• Help team members develop skills and abilities

Elements of leading teams

• Leading: long term, focused on strategic direction
• Managing: medium term, focused on planning and clarification of objectives
• Coaching: day to day business of close interaction with team members

Leading

• Create a real team
• Communicate a compelling direction for the team’s work (people respond better to clear and challenging and consequential rather than do your best)
• Mold the team to enable it to perform effectively
• Win organizational support to enable the team’s success
• Time interventions appropriately (at the beginning, middle, or natural breaks)

Managing

• Set clear shared team objectives
• Clarify the roles of team members
• Develop individual roles
• Evaluate individual contributions
• Provide feedback on team performance (outcomes, viability, member growth, member engagement, innovation, inter-team relations)
• Review group processes, strategies, objectives

Coaching

• Listen
  • Active listening (effort)
  • Open listening (suspend judgment)
  • Drawing out (encouragement)
  • Reflective listening (summarize)
• Recognize and reveal feelings
• Give feedback
• Set goals

Tripwires

• Call it a team but manage individuals
• Exercising authority too much or too little
• Assembling a group
• Skimping on organizational support
• Assume team members already have all needed competencies

References

Holtzblatt, Karen, Jessamyn Burns Wendell, and Shelley Wood. 2005. Rapid Contextual Design: A How-to Guide to Key Techniques for User-Centered Design. San Francisco, CA: Morgan Kaufmann.

Nielsen, Jakob. 1994. “Enhancing the Explanatory Power of Usability Heuristics.” In Proceedings of the SIGCHI Conference on Human Factors in Computing Systems (CHI’94), 152–58. New York, NY, USA: Association for Computing Machinery.

Nielsen, Jakob, and Rolf Molich. 1990. “Improving a Human-Computer Dialogue.” Communications of the ACM 33 (3): 338–48.

Tuckman, Bruce W., and Mary Ann C. Jensen. 1977. “Stages of Small Group Development Revisited.” Group & Organizational Studies 2 (4): 419–27. https://doi.org/10.1177/105960117700200404.

West, Michael A. 2012. Effective Teamwork: Practical Lessons from Organizational Research. Third Edition. West Sussex, UK: Wiley.

END

Colophon

This slideshow was produced using quarto

Fonts are League Gothic and Lato