Best practices for naming steps in a workflow (status labels)?

Question

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.

Answer 1

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.

Answer 2

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!

Answer 3

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".