Design Process Initiatives
In my time on Windows, I've led several process improvement initiatives on individual teams and across the design studio. This included internal documentation outlining how designers and front-end developers engage, a checklist for stress-testing designs before implementation, and a weekly bug bash for new experiences. I've been a leader in cross-discipline collaboration and a stickler for the nitty-gritty details that save time later in the development process. I've evangelized best practices with both designers and software engineers and enjoy bringing together groups of people to improve processes and working relationships.
One of the efforts I worked hardest on was the “Design Complete Checklist”, a guide for covering all the bases before a design can be considered complete. Each section included a contact person, links to resources and documentation, and a visual example of what success looks like. The document was shopped around within the Windows Design Studio and bought off by design managers. See below for a simplified version.
Design Complete Checklist
Create a great user experience for all conditions
Common controls and patterns
Action: Utilize common controls and patterns.
User benefit: Learn once, use everywhere. States across controls and patterns behave as a family; users learn an interaction and visual language.
Standardization and consistency
Action: Fit within the system unless there’s a justifiable user benefit. Compare visual solutions across the app and product.
User benefit: A consistent viewing experience allows users to focus on tasks and content.
Responsive and adaptive
Action: Test your UI on real devices. Work with your Design Developer to explore solutions in real markup.
User benefit: Our products look good and work well on all devices.
Action: Define primary states as well as edge cases. Follow up with your feature team.
User benefit: Every part of the app looks good and works well.
Action: Define light and dark theme behavior. Think about the application of accent color. Call out exceptions to common theming behavior.
User benefit: The user has a choice and it will still lead to a great experience.
Action: Define high contrast behavior. Think about keyboard accessibility and narrator.
User benefit: Windows is for everyone. Users have options for completing a task that suit their abilities.
Action: Test your UI with long strings and characters with high ascender and low descenders.
User benefit: Windows is for everyone. Non-English speakers can use Windows effectively and feel like it’s for them.
Action: Account for graphic assets in your designs.
User benefit: Asset metaphors are refined, clear, and look beautiful. There’s ample time for them to be vetted and tested.
Action: Think about incoming and outgoing transitions and animation at every level: app-to-app, page-to-page, in-page animations. Define hit targets.
User benefit: Motion teaches the user how to interact with the UI and gives feedback based on input. It helps the user understand where they are in the system and adds a sense of pacing and dimensionality to the experience.
Update the design share
Action: Make sure the latest design is posted. Notify partners of updates.
User benefit: When our partners are well-informed, we can all work toward the same goal.
Action: Make sure partners have what they need. Explore alternate solutions when the original design isn’t possible. Self-host and verify on a range of devices after implementation.
User benefit: We’re aware of the state of the app after hand-off and can react quickly to implementation constraints or user feedback. Users receive an experience that is as design intended.
Action: Account for all previously mentioned items in this list in explicit detail. Discuss buildability with Design Developer, Feature PM, and Dev. Bring your design to shareouts and get manager and design leadership buy off.
User benefit: Sometimes custom UI can present content in its best light. The same standards for our common controls are required for custom UI.