Designing at scale
You might well have heard people mention the phrase designing at scale, but what does this concept actually mean? I was recently interviewed on this topic by Tom Waterton, along with one of my Design Leads, the talented Esteban Pérez-Hemminger, so thought I’d share the discussion here.
The enterprise software context
Tom: Hi both. So, we’re talking about designing at scale today. Arin, you’re one of the execs at one of the largest design organizations in the world. Is designing at scale really just about running larger projects with more designers involved?
Arin: Obviously there is a big difference between having three or four designers working together and having hundreds working across dozens of projects. However, designing at scale is not just about having more people. In the enterprise software context, where IBM operates, there are several distinct challenges that all have an impact on the design work that we do.
Generally, we’re designing products for problem spaces that are inherently complex and which oftentimes will be used in conjunction with a variety of other products.
Tom: Okay, so your designers are having to think through how a given product experience fits within the overall set of products that your customers will typically combine. What else?
Esteban: In addition to these integration challenges, there’s the fact that our products typically need to support multiple users per instance, with those users often spread across different roles, each with different levels of access, etc. So we’re usually not just designing a solution for one persona but for three or four distinct personas who each have different goals and priorities. Getting the experience right for each different type of user is another key design challenge for us.
Arin: Furthermore, our products often need to support vast workloads and this itself can greatly impact the design work. It’s a very different task designing a UI that will support not just 10 or 100 records, but potentially 10,000 or 1,000,000 records.
Then there are the additional expectations and requirements that come with enterprise software, e.g. enhanced security and stability needs; support for industry-specific protocols and data formats; compliance with accessibility and globalization requirements, etc.
Tom: Given all this, I can see how challenging it must be to deliver a simple, intuitive user experience when it comes to enterprise software products.
Esteban: Right. Really nailing the design of even a small consumer app or website takes skill, but when you add in all these additional factors inherent to creating enterprise-grade products it does significantly increase the complexity of our design briefs.
Arin: Thankfully, I think that most people who choose to work in the enterprise software context often do so partly because they actively want to work on challenging problems — ones that haven’t necessarily been solved hundreds of times before. It reminds me of a Jared Spool quote:
“Great designers don’t fall in love with their solutions.
Great designers fall in love with the users’ problems.”
I think there’s a lot of truth in this.
Having a common design framework and set of tools
Tom: You’ve mentioned some of the unique challenges of designing within the enterprise software realm. What are some of the things that you’ve found have helped you successfully design at scale?
Arin: When you move from designing for one or two standalone products to scaling the design across a portfolio — or portfolios — of products then having a tried-and-tested and well communicated approach is essential. Here at IBM we all benefit hugely from having the IBM Design Thinking framework, which provides clear guidance on how to approach complex problems and contains various techniques and exercises to help multi-disciplinary teams explore possible solutions.
A key point to note here is that in order for us to be able to scale design across such a large organization and set of products, it’s been imperative for the whole of IBM — not just those who work in Design — to adopt IBM Design Thinking as the way in which we all approach new opportunities and projects.
Esteban: I agree. The fact that all IBM designers plus many product managers and engineers now share this common language and approach to tackling a given problem space means that we can all move forward together much more quickly.
Tom: So design thinking helps provide a practical, creative approach to tackling problems that anyone can use. What is there to help designers as they go about their day-to-day design work?
Esteban: We have a shared design system (IBM Design Language), which contains our design principles, guidelines, and assets relating to color, typography, iconography, interaction behavior, etc. This has also been critical in helping us scale design work as it means that individual designers don’t have to reinvent common components and standards but can instead jump straight into exploring the specific design challenges of their project.
Arin: Yes, crucially, the IBM Design Language still allows individual designers and design teams plenty of room to use their creativity and flair — which is evident from the award-winning product design work we’ve been delivering recently — but there is also enough definition and direction to keep a base level of consistency so that whatever we produce looks and feels like an IBM product.
Tom: So you have shared design assets and guidance. Do you also standardize on common design tools?
Arin: Yes, at a very practical level, having all your designers use consistent kit (MacBooks) and design tools (Adobe Creative Cloud, Sketch, etc.) helps them share resources and artifacts more quickly and easily. Likewise, having the broader product team (designers, product managers, engineers, etc.) all use the same collaboration tool (Slack), code repository (GitHub), and file sharing platform (Box) also greatly helps us design, communicate, build, and deliver at speed and scale.
Getting the design scope right
Tom: Esteban, as a Design Lead, what other things have you and your team learned with regard to designing at scale?
Esteban: I think that getting the scope of each delivery right is key. Now, I’ll immediately admit that this is a huge challenge as there is always more that you could do in terms of the user experience and more features that could be delivered, but there is also much to be said for delivering something of value to the market quickly. When we do scope things in such a way as to be able to deliver new function quickly, our users see that progress is being made on the product, they get to try out new capability, plus we get the valuable opportunity to seek feedback on the components that were delivered.
Tom: So you intentionally scope your design in such a way to be able to deliver little and often?
Esteban: Well, obviously there is a balance to be struck here, as if the scope of what you deliver is too small, your target users will not receive a sufficient experience to make a tangible difference to the way they work, but if the scope is too big, you’re likely to take way too long to deliver and will miss the opportunity to learn from the more regular feedback loops.
Arin: Right, which is another reminder of the vital role of user research. It really is so crucial that our design teams are constantly exposed to quality user research because if we don’t prioritize the right things it usually comes back to bite us in the end. So, as a professional design unit, the onus is on us to test out our ideas and hypotheses by carrying out ongoing user research, then using our findings to present a strong design direction with clarity about the impact that delivering (or not delivering) certain experiences is likely to have on our target users. Without proper user research, we are just working off assumptions.
One final thought on this: like anything else in design, we should never view our project scope, plan, backlog, etc. as final. Yes, as we work on a project we will make decisions and will set various markers in the sand, but we should re-evaluate all such things as we move forward and learn new insights and never be afraid to change previous decisions if necessary.
Keeping one eye on the future
Tom: There are always new design and technology fads coming and going. How does this impact the design work that you do?
Arin: With enterprise software, we’re typically designing products for the long-term — products that will be used by other businesses and organizations for years and years to come. So while keeping one eye firmly fixed on the current stage of a given project, we must also learn to keep an eye on what might be coming further down the line. This includes product-specific needs and requirements, but also design and technology trends. Again, having a mature design system helps to a certain extent here.
Tom: It certainly sounds like your designers have a lot to consider!
Arin: For sure. Designing at scale for us involves moving faster, providing reusable solutions that can work across multiple contexts, having access to professional user research competencies, and also trying to provide future-proof designs, as far as we are able to. It’s a lot to ask, but it’s also part of what makes designing within the enterprise software context so exciting.
Esteban: In my experience as a Design Lead, it certainly takes a whole mix of talent, vision, passion, and team-work to successfully design at speed and scale. We’ve had some great successes but we’re still very much on the journey, learning from each and every design, prototype, and research engagement.
Designing for the enterprise at scale requires due diligence of people, practice, process and mindset. It is an arduous, but rewarding journey in the pursuit of excellence in how we work and deliver meaningful outcomes — consistently, repeatedly and at the right time.
Arin Bhowmick (@arinbhowmick) is Vice President, Design at IBM based in San Francisco, California. The above article is personal and does not necessarily represent IBM’s positions, strategies or opinions.
