See also ("Provide a color palette and design for buttons that are purely highlighted links, to distinguish them from actual UI buttons") which I think needs designer and developer input.

On Mon, Oct 26, 2015 at 12:43 PM, Pau Giner <> wrote:
I think one of the underlying aspects here is the idea of side-effects and safe navigation.

We learnt by using the web that buttons and links had generally different expectations. Links have been used for navigation purposes, while buttons are associated with commands which affect the status of the system. These associations make us to click links without having to fear any unexpected change in the system.  This allows to navigate more fluently when those assumptions are met, and get into trouble when those are broken (e.g., a delete link in the middle of other navigation links).

I think the purpose of colour buttons is to set similar expectations. We highlight the next logical step and indicate whether some new content will be created (green) or destroyed (red) as an outcome. Creating and deleting content, even if these actions can be undone seems worth some considerations in an environment where content is public and edited collaboratively by many.
So I think that setting these expectations is useful on helping the user to determine on which decisions to put more thought and which ones to do more fluently.

I think we can design great experiences with or without this pattern, but this is a pattern that requires to be applied consistently to work. We need to consider also that the resulting effects on the user affect more their intuition than their conscious thoughts. So while I think it can improve the user experience, it is not something easy to test just by asking if the user can figure out why the button is green instead of blue, even less if the user has not been exposed to a consistent application of the pattern for a while.

If the problem is that it is not easy to be applied consistently, we may consider clarifying the guidelines to indicate the cases where each one should use with as unambiguous definitions and clear examples as possible.

Google use of colour buttons has been mentioned. In this talk (at 26:40) the code colour they used is explained: red for creating something, blue for do/confirm actions such as search, and green fro actions with an audience such as share. The fact Google has been using this approach does not mean that we need to follow, but it illustrates that associating colours to certain types of actions is not an unprecedented idea in the design of user interfaces.


On Sat, Oct 24, 2015 at 2:02 AM, Isarra Yos <> wrote:
On 23/10/15 18:28, S Page wrote:
Obviously design is for users. But having a pleasant productive time using a design and understanding its nuances are very different things. "Testing with your users to see if they understand the difference between [two button colors]" seems crazy (unless I misunderstand what designers mean by "understand"). Does Google test to see if users understand the difference between the rounded edge and the shadowed edge in Material? I really doubt it. Different colors and treatments provide different experiences, and there are guidelines when to use them.

That's nuances, details. Nevermind nuances. The question here is, on whatever level, does the distinction help the user? Have users noticed that there is a difference? Has it meant anything to them? Has anyone looked into this?

If it's shown to help, that's all we need. We have a justification for the maintenance overhead and stuff. And cookies. Always cookies. We should all go get some cookies.

Design mailing list

Pau Giner
Senior User Experience Designer
Wikimedia Foundation

Design mailing list

Nick Wilson (Quiddity)
Community Liaison
Wikimedia Foundation