UX Triage: Moving from See|Do to Grays.

This process is entirely meant to be non-linear. Traditionally, we move across our UX process from point A to point B leaving the previous steps behind. UX Triage is not traditional at it’s core. The See|Do and Grays work in unison and are both “living documents”.

For a quick-ish burn down of UX Triage, check out the post here.

See|Do priorities

Priority one with a See|Do is the define how your product connects together while it communicates to our users. It is not about Page A or Page B. It’s about how the user can do “n” things while they see “x” items.

Not all See’s will be pages, not all Do’s will be links or buttons.

Unlock the See

Commonly, as designers we are structuring out See|Do like a site map, the old top down pyramid of pages and links. Don’t limit yourself to only pages as See’s. More and more we are seeing products that don’t have any pages, or are single page applications. Think about creating a UX doc for Yo, or what you would deliver to the development team building a wearable with only LED feedback.

When we design for products that connect to the internet of things, they don’t often have a screen for user interactions.

Empower the Do

Things a user can do are limitless. On a previous project, I had to design a SMS system that communicated data and control over for each sprinker head on luxury resort green spaces. There were no “screens” or “pages” to put on a wireframe.

In an example with a little more fun, S.M.T.H. asks its users to throw the device in the air to compete in a game. No buttons or links for that type of interaction.

Our Gray priorities

While we are developing our Gray models, we want to keep in mind what the value will be to those on the receiving end. The developers I often work with want to know how the designer envisions the break up of molecules and organisms.

Not that this is gospel, but there might be an interaction that is enabled or impossible based on how the components are broken into parts. The developer should have additional insight on how it will impact performance, or any other number of aspects.

Grays are there to not only have a plan, but to facilitate the communication between the idea and the build. Grays that are too highly designed will slow the process and make the team wait around while the designer spends time in a vacuum. Just get it down and share it, design polish belongs in Hi-fi.

You can start, but you shouldn’t stop

An analogy of how these pieces might fit together, would have to be a road trip. The See|Do would be the map of your trip, while the Grays would be the events on the trip. This might sound backwards at first, but stay with me for just a moment.

See|Do’s as the map

The map isn’t only your ideal route, it’s also the path you take, the alternate routes for everyone else, and all the possible options within your product. It’s a map for many users who can take many paths. You can start out with a happy plan, but there might be a pivot here and there, or users can start from a different location entirely with different baggage.

Regardless of the path you want to take, there are variations and changes, don’t leave the map outdated, you want to keep the next traveler (dev/client/user) informed of the possiblites.

Grays as the plan

The events are many, and most of them optional. When a user arrives at a location, they can perform allowed events. Our Grays can define what they can do at each event, where the events take place, or similarities between activities. Educate the travelers on the how, where, why and which in your Grays. Don’t leave any room for confusion at what is going to happen when they arrive.

Short Case Study: Work iOS app

Work was a double-edge application — as mobile app for students to become brand reps on their respective campuses and a CMS to allow for W0rk or the brands to create and manage campaigns.

Work See|Do (student side)

The mobile application’s needs were quite shallow.
Allow students to:
· CRUD an account
· Find work orders
· Apply/Decline to the orders
· Track Task completion
· Submit for payout

Messages to the user are not “pages”, but they are what the user will “see” add need to be documented for the build process.

The user record being sent to the brand side is not a “see” or a “do”, but it is a vital piece of data for our friend, the developer. So adding a token of info here facilitates the conversation about when and where data is being passed around.

The See|Do is meant to accommodate the communication needs between the designer, the client and the dev team, not to strictly adhere to a style.

Work Grays (student side)

When the user is on the Dashboard there are many things they can “see”, but not many things they can “do”.

< The Gray here defines:

  1. An organism’s layout behavior (for example the work order)
  2. The Atoms or Molecules used
    in this layout.
  3. What items to call/use in the API or Database.

< Here the Gray defines:

  1. There is no change in the Work Order molecule from the Dashboard template to the Work Order detail template.
  2. How tasks are viewed, and stack on the page. Similar to how Work Orders stack on the previous screen.
  3. The approximate copy length for task descriptions.
  4. How users will fulfill the various Do’s on the template.

These are only a few of the parts for the entire application, but I hope they shed a little light on how I use UX Triage within the UX Audits with which I fill my days and weeks.

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.

Published in Startups, Wanderlust, and Life Hacking

-

Show your support

Clapping shows how much you appreciated Tyrale’s story.