SETTINGS APP
Windows 8.1 and 10
Information
Background
Windows 8 was the first step in combining a desktop PC with a tablet interface, however the two form factors were still had redundant concepts in key areas. One of these areas was settings: The mobile interface had a Settings app, the desktop largely used the legacy Control Panel. The Settings app contained only those settings needed for a tablet, the rest lived in Control Panel. This was very confusing for users who bought convertible PCs, as it was a guessing game as to where a particular setting existed. Or, worse yet, a user might not even know
With these issues in mind, our goal for Windows 8.1 was to eliminate the Control Panel as a concept and make the Settings app to be the new conceptual home for all settings. This would allow us to collapse concepts while cleaning up the information architecture and wayfinding of the system. All settings would now be in a simple, modern, touch-friendly interface.
These goals were understandable, but there were some significant hurdles to overcome: Time and scope. There was only one year to complete the work, as Windows 8.1 was a supplemental release. The scope was massive, as the Control Panel was an unregulated confederation of settings that had accumulated piecemeal over 27 years.
INCEPTION
There was little time. The scope was massive. There would be multiple teams involved, but I was the only assigned UX designer at the time. The Settings project team was rightfully anxious. The Program Managers began making spreadsheet inventories of all of the settings, dialogs and states they could find, but this only increased the collective anxiety as the sheer size of the iceberg became clearer.
The team desperately needed a plan to rally around. Amidst all of the anxiety I took some time to think about the challenge in the abstract. I was looking for an analogy that might simplify the problem and make it digestible.
THE MOVING ANALOGY
The thought occurred to me that we were not really building anything new. We were simply moving things from one place to another. When we physically move from place to place, we don’t take an inventory of every last item. We simply buy boxes of different sizes, load them up, label them, then move them.
With the moving analogy still fresh in my mind, I took a break and went to a nearby office supply store. I bought index cards of varying sizes to mimic boxes of different sizes. For labeling I bought some post-its and sharpies in different colors.
THE T-SHIRT COSTING EXERCISE
With my new office supplies in hand, I called a meeting with all of the core members of the Settings app team. I led them in a simple exercise:
Pick an area of the Control Panel.
Go through your area. When you see a page with a lot of settings, write its name and a brief description on a large index card. If the page seems typical, use a medium index card instead, etc.
If a page is very, very large, you can use multiple cards. Just number them.
If a particular page is an extension of another page (e.g. a modal dialog), mark that card with a red “E” for “enthusiast”.
Move quickly. Just size it up, write it down and move on.
We reached a point where we felt we had covered most of the conceptual space. We then did an affinity diagramming exercise on a large wall using all of the cards.
Once our clusters had settled, we were able to make a number of conclusions:
There were only 8 to 10 major clusters
Within each cluster there were 4 to 12 sub-clusters
The cards marked with “E” were clearly extensions of other cards and were not shared across clusters or sub-clusters
This led us to the conclusion that we could flatten the navigation to a “2 levels plus” model with only a main navigation, sub-navigation by pages, and extension pages where needed. So I wireframed a simple system with 2 levels and an extension level that was visually different. Because of platform constraints we could not use modal screens, so we opted for a back button approach instead.
We ran lab studies to verify our proposition. We found that if the main categories and page names were distinct enough from each other, all users could locate any setting within 2 clicks and scrolling the window. The exact names of categories wasn’t that important as long as the names were conceptually different from each other.
This was the breakthrough we had been looking for. We had a model that could scale to handle all of the settings. The model was touch-friendly and compliant with system constraints. The predictable “2 levels plus” navigation was seen as a competitive advantage over iOS, as settings were organized and bounded. The depth of the system was predictable.
ELABORATION
Now that we had a model, the gargantuan task of moving all of the settings into the model was upon us. This made the elaboration phase unique in many ways:
The bulk of the settings pages would be designed by Program Managers, not a designer. Therefore, templates, tools and guidance needed to be in place.
The navigation framework, styles and control set would need to be ready when the page designs arrived. This meant that the bulk of basic UI design and development needed to happen before the pages were elaborated.
Multiple teams would be involved in delivering pages, so there was a need for UX oversight to ensure overall quality and consistency.
BUILDING THE FRAMEWORK
Getting a jump on things, I partnered with a developer to get the navigation system and the control set constructed. Everything was designed to be roughly interchangeable with sizing and spacing meant to snap to the layout grid.
LEGOS FOR EVERYONE
To expedite the design of the settings pages across teams, I created a wireframe toolkit in PowerPoint. The toolkit had guides and pre-made "lego blocks" that corresponded to the controls and their inherent spacing. To design a page, a Program Manager just needed to select sppropriate lego blocks and stack them on top of each other in one column. Once the lego blocks were in place, the bounding outlines could be removed, revealing how the page would look when assembled. The beauty of this approach was that no redlines were needed for the most part.
UX QUALITY CONTROL
Now that the system was largely built and the page designs were coming in, we needed a process to ensure consistency and UX quality.
I set up twice-weekly review meetings. At first they were 4 hours each, with one hour per team to present work. The core Settings team would review all of the pages the various PMs had constructed, give UI guidance, and identify additional needs.
CONSTRUCTION
Given that the bulk of the system had been constructed early in the elaboration phase, the construction phase was mostly about build testing, UX polish and constructing custom controls and elements. The twice-weekly UX review meetings tapered off until we were just left with performance-related bugs.
DELIVERY
The Settings app was delivered fully and on time. While delivery is to be expected with any project, the sheer scope of the project and the brief schedule could easily have led to failure. It was a lesson to me that the conceptual techniques we learn as UX designers are not just artsy daydreaming — They can actually lead to breakthroughs that can transform a whole project.
ADDENDUM: WINDOWS 10
After the release of Windows 8.1, the Windows team was re-organized and merged with the Windows Phone team. The main focus of Windows 10 was continuing the evolution of the Metro design language while merging concepts between the PC and the phone.
Part of the overall effort was rationalizing the in-box apps from the phone and the PC into single “universal apps” that felt like the same app, regardless of form factor.
Late into the first milestone management decided that Settings needed to be a universal app. Given my experience leading the effort in Windows 8.1 I agreed to take on the same in Windows 10. I took the lessons I learned from WIndows 8.1 and applied the same methodology. Even though there were far more settings to rationalize, we were able to get the app in a relatively stable state before most other apps in the system.
