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.
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.
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.
Almost everything we design needs to be responsive. Responsiveness relies on the parameters given to the interface “system”.
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.
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.
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:
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.
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.
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.
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.
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.
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.