2

The End-User of our product has several peers, and they collectively work according to a ticketing system.

  • A ticket gets submitted and goes a group pool of tickets, a shared queue.

  • End-user also has their own pool of assigned tickets, their individual queue.

  • The queues are (essentially) a table of data with each row containing one ticket

  • The shared queue and individual queues look nearly identical, down to the button on each ticket's row that says "view."

On the shared queue, the 'view' button displays the ticket data, but in a "read-only" format.

On the individual queue, the 'view' button displays the ticket data in an editable format. The user can act on it, or 'perform write operations.'

An individual can't work on/advance/edit/complete a ticket that is in the shared queue.

The tickets can only be worked if they've already been moved to an individuals queue. Sometimes the End Users get busy and forget what queue they're on, and clicking the 'view' button is frustrating to them because they expect to be able to work on it, but are faced with a 'read-only' view of the ticket.

Question:

What would be the ideal text change for each button to clearly indicate what the end user will see/experience when they click it?

I'm getting a lot of pushback from technical support, devs and product management. Each feels strongly about which should say 'view' and what word/label can be used instead of 'view.' Should it be an action word like "work ticket" or "complete" or "edit" or should it be something like "preview" or something else entirely?

  • 3
    One can use 'View only' for shared queue and 'View & Edit' for individual queues. – Usman Mani Oct 2 '18 at 5:41
  • I don't understand why the shared queue tickets are read-only. – Yvonne Aburrow Oct 9 '18 at 15:11
  • 1
    @YvonneAburrow it prevents multiple users from 'working' a single ticket by accident. You can view it before you take it, but you can't edit it/interact with it until you take it. – Maigen Thomas Oct 9 '18 at 17:45
  • OK thanks - can they take the ticket from the shared queue? – Yvonne Aburrow Oct 9 '18 at 18:38
  • @YvonneAburrow yes, it's the only other thing that's allowed in a shared view besides viewing the ticket. – Maigen Thomas Oct 9 '18 at 18:45
1

For me, the key part of your question is:

Sometimes the End Users get busy and forget what queue they're on, and clicking the 'view' button is frustrating to them because they expect to be able to work on it, but are faced with a 'read-only' view of the ticket.

Therefore, the main obstacle to overcome is being able to quickly work on either type of ticket, without having to go through unnecessary steps. The key to solving this problem is, I think, moving from a model where each button does "one thing" (e.g. view a ticket; take ownership of a ticket; edit a ticket) to a model where a button may do more than one thing.

In your case, for all tickets (whether in the user's queue, or the shared queue), you want something like an Edit or Work on button. For tickets already assigned to the current user, it will open the ticket in read-write mode as is currently done. For tickets in the shared queue, it will first try and take ownership of the ticket and – only if that succeeds – open the ticket in read-write mode. If the user fails to take ownership (because another user beat them to it) then – because the first user's intention was to edit the ticket – I think you shouldn't open the ticket in read-only mode, but should, instead, display a message along the lines of "Another user has taken ownership of ticket #12345".

I don't want to get into too much detail over how your UI should look (the key is combining take-ownership with edit), but my first pass might be something like:

    Ticket #   Own? Description
    —————————————————————————————————————————————————————————————————————————————————————
    12345       X   Oscillating flange does not oscillate                 [Work on]  [..]
    —————————————————————————————————————————————————————————————————————————————————————
    23456       —   Reciprocating pump does not reciprocate       [View]  [Work on]  [..]
    —————————————————————————————————————————————————————————————————————————————————————
    ...

(Where I have more-or-less merged the two queues into one, although you could retain two distinct queues.)

Here, all tickets have a Work on (or Edit) button. I have also chosen to give tickets in the shared queue (i.e. that the current user does not own) a View button: this would allow uncontested viewing of the ticket, without attempting to take ownership of it. You could have a View button for tickets already owned by the user, but (a) I think it helps distinguish owned/shared tickets, and (b) from your description it doesn't sound like you need a read-only mode for tickets already assigned to a specific user. The .. button could lead to less-used options, e.g. take-ownership (of a shared ticket), release, close, etc. (Depending on space, some of these may have their own dedicated buttons).

I would also have – if not already present – buttons/commands on the (read-only) "View" screen (of a ticket in a shared-queue) for one or both of "Edit" and "Take ownership": so that if a user does open a ticket speculatively, and decide they can work on it, they can (attempt to) do so directly without having to return to the ticket-list screen.

0

It sounds as though the workflow is:

View shared queue
--> Take ticket [flagged as taken] 
--> [Ticket appears in personal queue]
--> [other actions now available]
--> reply / close / reassign / relinquish

If that's the case, then there should be two buttons in the shared queue, labelled View and Take ticket (and Take ticket should be a valid action for the shared queue).

And in the personal queue, there should be the following buttons: Reply | Reassign | Relinquish | Close.

If you click close, the options for closing should be works for me, resolved, workaround available etc.

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

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