The Difference Between a Light Switch and a Toggle in UX.

The Difference Between a Light Switch and a Toggle in UX.

2011 October 14

by Jason

Here at DesignMap we go to lengths in determining the best controls for our clients. Often in the course of explaining our choices, we uncover important distinctions, that we feel adds to the growing field of UX. One of those instances came up recently regarding the use of a light switch vs a toggle. Here is how we see the differences.

Light Switch
Light Switch is a sliding button which displays its current state, clicking the button will switch states. A Light Switch should be used as a gate, in scenarios where simple binary functions are necessary. For example turning on a set of features or search criteria. In the diagram below the grey line represent information flow with the Light Switch acting as a gate: either the information flows or it is stopped.

Toggle
Toggle, a button which only allows for one item to be selected at a time, turn off unselected items as a selection is made. The Toggle should be used as a pivot where both items in the Toggle are options – for example, filtering a grid by one of the options in the Toggle. In the diagram below the information flow is diverted to either option of the Toggle.

Best Practices
Light Switches generally should have very short items names, “On” and “Off”, “Yes” and “No”, etc. Additionally, to the user, the name that is not selected should be able to be inferred from the selected name. For example, most people would know that if they see “Yes” the opposite would be “No”, even though they cannot see the word No in the Light Switch.
Toggles need to show all options to the user as the non-selected options cannot always be inferred by the selected option
Furthermore, Toggles could have more than two options, so showing all options at a glance is imperative.
Incorrect Usage
In the case of Toggle switches, “On” and “Off” do not work well. The reason behind this assertion is, that it requires users to read two labels in order to know the current state of the switch. Additionally there is no color difference between the two options, which would also help with the determining the state of the Toggle.

Both Light Switches and Toggles have places in modern web applications. Hopefully the above descriptions will help clarify which scenarios those controls are better suited.
What do you think? Do you use Light Switches in your interaction design? Let us know in the comments.
ShareThis

UX Magazine Gamification Article

2011 May 24

Leave a comment

by Audrey Crane

Super-excited to have the opportunity to contribute to UX Magazine.
ShareThis

Stories, Maps and Products

2011 May 14

1 Comment

tags: Process, product

by Neil McKay

Product opportunities come in many forms, and there’s just as many ways to define an opportunity and translate it into something tangible.
To create a great product, Product Managers, Developers, and Designers (among others) need to both understand the larger context, and develop an intimate knowledge of every detail.
Recently we’ve been using a pattern called ‘Story Mapping’ (coined by Jeff Patton) to help us do both. Originally developed to bridge the apparently irreconcilable practices of user centered design and agile development, the benefits of Story Mapping apply even when the organization is not using an Agile methodology.

The (my) case for story mapping

Story mapping gives us a tool to decide what’s in scope and what’s not.  Ideas are easy, and making a great product is as much about making tough calls on which features don’t make the cut as it is about interaction design. Story Mapping can help you balance what your user needs and what you can deliver on time.
This is a low cost, fast and transparent process. It’s great for exposing and managing complexity that otherwise may have only been found when the developer or designer are actually building the product.
The act of writing a ‘story’ requires us to empathize with our user. A product that anticipates the desires, fears and aspirations of a user will almost certainly exceed expectations.

Getting Started

The Story Mapping process needs inputs, something to frame the activity. We need to know where this story starts, where it goes, and where it ends.
These goals are usually found in business requirement documents. As the name implies though, story mapping, like a good story works best with actors and motives. In the user experience world we create Personas to consolidate user research into a set of archetypes representing the spectrum of your audience.
Before getting started we choose one of our Personas to be our headline actor. With our feet firmly in our persona’s shoes we start telling stories of how Jane (no longer just a ‘user’) would get this job done, and very importantly: why Jane does this.
We’ve been trying to keep this process simple, light weight and maybe even fun. This way the team can see the benefits of the process as they’re working on it.
Get started with lots of post-it notes, lots of wall space, and a cross discipline team. Keep your team small, I’d suggest 3 at most. People who’ve been involved in your research, listening to potential users, are your best bet for informed contributions.
Product managers, subject matter experts, client support staff and designers are also likely candidates for your team, and don’t hesitate to work with developers, even potential users themselves. You can always bring other people to your completed map later to review and test the stories.

