UX Triage; What I have learned performing UX Audits around the globe.

After working alongside talented developers in Mumbai, Kiev, Moscow, Bucharest, New York, LA, Nashville, Vegas, & Chattanooga one thing about my existing UX processes became clear.

User Experience needs a better user experience.

The devs I have worked with across continents, cultures, teams and projects, were all familiar with different processes. They would get deliverables of every shape and size. Pretty wireframes, pixel perfect psd’s, or some overly complicated Omnigraffle files.

When your team needs to pivot, the UX’er and their “2 weeks ahead” — *Poof* all the effort could be gone. In one case, when working with 60 mumbai developers, if a pivot was made mid-sprint, and the UX’er couldn’t deliver all the needed documentation in < 12hrs… we would lose a combined total of 540hrs of development. All while the devs waited for new direction.

What developers want is information.

How can you deliver valid information to developers in a timely fashion?

  1. Be quite simple
    (strip out subjective & repetitive content)
  2. Be even faster than it is simple
    (work hrs ahead; not wks or sprints)
  3. Require a low cognitive load
    (use very few element types)
  4. Clarity on the concept, it’s use, behavior and triggers
    (include the where, why, when, and how)

The view of a new horizon

After using UX Triage for years, I am taking time to write it out. My hope is that someone finds it useful.

That said, UX Triage is a progression from many ideas. I’ll use terms from those ideas to make this an easy learning curve.

A good place to start with a UX process is with what the user will experience. Define what the user will see and what they can do in an easy map to follow.

Basic tools/stages:

  1. Understand — separate needs, wants & desires, then write them down.
  2. See|Do — define the relationship of actions and interactive content.
  3. Atom Gathering — define and craft the components you will use.
  4. Into The Gray — layout where components work together.
  5. Interaction Models — illustrate how it works, and behaves.

Step #1 —Understand

Before you can solve any problem, you need to know the desired solution. Once this is defined, you can transverse the potential journey to your end. Keep your team focused by capturing the feature requests, then splitting them into needs, wants, and desires.

Draft a problem statement that captures the core problem you are attempting to solve.

Use these as a method to get everyone involved from the start.

The two things here will inspire the next steps.

Without a destination, how do you know where you are going?

Step #2 — See|Do

Lines and text, with which you can convey an enormous amount of information when you strip away meaningless distractions.

This tool removes the distractions of imgs, layout or content which allows the designer to focus on just the functional aspect of the user’s experience. To see through the project to its base elements of interaction.

Our purpose is to begin to define the relationship of actions and content.

This helps you not only scope the breadth of the product, but identify the gaps, and problems in your flow.

Heavily inspired from Ryan Singer’s article on UX Shorthand. http://bit.ly/1JSoLY0

A See is anything the user will visually see with their eyes. This goes above the hard line.

A Do is any relevant action the user can take from this view.

Don’t bother with repetitive and redundant items such as main nav links, footer links, or elements that don’t contain actions like images or copy.

A See|Do will map what the user will see, even when this exists outside of the “product’s” domain. Some elements like sad paths, emails to the user, or flash messages are often left out of the early stage UX efforts.

Sample Login See|Do map.

In an example of a simple login flow, that only takes minutes to create, the See|Do (S|D) communicates many things to our friend, the dev.

  1. Happy/Sad paths placement, consequence, & results
  2. Same page validation
  3. Same page forgot password input/trigger
  4. Email for reset password contains link to reset, not auto-generated password
  5. Where user lands after each action
  6. Password reset happens on Login screen with updated page state

The distillation of a S|D will allow for a workflow foundation that will keep all parties involved playing the same chord. Clients can understand how and where their features fit together and quickly get a full picture of the breadth of the product.


One thing to keep in mind is the value of a foundational understanding between parties involved. When all parties are involved from the ground floor moving through the UX system, communication down the road becomes more concise and targeted.

Step #3 — Atom Gathering

We want to give our clients and devs proper information on what we are aiming to craft. The concepts of Atomic Design present a great starting point for discussion and delivery. We want to create systems of UX not screens or pages. UX Legos that can be plug and play for our team.

Moving from a fleshed out See|Do, we can begin to define our components. We begin by expanding a S|D component with the atoms it will contain. In this login example, we list out the inputs, btns, and links that will form a molecule.

