Making user recognise they are writing a public note / message rather than a private note / message

Question

We're building a custom business application which internal staff have access to and also clients have limited access to.

There is an option for the staff to leave a comment / message to each other, and there is also an option for the staff to leave a message to the client.

What i dont want to happen is the staff thinking they are leaving a message to each other, but actually its a message to the client.

The UI is currently a table like below, clicking on the green squares opens up a notes modal were they can leave messages on each item (each item is a row in the table).

What would be a way of alerting the staff users that they are about to leave a client note rather than an internal note ?

I was thinking some sort of confirm on the client notes, or something similar to a captcha (not so complicated though, something like a simple maths question so they have to stop and think) but this seems a over the top.

Answer 1

I would start with different (and larger) icons for the notes in the table/grid e.g.

• an icon of a note with a padlock for internal notes
• and icon of a chat symbol for external notes

Then I'd consider moving the icons closer together, to make the differences between them more noticeable (to prevent user from only noticing one). Make sure they are not too close for touch screens though.

Then I'd change the write note UI to include the icon in the title followed by "Write internal note" or "Write note to customers".

Then I'd enable changing the note type if the user got mixed up by clicking on a [change] button that appears at the end of the title.

Finally, I'd consider adding a confirmation box for external notes, perhaps displaying it only to new users or users with specific statistics (e.g. users that haven't created a lot of notes).

Example of dialog:

^{download bmml source – Wireframes created with Balsamiq Mockups}

Notice that there are differences in:

1. the icon
2. the title
3. the "add note" text
4. the button text
5. the button's verb (save vs. send)
6. a different link for users that entered the wrong dialog

Edit:

You could also add a checkbox saying "This note is ready for publishing" next to the submit button to absolutely make sure that no one misses the difference.

Answer 2

I would say you should explicitly label them as such:

Maybe even do a bootstrap-like popover notification when they hover the green, Client Notes, icon which explicitly states that These notes are visible to the client!

Update

After reading your comment I would like to update the answer to mention that adding alerts, confirmations, Captchas, etc...are merely roadblocks which users will eventually learn to just expend the minimum effort required to get it out of their face.

A math question or Captcha does not necessarily translate into Are you sure you should be doing this? but rather We don't want spam so complete this mindless task please.

Educating the user up to the point of saving is, in my mind, the best route because it should invoke a thinking process during the entire time rather than just having something happen at the last second.

With that said I can also recommend adding a line of red text below the textbox saying something like These notes will be visible to the client.

Answer 3

First of all, never count on users to read anything. Not. At. All. They won't, and by the time you are explaining to them that the label was Right! There! On! Their! Screen!, the damage has already been done.

Consider making the micro-interaction for composing a customer-visible note strikingly different — and slightly more difficult — than writing an internal note.

For example, you could allow users to compose an internal note simply by clicking on one of the icons in the "Design Notes" column.

In the "Customer Notes" column, you could require them to click-and-hold to reveal a pull-down menu that says "Compose a Customer Note" (or the appropriate language). The icons in the column could be accompanied by the familiar "▾" symbol to let them know that it's a menu, not a plain button.

Making the interaction style easier for "safe" internal notes than potentially "dangerous" customer notes gives your users a momentary pause to remember that they're writing for a different audience.

Answer 4

Request Tracker (a trouble ticket system) handles this quite well.

It has both comments (which are internal messages) and correspondence (which is sent to end users).

