Take the 2-minute tour ×
User Experience Stack Exchange is a question and answer site for user experience researchers and experts. It's 100% free, no registration required.

I've been unable to find a good guide for naming steps in a workflow (status labels).

What are some principles / best practices?

If you're curious, my specific case is:

I have a system where users submit payment requests. If the user does not cancel the payment request by the time our Customer Service team sees it, Customer Service reviews the request and either marks it as "fraud" or approves it. After approving dozens of requests, the CS employee can press a button to upload all of the approved ones to a 3rd-party payment system. Then time goes by (the response is not immediate), so these items are in a limbo status (which I'm thinking of calling "uploaded_for_processing"). The 3rd-party payment system eventually returns "success" or "failure" for each request; in the success case, we set the status to "complete" (in our local system). The failures need to have their statuses set to something that lets the CS rep review those (e.g. failed_to_process). For each, the CS rep needs to contact the user to inform her that her payment request failed and that she needs to try again. Then the CS rep would mark the request as "reported_failure_to_user".

  • new
  • canceled
  • fraud
  • approved_for_upload
  • uploaded_for_processing
  • failed_to_process
  • reported_failure_to_user
  • complete

Something doesn't feel right about my choices for these status labels though, so I'm wondering if there is a good framework for thinking about how to name them well.

Also, these status labels are for internal (Customer Service) use. Our customers won't see them.

share|improve this question
1  
I have no naming framework to offer, but how about "rejected" instead of "failed_to_process" (after all, it was looked at with a negative outcome, instead of, you know, network troubles preventing upload), and "submitted" or "pending processing" instead of "uploaded_..."? –  Ulrich Schwarz Jun 13 '13 at 6:50
add comment

3 Answers

up vote 5 down vote accepted

Some points for good labeling are:

  1. Short – 'submitted' vs 'uploaded_for_processing'
  2. Distinguishable from each other – bad: 'uploading' and 'uploaded', good: 'uploading' and 'submitted'
  3. Same styling rules – try not to mix verbs and nouns and use same case
  4. Understandable – user should know business process to match labels in UI to business phases

For taking attention to the items which require user actions you could use color-coding.

With minimal effort on learning business process you can display workflow schema for user. enter image description here

share|improve this answer
    
This is great! Also, what tool did you use to make that workflow diagram? I'd love to visualize more stuff that way. Thanks! –  Ryan Jun 13 '13 at 20:51
    
Another principle that I was considering was: independently understandable. In other words, I feel like it would be ideal if the status label independently provided so much information (without a diagram or even knowing what the other possible statuses might be) that the (internal) user would know (or could guess) where the flow has been and where it needs to go next. This principle would seem to conflict with your "#1- Short". Do you think having 1-word labels is more important than my "independently understandable" principle? Thoughts? –  Ryan Jun 13 '13 at 20:58
    
Ryan, I have used Xara Designer for the diagram. –  Alexey Kolchenko Jun 13 '13 at 21:27
    
Nice points of good labeling! Brief and to the point! –  Anna Rouben Jun 13 '13 at 21:35
    
Labels should be definitely meaningful for users. There are two edge cases: 1. Labels are just numbers which reflect process stage – they are fast recognized, good for experienced users. 2. Labels are self-containing help texts – good for new users, bad for experienced ones, clutters UI. As you develop labels for special users, they should be awared of business process and use the system frequently. This means memorability and learning curve are high. After several usage they will recognise (not read!) the labels by first letters. That's why icons are widely used, too. –  Alexey Kolchenko Jun 13 '13 at 22:11
add comment

An important goal here is to make labels meaningful for your internal users. You could do a little study with a few of your internal users. Give them cards describing the systems states and ask them to label each state. You can also ask each participant to elaborate about their label choice to better understand how they users think about the domain. You may see some trends. Since the customers are internal, it might be easy to recruit participants. To make it easy for the participants you could even consider just providing state descriptions in the email and ask each participant to reply to you directly with their labels. Good luck!

share|improve this answer
    
This is a helpful thought! Thanks! –  Ryan Jun 13 '13 at 20:53
add comment

I believe there is a way to go beyond the trivial advice of "use the vocabulary of the target audience (just go figure it out)".

When you put a label to something, try to make the label describe what it means to the user, and not the technical meaning or implications it has.

For example, when viewing the shopping cart, you would call the things inside it products or items, and not rows or entries (see my answer to a similar question).

In your case, try to think what each state means to the user. When we want the interface to be more "actionable", you might consider naming the states after what the user should do with items belonging to each state, e.g. "Needs review".

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.