Hub and Spoke

Problem

People have independent tasks or applications and need to organize and easily access and focus on them.

Solution

Create a navigation model that has a central hub with entry points into the various isolated tasks or applications (spokes).

Context

• People need (or want) to focus exclusively on one task or application at a time.
• You have an extensible plug-in model where individual plug-ins have no normal or expected means of cross communication or linking.
• Your target device or form factor makes providing Global Navigation impractical or entirely unfeasible.

Rationale

There are few classes of software solutions that really warrant this approach. Games are a good example—people expect to and usually want to be immersed in them. Sensitive tasks that require a person’s full attention could be another. These are examples of potential spokes in a hub and spoke implementation—the hub would be a common home/launching point.

Usually, the reason for the hub and spoke pattern is more technically-driven than user-driven. It is most commonly seen on phones and other small devices where having global navigation (and even the ability to interact with it were it displayed) is difficult or in situations where there is an open plug-in model for applications, such as Facebook, where the hub is more of a facilitator for disparate services and applications to come together in one place. The iPhone fits both of these constraints.

People have become accustomed to feeling like they are multitasking and that they can get around to other functions and areas of things easily; they don’t generally appreciate being forced to access (or feel like they’re stuck in) one task or application at a time. Sure, they probably are mostly focused on one at a time, but they like to easily move between them. So if you’re not constricted by technology, make sure you have a good reason to lock people into the hub and spoke model.

Implementation

The nice thing about the hub and spoke model is that it leaves the spokes relatively free to decide on their own internal navigations and constraints. In fact, you could almost consider the browser itself a hub and the various sites out there spokes, though they usually do far more linking between each other than would be considered normal for spokes in a more intentionally designed hub and spoke implementation.

If you are in control of the spokes, i.e., all the individual isolated tasks, tools, applications, what have you, then it is really a matter of creating a shared hub for them. You should remove global navigation from any spokes, especially if your purpose is to constrain users within a particular tool/task flow to completion, though you may want to keep an exit chute (Home) navigation affordance. And if there is a definite completion step, it should generally lead back to the hub.

If you are designing an open, plug-in model, you also need to create a way for new modules to register with the hub, provide some basic data (such as icon, name, and description) about themselves, and then give them a host with very minimal surrounding navigation. The hub then needs to be able to scale (even if it is simply scrolling) to accommodate an unknown number of spokes.

Sources

Jennifer Tidwell , Designing Interfaces

Tags

Navigation, Information Architecture.