This comment from an user sums the very scenario and the issue, I recently encountered while designing a product –
“I have been using Toggle Button to “Add” and “Remove” elements to a collection using simple Toggle Button (one with state visible at a time) which had following states.
ADD (if button wasn’t clicked ever)
REMOVE (if the button was previously clicked and an item was now part of the collection)
With this in mind, lets deep dive.
A Public Contact Search facility, from where you can search, select and bookmark your preferred contacts in your own contact list.
- User found Joe’s contact in the public contact search facility.
- Adds Joe to his Contact List.
- Gets a confirmation that Joe is added to his List.
- Has an option “Manage” the contact addition (imagine it opening a popup to confirm other things, including an option to delete Joe from his Lists)
- Whenever Joe’s contact is visited in future (public), the user gets this understanding that Joe is already in his List.
Four clear actions are:
- Add Joe to contact list
- Get confirmation on the addition.
- Manage Joe’s listing in future
- If Joe’s contact is visited in future through public contact search facility, get a clear understanding that Joe is already in the user’s contact list (and hence the option to Manage the contact).
Without much talking, here’s what I came up with — ”A Multi-state UI Button With Inline Notification” that tries to fulfil all of the above.
- A multi-state button that gives importance to notifications and its vicinity.
- A persistent notification helps to understand the context, at any later point of time.
- Thoughtful copy makes the CTA — making the button actions (with a suggestion to what they will do) more clear. Context is the word.
- Motion design helps make the transition between states more meaningful and avoids the instant switch.
- Works good for mobile too, except the hover state.
- In cases of smaller button, or bigger notifications, the notification text could be placed in the very near vicinity of the button.
This is just an exercise that fit well with the product at hand, but I am sure could be applied elsewhere too (Here’s a similar solution, but applied to a different problem — one I recently shared on an UX forum). It obviously demands more real state, but then the goal is to make better experiences and not just save more real estate. Right?