UsabilityBlog

This summer I’m teaching two courses for the Kent State UX masters program – the introductory class User Experience Principles & Concepts, and the first of two user research classes. The intro class is a level-setting course, as we admit people with a broad range of UX and non-UX related job experience.

The Researching User Experience (RUX) 1 class gives students the opportunity to learn how user research techniques are used to help organizations accomplish their strategic business goals. Sometimes this means identifying how people organize their overall workflow and how the organization’s current solution is incorporated into peoples’ workflow. Other times user research is employed to discover opportunities, i.e., “jobs-to-be-done” that people or a business would pay to have a solution for. Whatever the specific research goal, you learn a hell of a lot by watching people work or play.

The key for me is that user research is one of the more important tools that a product manager / product owner can deploy to better understand both customers and customer value. So when UX’ers are functioning as user researchers, it’s incumbent on us to identify the underlying drivers of users’ behavior. And we best serve the organizations we conduct research for when we also understand the product owner’s goals and the organization’s objectives.

Getting students to recognize that user research is not primarily about identifying a product’s usability issues has been my biggest challenge when teaching RUX 1. It requires me to help students focus their attention on big-picture workflow and overall process pain points. It’s much easier to identify task-level usability problems in a single application, because they’re more obvious than process- and workflow-related pain points and inefficiencies. It’s harder to go deep and identify root causes.

It’s a challenge, yes. But it’s fun and gratifying when I get to watch students learn how to take a broader approach to user research and develop their opportunity-spotting skills.

I’m recommitting to journaling my experience as a working UX practitioner. I’m not sure exactly why I stopped. Between 2006 and the mid-teens I had a good run with UsabilityBlog. Somewhere along the way I probably got too task-loaded, and I just tailed off.

Here’s the thing, and I doubt it’s just me that has this feeling: it’s hard to start blogging again when you expect that every piece you produce should be worthy of a keynote speaking slot. So join me as I lower both your expectations and mine. And read on for a peek into my ongoing series I’m going to call “UX Working & Learning.”

What I’m Working On This Week

I’ve been working with a Cleveland-based software company for a few months now. This past winter I designed views and workflows for a new set of features they’re rolling out in the beginning of Q3. For the past few weeks I’m helping them redesign information architecture and navigation so their suite of products employs a consistent navigation scheme, structure, and interaction style. Like many enterprise software products, they haven’t had much in the way of a design system or any product line-wide design standards. So their five or so main products, which are increasingly converging to meet target users’ needs, are wildly inconsistent in some areas. The principle designer (actually, only designer) and I were tasked with bringing the products’ navigation and IA together, while not stranding (read: pissing off) the installed user base.

It’s a challenge, but I’ve done this type of thing before. I learned some important lessons when I led the redesign effort at Peachtree Accounting over 10 years ago. My key takeaways then were:

  • You can add a second navigation scheme and system to an existing, inefficient one. But you need to make sure they don’t interfere with each other. You have to ensure you’re not pulling the rug out from the feet of long-time users who are resistant to change, while also providing a more sensible and usable scheme and system to newer and future users who haven’t overlearned the old ways of doing things.
  • Don’t put all your redesign eggs in one basket. Design several competing alternate versions, and test them. Let iterative usability testing be the “design Darwinism” mechanism of identifying the best IA and navigation.
  • Position the design and testing as iteration zero so you can defend against “BDUF” (big design up front) accusations. Agile works great when most of the design direction is known. But UX’ers need more than your standard two weeks for a ground-up redesign or product line convergence.

What I’m Learning This Week

Sometimes I learn a soft skill technique, other times I’m heads-down in a new tool or application. This week I’m learning how to use the prototyping tool UXPin. The lead designer uses it and would like to be able to collaborate on the IA and navigation concepts. So I’m off to watch a few more video tutorials.

Here’s something for UX’ers and people who hire and manage UX’ers: I’ve updated the UX Kit for 2019.

