Forward-Thinking Design Systems

In the chaos of the everyday, it’s often hard to step back and assess whether your organization’s design system is really working. But coming to the realization that it could be better, and then making the decision to change things around— well, that’s overwhelming.

Where should you start? 

The benefits to reevaluating, maintaining, and evolving a design system are straightforward – creating efficiency for your team, consistency for your users, and the ability to scale for your company. However, the organizational impact of a design system is what’s hard to master.

Don’t worry! Grand Studio has a few ways to battle organizational complexity when redesigning, scaling, and maintaining a design system, based on what we’ve learned over the years.

Future-focused decisioning

When reevaluating a design system there are often multiple products and regions to take into consideration. When we redesigned the design system of the world’s largest basketball league our design team was tasked with the challenge of unifying domestic and international digital products across web, app and OTT platforms. Like all design systems, the NBA system had to scale to meet the needs of a number of teams with differing outputs. We ran a design and development audit on the existing products as a way to keep track of styles and components and to understand the context in which these elements are being used. Once we had an understanding of the existing styles and components, future focused decisioning became a key player to fill any gaps and prioritize key components. To build a scalable and sustainable design system your decision making must ensure flexibility, rather than rigidly structured for the needs of a single product. A design system will change, so we should design with product evolution in mind.

Quality and Development

In order to scale, the team needs defined and reliable workflows, including handoffs between design and development. A design system in itself helps facilitate designer-developer collaboration by establishing a common language within the team. So you’d hope this would make handoff smoother, right? When design systems are large and unwieldy they become a challenging tool for disparate product teams. We work to establish a streamlined and precise design system that can deliver a clear and transparent handoff process. Our goal is to edit back and create a single source of truth for multiple products within one system. The best way to create a common language within the design and development team is to explain how components behave and include code samples. This complete explanation goes beyond a set of tooling and creates precise handoffs that are codified in the design system.


To introduce and implement changes within a design system, there’s a need for solid change management. When evolving design systems, we work closely with our partners throughout the design process to not only focus on building consistent user experiences across the entire product suite but to give them the tooling to champion the design changes. We rely on our partners to be internal champions, in order to facilitate buy-in across multiple departments and product teams and to ensure the changes are used properly by all adopters. 

While design systems are essential in developing evolving products that are scalable their frameworks are complex. Simply put, design systems will fail without the commitment to maintain them. Updating your design systems requires focus, commitment and openness to doing things differently. We focus on working with our clients to recreate the fundamental building blocks, the right tooling, and methodology that will create conditions for adoption and scalability.

Want to learn how we help companies build clarity out of complexity?

We’re here to help! 

The Death of Personas

Nearly ten years ago, we were asked by a large financial services company to help their innovation group spread the gospel of human centricity. Over several years and many product design projects, we created dozens of empathy artifacts, most notably several different generations of personas. These personas were beautiful objects with big photos and many personal descriptions of our character’s desires, motivations, and frustrations.

We don’t make personas like that anymore. Back in the day, we needed personas to promote user empathy for our business and product partners. Now, empathy is baked into product management practices generally, and the hard job is understanding how to connect user understanding to long-term product strategy. 

Instead of personas, these days we make more action-oriented user understanding artifacts.

Behavioral Models

Instead of personifying a single user, we describe the intent and/or mental model of classes of users. When we designed experiences for international basketball fans, it was farewell “Julie,” hello “fans who follow players, not teams.” These models discard personal detail in favor of describing their behaviors in relation to our product, and we often end up mapping these models on a 2×2.

Jobs To Be Done

We do a lot of design for professional products, often where there isn’t a choice to use the software; it’s a job requirement. In these cases, personas are completely inappropriate: the personal qualities of any one user are far less important than identifying the users’ JTBD. Once we’ve identified these, we can then classify our users by the similarities and differences in their jobs, which helps us plan and design our software. We find JTBDs pair well with service blueprints where we articulate individual actors’ jobs throughout the service experience, or as individual job maps where the actions can be directly tied to a user’s goal.

Representation Matrices

When we envision or design big enterprise software, there are inevitably users that can be categorized in many ways, including by role, seniority, geography, language, country. A representation matrix helps to identify and organize users across matrix verticals (e.g., “every vendor in Asia”) or horizontals (e.g., “every vendor that supplies raw materials”). This, in turn, helps to identify the user qualities that matter most to our design and product management decisions.

In all cases, these tools are designed to give a strategic output. Rather than helping teams build empathy per se, these are meant to help make hard decisions about what our products should or shouldn’t do. Honestly, making these tools is quite a bit more challenging than making personas. Still, it’s also clear that they better represent the increasingly mature role of HCD in product management and strategy.

Want to learn how we help companies build clarity out of complexity? 

We’re here to help!