When composing a message, the background of the textarea is white for comments, and light red (#fcc) for correspondence.

The red background color makes you stop for a moment and consider who you are sending this to - which works well. Accidentally sending a client message to staff isn't a big deal, but sending staff messages to clients can be.

Here are some screenshots of how Request Tracker handles it, slightly censored:

Comment - Internal communication

Corespondence - Client communication

As you can see from the screenshots, the color of the text area changes. You also have the option to switch between comment and correspondence from this screen, and to add people to CC. Thanks to the color change, we almost never get it backwards and send staff only comments to our customers.

Answer 5

I think the most simple and effective solution would be to change the labels and the interface of both modals. So there is a contextual and visual difference between the two functions. Because now the two different functions are almost the same in terms of Look & Feel, so people are likely to think it will work the same and will confuse the output of the two different functions with each other.

I suggest to label the Internal Design Notes the same: "Design Notes" and the Client Notes to: "Messages to Client". Let the "Design Notes" look like actual (yellow) sticky notes. Change the interface of the "Messages to Client" to speech bubbles, so it looks like a message.

Answer 6

Are notes to clients also shown internally to other staff? Do notes to clients have the same structure and info as notes used internally?

If so, on the compose message screen, consider using a simple checkbox immediately before the "Post" button that say:

[ ] Make this note available to client

[Post Note] cancel

On the table you have, consider combining the Design Note & Client Notes together into a single column like Note Type and show "Design (private)" or "Client (public)". Different colors would be good.

Answer 7

Although I'm not a fan of them, if this is important enough that you have had internal discussions sent to client in the past then ye olde alert box may be most appropriate here:

If it has been damaging in the past, it may take a change to the workflow, i.e. client notes remain hidden until a manager/supervisor has reviewed them.

Answer 8

I think that you should try to differentiate the columns more distinctly, something like that (I also moved both columns into one single pseudo column):

At the picture above:

1. I've used numbered links to show how many comments are attached to the items: using numbers instead of the similar icons will improve perception.
2. I've used different colors to make these columns visually different.

Concerning "New message" dialogs. I think that you may do the same trick: use different colors for titles or for "submit" buttons to make them more visually distinct.

Answer 9

What about changing the text in the "Save" button to "Save Public" and "Save Private" respectively (or something similar). If you want to make it even clearer give them different colours. After a while your users would associate the colours with private/public messages.

Answer 10

Use fundamental design principles to create visual distinction between the elements.

Using color, layout, typography, and scale, you can indicate to the user on a fundamental level that there are two different kinds of notes.

Most of the other commenters have stressed one of these concepts (layout), but have not addressed the other design fundamentals in order to create visual distinction. For the most effective design solution, you should utilize all of these elements to indicate to the user that there are two different types of notes being created. I agree with @dland that you should never rely on the user to read anything (this should be a secondary visual cue), which is why you should visually communicate the distinction.

Although I don't have time to really design this for you, take a look at this image and notice the differences between it and above:

With simple modifications, it becomes more clear intuitively that you are looking at different things. Adding color to the columns denotes visually that they are different things. Furthermore, using a shade of red indicates that this may be something that could be potentially hazardous. Using different iconography, as well, is an additional visual cue that these two types of items are different.

These visual cues, when carried forward into the modal dialogs, further reinforce the distinction between the elements:

While these are rudimentary at best, you can see what I am getting at. The design problem, ultimately, is that there is not sufficient contrast to indicate that these are two separate items. By utilizing and manipulating fundamental design principles, you create a better design solution.

---

On another note, I think that the problem could be solved more simply by improving the Information Architecture. Since notes to clients are more potentially hazardous, perhaps accessing this would be located in a different part of the application.. Maybe rather than accessing the notes to clients functionality within the object itself, you could have a messaging system where you compose a message, then select the object(s) to apply that comment to.

Inverting the relational structure of the message will make it more intuitive, further, that you are creating a different type of message. This, in my opinion, would be the best holistic solution:

• To compose a design note, you access the object first then attach a note to it

• To compose a client note, you access the note first then attach an object to it

Furthermore, since theoretically the same client note could apply to multiple objects, this would allow a user to attach a single note to multiple objects. Otherwise, they would need to re-enter or copy-and-paste in order to attach the same note to multiple client objects. This may or may not be relevant for your application, of course, but from a theoretical perspective is applicable.

Ultimately, by improving the information architecture (ie. accessing the different types of notes in different areas) along with an improvement in your fundamental design concepts (color, typography, scale, layout), you will produce a well-designed application.

Answer 11

Here is a completely different approach then mentioned so far. If we consider the idea that notes to the user submitting them are always the same thing, so it's a matter of where they are submitting to.

Here is an example from popular agile program JIRA

When writing a comment on the side of the submit button is a "target audience" drop down, set by the application, so people who aren't suppose to see the notes dont, but to person with all access see all the notes.

So I would amend your modal like so:

^{download bmml source – Wireframes created with Balsamiq Mockups}

Where (1) is the new drop down in the modal window, that when you select each audience (2) Will update with the type of note you are submitting. Programatically you now also only have 1 window to deal with and through AJAX update each window depending on the intended audience.

Furthermore you couldn't submit until you select the audience, once you have then you see the add note button.

Answer 12

I feel like you could simply display the pop-up when they click to create a note and after they finish the note they could then hit a submit button which would prompt an alert saying "This note will be for the client, click yes to continue" or "This is for the design team, click yes to continue. Upon clicking yes they are brought back to this page, almost a fail safe system. Just a suggestion, hope it helps.

Answer 13

I would suggest you get rid of those big text in red. Instead, use a specific color (e.g. light orange) for the background of the text area as well as for the Client Notes column. And use "Share with Client" instead of "Save".

Answer 14

Whats wrong with simply changing the modal titles:

(Private) Design notes

and..

(Public) Client notes

Answer 15

Some options

1. Provide a watermark in the text area where they are entering
2. On tab out warn them about it
3. when they start keying in text, highlight the border of the text area with some specific way

Answer 16

Our purpose here is to give some acknowledgment to internal staff that whom they are making note to. So there is no point in doing any change in modal. Let same modal be used for both internal and client(of course the content-heading will be separate). This will also keep code optimized and redundancy can be avoided.

Instead lets do single change in table rendering.

• Merge both the columns of notes into single column
• At the top of this merged column add a drop-down with options as select notes/internal notes/client notes

How this will help:

• Every time staff will have to go to drop-down select appropriate option and only that notes will be displayed.
• There will not be any confusion while sending notes as at a time only single type of notes are visible.

This can be one of the cheapest way in terms of design and code changes. Lets me know any visual required, but this should be understandable.

Answer 17

In the table, I'd follow @alexeypegov to indicate whether (and how many) notes exist in the respective categories. If you find out that there is no customer note after you clicked on the icon, you've wasted precious time and energy.

Regarding the pop-up design, I don't like the approach to make customer notes more complicated (by to-be-published checkboxes or - horribly - do-you-really-want-to-publish-this-note dialogs). The task is simple and so should be the interaction design.

To that end, I would design the different dialogs clearly different: In customer notes, add "TO:" plus the customer name (image, address, whatever you have), while in staff notes, just put in "<username> said:". Use different terms for the submit button, e.g. "Save" (short) vs. "Publish to Customer" (long). Depending on how playful you can go, use visuals like scratchpaper background vs. letter layout.

Think about two rooms, one where you talk to staff, and one where you talk to clients: There's different furniture usually, one has coffee, but the door works identically. Present the different dialogs with enough differences that the user immediately feels the client's presence.