This step defines scope for both our front-end and API devs. Our devs can begin to formulate the API calls, or imaging the structure the markup.

This is an excellent time to gather the client requirements for features, forms, or data displays. Listing out the atoms of each feature/component this early in the process sets expectations and removes the ambiguity or assumptions in the product.

Step #4 — Into The Grays

Now we begin to layout our See|Do components with the atoms we have defined. Here, we are fast and loose. Keep them simple and ugly to remove subjectivity in decision making. Personally, I like to remove even alphanumeric characters and use a redacted font.

The Gray process should take minutes per component. Experiment freely with layout and positioning. Use other components you have defined to give context if needed. This tool is meant to remove assumptions of how it should work and start the conversation of how it could work.

One objective is to visualize where our Do’s fall in to the page, juxtaposed by blocks that represent future content.

In the login example, we begin to layout many different layouts that put the hierarchy and focus on different parts. Not all the layouts are entirely familiar, but we are looking to include any viable idea.

When you have a few viable options you can begin simple user testing. Will users understand where the forgot password link will be? Will users prefer one layout on desktop and another on mobile? Are there any basic assumptions the user will make based on the btn positioning.

It’s good practice to further develop your molecules and organisms into templates. Flesh out your templates with real content. Test how users will react to the templates, test how quickly they understand the workflow with content.

Atomic parts as you travel into the grays.

Atoms — Simple single elements. Use these to construct your base components.
Molecules — Align these with their See|Do counterpart. It demonstrates the bond between connection and display.
Organisms — Your molecules gather together to make these more complicated tools.
Templates — Your first looks at “screens”. It’s good practice to envision a desktop/phone/tablet template for the same “screens” or component sets.
Pages —Put real content into a template to test it out. Fill it with images, and copy to get a solid feel for how it will work.


“Shut up and calculate!”

User test as soon as possible, remove any assumption of how you think your users will behave and get hard data to back up your concepts.


Step #5 — Interaction Models

To round out the components we are defining, we must also include the behavior. What are the tap areas? How will it move? Does the layout change when on desktop or mobile? All these things need to be considered and communicated to the developers.

Simple examples of interaction models for UX-Triage components.

These are relatively simple examples of interaction models for a molecule and organism. The points to communicate are how the atoms interact, how the molecule might move or react to other molecules on the page. Define tap and click areas, or define how the components will grow.

All these touch points will help the developer understand how the product will fit together. It will also communicate to the UI/Hifi designer many of the UX’ers intentions for the user’s interaction.

Implementation

Every team needs to find it’s own way of communication and collaboration. While working with the many, diverse teams over my time, this process has been a breeze for both the UX’ers and the devs on the recieving end. There is plenty of room to tweak it as you might need.

It will not work for every team, but I have successfully implemented it with large scale enterprise teams and 2 man startups. One of the beauties of these tools are how simple they are, which allows clients, or product owners to jump in and communicate clearly.

When a ***UX Triage*** is in place, the team will be able to function largely without the play by play watch of the UX designer. They will be able to rely on the tools and parts of the system to plug and play various parts for many solutions.

Keep it light, keep it clear, keep it updated.


Real world use?

At Spartan, I use these tools everyday. The most common use is during a
UX Audit, where we work with a client in an 5 day design sprint to scope their product, define features, navigate obstacles, and test prototypes.

If you would like to see or hear more about how I have used these tools in practice, reach out. You can google “tyrale” or hit me up @joinspartan.com. With such a blessed unique name from my folks, I am an easy fella to find.


TL:DR

Fresh tools for UX designers that want to move faster, while providing developers information early and often. Influenced by the Atomic Design concept, UX’ers can craft systems with the same principles & components. We should deliver compontent systems to our friends the devs.

Basic tools/stages:

  1. Understand — separate needs, wants & desires, then write them down.
  2. See|Do — define the relationship of actions and interactive content.
  3. Atom Gathering — define what are your base parts.
  4. Into The Gray — layout where components work together.
  5. Interaction Models —illustrate how it works, and behaves.

Update: I have written out further explanations on the movement from See|Do to Grays. Check it out here.