I originally created this document as a guide for product management and development teams that wanted to incorporate user experience research and design practices into their processes, but weren’t sure how to do it.

Over the past 10 or so years it’s grown to cover new areas, including:

  • UX strategy and content specialist roles
  • How UX contributors function in agile software development environments

The most recent update includes minor corrections, updated salary information, and the addition of other publicly-available UX resources.

The UX Kit is available under a Creative Commons Attribution-Share Alike 4.0 International License. Support open culture! You can learn more about this license here: http://creativecommons.org/licenses/by-sa/4.0/

Get the UX Kit

Here’s another resource that I wanted to share with the UX community: I’ve created a template and example for a daily research recap.

I created this template as a way to quickly communicate research results to team members and stakeholders on a daily basis.

One of the more important lessons I’ve learned during my UX career is that it’s vital for UX practitioners to keep team members and stakeholders informed and aligned. Another lesson I’ve learned is speed of communication is critical in this brave new world of agile/lean product ideation, design, and development.

As the people who glean insights from users and customers, we should strive to communicate our results quickly. At the same time, we need to be clear that daily recaps should not take the place of considered analysis.

This template is intended to communicate “here’s what we’re seeing after n user sessions” as opposed to “here’s the results, now go write stories and code to this information.” When you use it, you should ensure that this understanding is shared.

It’s set up as an email, but you could just as easily drop it into Slack, Jira Agile, etc.

The template is here: https://docs.google.com/document/d/1VqgNCnlwG89WVjI7wjK3SD_6AMhKGMjUhpBW6zkdYjs/edit

Like the UX project planner, I’ve licensed it under the Creative Commons Attribution-ShareAlike 4.0 International License. As a Creative Commons work, it’s yours to use, modify, adapt, etc. Please share it, improve it, and enjoy!

UX’ers, I made a thing for you: check out version 1.0 of an open source UX project planner / tracker template I’ve been working on for a few months.

I created it as a tool to document a user experience project in an efficient and collaborative manner, as well as give clients/stakeholders visibility and accessibility into various aspects of the project.

We all know the importance of setting appropriate stakeholder expectations, attaining alignment among contributors and stakeholders, and ensuring that your project schedule, process and data are accessible by all involved.

The planner / tracker is my solution to these challenges. It’s not perfect, but it functions well as a “one place for everything” resource. You can use it to frame up the project, identify contributors and approvers, lay out the schedule, design and document your recruiting and session protocols, record your project meeting notes, and even enter your raw notes from observations or interview sessions.

Best of all IMO, your client or stakeholder can comment inline on whatever section you need reviewed. Because I’ve utilized document headings and subheadings, you can do neat things like tell the client (via email, Slack, semaphore, etc.) something like:

Hi all, I’ve drafted the recruit request and put together an initial schedule of session times and dates.

Could you please review these and provide comments and/or approvals?

The recruit request is here:

http://docs.google.com/document/foo#heading=recruitheadingID

And the participant schedule is here:

http://docs.google.com/document/foo#heading=scheduleheadingID

Some other thoughts:

  • Leave the outline sidebar on. It’s incredibly useful for jumping between sections.
  • I’d like to add a section for initial data synthesis, and possibly analysis. I just figured getting this out in the world was more important than making it perfect.
  • As you read it, you’ll see references to other tools that I employ for project work, such as SlackGoogle DriveMoqups, etc. Obviously, use what works for you. But I highly recommend including direct links to any external resources in the project planner itself.

I’ve set permissions for this as “viewable, copyable and downloadable by all.” So you should be able to just save a copy to your own G Drive, or download it to use in Word. Fair warning, I make no claims regarding formatting fidelity outside of Google Docs.

I’ve licensed it under the Creative Commons Attribution-ShareAlike 4.0 International License. As a Creative Commons work, it’s yours to use, modify, adapt, etc. Please share it, improve it, and enjoy!

Here’s a short URL for the planner / tracker: http://bit.ly/uxprojecttemplate