Alyssa Vongries

Settings Management

Designing for phased implementation and breakpoint-conscious responsiveness

A note: This doesn’t represent the entirety of my design process for this project. It doesn't even really address many of the design decisions made. My goal is to highlight two of the concepts I think about while designing, and I'm using this project as a vector.

The Project

Company A is introducing a Settings Management feature to the platform for internal and external users. We need to provide internal and external users with a way to change account-level settings.

  • Internal users (employees of Company A) already have a way of accessing and changing account-level settings for any given account, but they have to leave the platform and access an outside application to do so.
  • External users (customers of Company A) currently have no access to account-level settings.
  • An exhaustive list of feature flags already exists and will need to be replicated in the new settings management experience.
  • New features will be introduced in the future, so the interface has to be designed to accommodate an unknown (possibly large) number of feature flags
  • A “feature preview” section should be introduced so that external users can try new features before they’re officially launched.
  • A “quick settings” section should be designed to present a subset of feature flags without deeper navigation.

Some considerations

  • Platform usage is 95% desktop
  • Company A wants to be device agnostic, but if sacrifices need to be made in the short term, it should be on the smaller versions.
  • Any given external user (customer) is generally only expected to use the platform once or twice a year.
  • The design should follow established/reasonable patterns or be extremely easy to learn.
  • The user shouldn’t be removed from their workflow within the platform to go to settings.

It’s responsive, duh...?

Maximum viewport responsiveness with (less) responsive components

A system of things: using small things to make bigger things

Breakpoint-conscious design: being mindful about what needs to be responsive as screen width changes and what doesn’t.

Why is this important?

Almost everything we design needs to be responsive. Responsiveness relies on the parameters given to the interface “system”.

  • The underlying code provides breakpoints which are natural places for the interface to transition (or not).
  • Components and their variations make up the ecosystem of the design and can be used to address (or not) changing viewport widths without sacrificing function or understanding

While some design tools give the great advantage of auto layout, which makes it much easier to mimic and predict the behavior of interfaces, I still look at the ends of each range to decide when the approach needs to change. This helps me design a more robust system and sometimes allows me to avoid pitfalls.

A system of things

I already knew a fair amount about the content that belonged in the interface. The feature flags had already been chunked into sections and subsections. The feature flags already had titles and descriptions.

  • Optimized for readability and then don’t get wider
  • Using components from the existing design system
  • Designed for all the possible scenarios
Similarity matrix of the card-sort results
Feature flag toggle
Similarity matrix of the card-sort results
Feature flag toggle with a longer title and description
Similarity matrix of the card-sort results
Feature Preview section requires a variation with a launch date
Similarity matrix of the card-sort results
Mobile feature flag toggle at its widest
Similarity matrix of the card-sort results
Mobile feature flag toggle at its narrowest
Settings management form
  • There were a couple of different directions that seemed natural for the overlay
  • I ultimately decided to use two sliding panels, one for the menu and one for the feature flag toggles.
  • We had a rather long list of subsection headings for two of the sections and the full height panel minimizes the need for scrolling through section headings in the menu
Similarity matrix of the card-sort results
The mobile version of the sliding panes allows us to show one panel at a time, giving more screen real estate
User journey for Tessa as she conveys her tattoo idea to he tattoo artist
Higher fidelity mockup of both panels expanded


Once I had the main components outlined, I needed to determine how they should behave at different viewport widths. Fixing the component width can allow better behavior prediction and can result in a more flexible interface.

I look at each breakpoint as a range and design using the smallest and largest widths as a set; they follow the same rules of behavior and use the same versions of the components.  The breakpoints I was working with this are as follows:

  • 992px
  • 768px
  • 640px
  • 320px

992px and up

The largest breakpoint I care about in this case is the 992px. Provided all the accessibility and usability requirements were met, my goal was to make it so that the two panels added together were optimal at 992px, meaning that after we hit that breakpoint, the components no longer need to be responsive at all, they just stay fixed.

640px - 991px

The menu panel is fixed at its optimal width and allows the second panel to responsively resize until it hits its max-width.

You might notice that this range represents two of my so-called sets. I did model both sets, but it turns out that 768px breakpoint doesn’t need to change behavior or component usage. It’s represented here in the middle.

320px - 639px

In these much smaller screens, the menu panel is replaced by the detail panel; they’re never visible at the same time. The menu panel is fixed and if the viewport width drops below 320px, it will become horizontally scrollable. The detail panel is responsive until it hits its maximum width.

Phased Implementation

Delivering incremental value and preparing for the unexpected

Considering that this is a brand new feature, I knew that I’d need to design for an incremental rollout and deliver value as each phase is implemented.

Why is this important?

If development gets interrupted at any point during this feature implementation or rollout, then whatever is already implemented needs to function as a stand-alone.

While setting management is an important utility project, most of it already exists for internal users. This means that it’s likely that other items (bugs, injections, and other higher priority interruptions) could delay this work. I designed discrete phases so that if we needed to, we could shift focus to other work.

The phases were broken up as follows:

Phase 1: Feature Preview section

Phase 2: Feature Preview section + Existing Feature flags

Phase 3: Feature Preview section + Existing Feature flags + Quick Settings section

I designed the last phase first and then backtracked to the initial release.

For phase 1, which would have only included one item on the menu panel, I opted to repurpose the initial menu panel to present the Feature Preview options. Once phase 2 is implemented, the Feature Preview will have its own section heading in the menu and the toggle items will live in the corresponding detail panel.
The 320px - 639px viewport width range would have forced the user to choose one menu item to get to the detail.

User journey for Tessa as she conveys her tattoo idea to he tattoo artist
Phase 1: Preview Feature only
User journey for Tessa as she conveys her tattoo idea to he tattoo artist
Phase 2: Preview Feature section + Existing Feature flags
User journey for Tessa as she conveys her tattoo idea to he tattoo artist
Phase 3: Preview Feature section + Existing Feature flags + Quick Settings section