Settings Interface

Framing the Problem

Our capstone client, Project Jupyter, was looking to update the settings experience on their flagship dev environment software, JupyterLab. The existing experience required users to modify their own copy of a settings.json file which the team felt was complicated, inefficient, and created roadblocks for UX initiatives. They requested a visual settings interface that was intuitive, efficient, and extensible.

Team Structure

Given my experience as a Product Design Lead in corporate, our capstone team decided I’d lead design efforts with two team members as direct reports.

Strategizing and Organizing the Work

I began by authoring two documents to organize design team's work.

Project Design Strategy - a high level project agenda whose audience included design, research, product management, and faculty (for visibility reasons). It was a home for design preparation activities - ensuring the designers were set up for success from a technical standpoint (software and permissions) as well as from a knowledge standpoint (research, product, and client artifacts). It was also home for a detailed milestone roadmap that all stakeholders had participated in creating. Please feel free to review a PDF copy here ↗.

Interface Design Strategy - a companion document to Project Design strategy. This document’s primary audience was design team. It included product and feature visions, design principles, milestones, user stories, and most importantly, it acted as a living home to all design feedback as the project progressed. This is also available as a PDF copy here ↗.

Leading Day-to-Day Design Activities

I led the designers through design cycles including team meetings where I delegated user stories and responsibilities, provided design direction, and facilitated peer review. I also mentored the designers on advocating for and defending their design decisions, but I balanced this with guidance on how to constructively consider, process, and negotiate feedback.

Feedback happened in one of 3 ways:

1. preliminary verbal/brainstorm (via Zoom): internal design team zoom calls where we went over assigned user stories
2. formalized written (via Interface Design Strategy google doc): explicit feedback after zoom calls once I'd been able to distill recommendations for each assigned user story
3. collaborative/peer (via Figma): figjam/freeform-esque annotations on our working Figma file

Here's an example of written feedback:

Here's some peer/collaborative:

Over the course of the capstone, Hyeji and Jon nailed their first ever product design project taking it from sketches to wires to final design.

‍
Leading Design Presentation, Stakeholder Communication, and Feedback Rounds

We presented to the broader team at the appropriate junctures. I’d kick off the meetings, but have each designer present their own work and handle questions from the team. I’d jump in only if I detected sufficient jitters or an opinion impasse. I’d capture all feedback and wrap each call with a summary of next steps for designers and stakeholders alike.

Outside of our team meetings, I acted as the design liaison to the extended open-source engineering team who had an ongoing discussion about the initiative on GitHub.

Design Handoff & Post-Ship

Once we reached at the final MVP, I led the designers through documentation and handoff preparation. This included integrating the existing design system and detailing new reusable components for the fields and controls. We handed off the fig file to Project Jupyter’s product manager and staff designer.

Our master’s program ended before the feature was prioritized for development, but was released in 2022 and is now fully available to all JupyterLab users. Additionally, extension developers are successfully integrating their own settings into the centralized settings UI!

‍