Crafting Great Experiences Through Design-Focused Delivery
Four years ago, when I first joined Slalom Build, there was a simple belief: Experience-led cross-functional collaboration was the key to successful products and seamless delivery. This desire to break walls was extremely appealing to me. And it rang especially true of our approach to discovery, and served as the foundation to our delivery framework, the Product Engineering Methodology,
As years went by, I started to notice a trend in the development lifecycle. The value of human-centered design was well understood, but as a project progressed, it was often cast aside in favor of fast turnarounds. User validation was constantly seen as lower priority to the next release. It started to become clear we had a human-centric problem, in our human-centered product development world. This impacted not only designers, but the lack of attention to product vision and design principles meant developers were left having to guess the intent behind designs and deal with ambiguous patterns.
Almost in parallel, another trend started to emerge in the industry: A renewed attention to how teams interact and how that can be used to improve process. The concept of DesignOps was born.
According to the Nielsen Norman Group:
DesignOps refers to the orchestration and optimization of people, processes, and craft in order to amplify design’s value and impact at scale.
At Slalom Build, we started to take a deeper look at our delivery methodology, paying close attention to three key areas:
- People: Not only our end-users, but designers, engineers, and stakeholders.
- Systems: The tools, documentation, and structures that enable the work.
- Process: Maximization of efficiencies in workflows and touchpoints.
Beginning with a solid infrastructure
As technology evolves, the gap between design and implementation gets narrower and narrower. With tools like Sketch and Framer, designers need to pay closer attention to the reuse and scalability of their designs. The attention we give to a product’s design system is a reflection of this. Design systems are the foundational component to a successful delivery.
What’s in a system?
- Purpose and Vision: The goal of both the product and the system itself.
- Design Principles: The principles that will guide any design decisions.
- Visual Styles: How the brand emerges, through colors, typography, iconography, etc.
- Components & Patterns: The building blocks that construct a cohesive experience.
- Guidelines: Best practices and direction on how to apply all the elements of the design system.
Above all, a great design system should provide guidance and clarity to the whole team.
Don’t build it alone
As in feature work, a system born out of collaboration between designers, engineers, and stakeholders is very important.
Development should always be part of the design process. Designers and developers working in silos — or even physically separated from each other (in the workplace) — is bad for team culture, as well as the quality and efficiency of the work.
Andrew Couldwell
The partnership between design and development is key in closing the gap between designs and the finished product. After all, documentation that sits stale and isn’t actionable is completely useless. Tools like Storybook and Frontify are helpful in closing those gaps. They serve as a true single source of truth, since the patterns and components that they surface are the actual coded patterns that appear in the product.
Aligning the design process to the development process
New tools like Abstract – a version control tool for designers – allow us to align the design and development process like never before, making conversations between design and engineering more fluid as a result. Inconsistencies are far less frequent, resulting in reduced code complexity for developers to wrangle.
Abstract lets us follow a workflow similar to GitFlow. It allows us to use and share components and patterns in Sketch Libraries as single sources of truth in our designs. As we design new screens we can request reviews from the rest of the team, including developers – a similar process to Pull Request Reviews. This gives the team the opportunity to weigh in and align from a UX and technical perspective. After we address the feedback, we merge screens and components to a master branch that developers can reference. This process reduces any design divergences and ensures a more cohesive design. And a more cohesive design means teams are able to develop product more efficiently, with less code complexity.
For React based projects, Framer X provides an even more powerful alternative. With Framer Bridge, designers can reference production code components when designing in Framer X - a concept pioneered by Airbnb Design’s Painting with Code library for Sketch.
The governance question
Focusing on style guide delivery as the climax is the wrong story to tell. A system isn’t a project with an end, it’s the origin story of a living and evolving product that’ll serve other products.
Nathan Curtis
Think of systems as a product within a product. As the product evolves, so should the system. So how do we invite contribution while maintaining standards?
Separate church and state
Isolating foundational pieces of the system into a separate environments helps enforce more deliberate conversations around changes and iterations to patterns and components. Adding the same rigor to foundational elements as we do with feature work helps us reduce friction and stay true to our principles.
Identify the governing body
Form a team of key decision makers from design, engineering, and the business side. Design decisions should be agreed upon by the whole team and align to priorities and vision.
What delivery integration looks like
Before sprint
- Teams meet to understand functional needs.
- Designers demonstrate the experience using components and patterns from design system.
- The whole team reviews and discusses the experience.
- Designer documents expected behaviors or design nuances in user stories.
During sprint
- Designers work with engineers answering any design questions that may arise during implementation.
- Sit down with engineers to ensure that the stories in-flight meet the design success criteria.
After sprint
- Document any new UI patterns and their guidelines into the existing system.
- Conduct usability testing sessions to gather end-user feedback and opportunities for improvement.
How this improves our sprints
Time for holistic discussions
Having a solid foundation to the design work via a solid design system removes the reliance on mockups as an accessory to user stories. And since long-established patterns and components are no longer a part of the discussion, teams can have more meaningful, holistic discussions around high level topics like business logic, long term vision, and user needs.
Increased velocity
Sometimes speed matters, and a cohesive design system with a codified basis also enables teams to move quicker. Code is less complex and reusable patterns are more easily implemented, while testing efforts become less centered around individual component behavior, dedicating more capacity to complex functional tests.
Scaling with quality and consistency
All that attention put into documentation and process early in a project pays definite dividends in the long run. Stakeholders can be confident that scaling the product portfolio or team makeup won’t come at the expense of quality.
DesignOps as concept is still evolving, but one thing is certain: it’s an exciting new outlook on the designer’s role within the product team. It’s great to see a renewed appetite by the industry for thinking of process as a design problem, looking for ways to make each step more efficient and collaborative.