Telling stories with your team

See Jane’s user experience

Epics

Begin with high level chunks, describe Jane’s work flow from end-to-end.  Use a post-it for each step.  Keep the steps broad enough that reading through the steps end to end will be about the length of a sentence. This is often called the ‘Epics’ level.
An over simplified example:

Reading through your 'Epics' should describe the tool in the length of a sentence.

Jane wants to read, manage and respond to incoming email and also create and send new emails.
Think of these as buckets of functionality to cover the user’s needs, and, of course, to address all your business requirements.
Keep reviewing and adjusting these as you build the map.

Activities

For each of those high level steps do the same again, but now with a bit more detail.
Note what the user’s goal is, what they want, and why.
“Jane wants to prioritize emails from multiple accounts to balance two jobs and feel in control.”
We call this level of story ‘activities’.

Jeff Patton describes Activities as groups of related tasks that can be achieved in one sitting.

Tasks

Think more granular as you write the next level of stories: what are the individual decisions or actions that Jane wants to make?
These ‘Tasks’ get us into the details of each Activity, and expose all the complexity of activities that previously we wrote off as simple, or not a big deal.
Position them horizontally in sequence so you can read from one to the next: Jane ‘browses’, [and then] ‘selects’ [and then] ‘marks email as high priority’.

Read 'or' between tasks down the column, 'and then' between columns.

Of corse in any workflow there maybe several options at any one point.  To accommodate this we stack stories vertically  – so we can read down a column of stories with ‘or’ in between: Jane ‘browses all emails’ [or] ‘searches by keyword’.
It’s important to give this step it’s due. Tasks are the building blocks of your map. The key benefits of story mapping are gained by validating the Activities and Epics above with cohesive, comprehensive and highly detailed tasks.
You may find the need to revise the Activities and Epics as you expose the details.

Feature Prioritization

Triage for user satisfaction
Take all those vertically stacked ‘or’ tasks and prioritize them. Reposition the tasks that are most crucial to Jane and move them to the top of each column. These are the tasks that are necessary for Jane to complete her goals. In my very simple example above, it’s critical to be able to select an email, selecting multiple emails is not.
The items at the top must allow the Jane to move horizontally through the stories and achieve the most important goals – this is your minimum viable product.

Scoping

This step makes Story Mapping ‘agile’ and time-line friendly
Your team can now slice through the map horizontally to select which tasks will be addressed per release. Here you can evaluate effort estimates, demand or necessity of a feature and of course your time line. If your organization is using agile you can fill your backlog and sprints in this step.

'Search can wait, but we're able to do multiple select now...'

So…

I think this is a great tool to shine a light into all the corners of your product. A wall covered with post-it notes makes product plans tangible and physical, everyone can see literally how big it is.
Stand back to see the big picture, step forward to understand every little piece.
Be prepared for your map to get HUGE, and for folks to baulk at putting the effort into something made of post-it notes. If that happens, I’d point out the alternative: some individual has to sit down and type out a document that details every little bit of the product. Then many people have to sit down read, and respond to that document. Revise and repeat. Personally, I’d prefer to hash it all out in a team with pens and paper.
You can rally your team around the story map, where everyone can discuss, understand and contribute to the entire undertaking, and celebrate each milestone reached.
P.S. Obviously story mapping is best in-person, but reality means we work remotely sometimes. I’m still struggling to find a good online tool to do this process with remote teams. There’s a growing list of tools, from simple and literal post-it note apps like Listhings, through to agile project solutions like Silver Stories, and ScrumDesk, none of which I endorse due to either being under powered or overly complex