Have you ever considered how much data there is in a pair of shoes? To sell shoes, you need data for orders, inventory, and point-of-sale systems—including all sizes, styles, and colors. From a software engineer’s perspective, enabling all that data to be input, managed, and shared is complex but straightforward. But for a fashion buyer, that data setup needs to be simple. Because the rest of the job, like any creative process, is fluid and erratic. Anticipating trends several seasons in advance, selecting and ordering the right styles and colors to ensure sales—it’s not a logical, sequential process. And it differs across categories: shoe buyers work differently from buyers of tops, bottoms, accessories, etc.
So, how do you design an interface for collecting and managing all that data that is logical and easy to understand, but still works for all the buyers and doesn’t take time away from their other work? And do it without driving the engineers nuts building a zillion custom interfaces?
So how do you design an interface for collecting and managing all that data that's logical for engineers to build but works for buyers' fluid, varied processes without slowing down their real work?
Sounds like a job for a design workshop. [Smash cut to a designer with trendy glasses, confident expression, cape flowing in the wind.]
In a traditional software requirements gathering process, engineers might interview buyer teams separately, translate their needs into technical requirements, and then spec a solution. But this siloed approach might lead to misalignment and a solution that doesn't fully address the nuanced realities of how different buyers work. Design collaboration that brings diverse stakeholders together with the team designing and building can bring these nuances into focus and help drive toward a solution that addresses them.
Harvard Business Review research found that cognitively diverse teams can solve complex tasks 60% faster than less heterogeneous teams. And interdisciplinary collaboration doesn’t just produce better solutions—it builds empathy and shared ownership that carries through implementation and beyond.
PRINCIPLE #3 Harness diverse perspectives Bring in voices from across disciplines and roles. Value diversity and create a structure that allows everyone to be heard and understood.
On our project, when we brought the buyers, software engineers, and business teams together to collaborate directly, the engineers heard firsthand about the creative chaos of trend forecasting, the buyers gained appreciation for technical constraints, and the finance teams understood both perspectives. And the buyers felt invested, which led to greater trust in the solution they would use every day.
Here’s how I approach facilitating a Design Studio workshop to get a diverse team collaborating on solutions to challenging problems:
Recruit your teams. Find people who have differing perspectives and expertise. Include end-users or customers as well as the business folks, designers, engineers, and developers responsible for solving the problem. Seek out people who may have conflicting interests or opinions. The idea isn’t to generate conflict but to ensure you’ll have diverse perspectives. Assemble your recruits into small teams, with at least one representative from each role—teams of 3 to 5 work best.
Define the problem. Before your workshop, interview everyone you can, especially the people who will be using the solution. Clearly define the problem that the team needs to solve. You can write it as a business problem statement or in another easy-to-consume format.
Write some stories. Craft brief design scenarios based on real-world use cases that demonstrate the needs and challenges of the people who will use the product or service. Include realistic details about constraints, objectives, and context. Use these as conversation starters to get users to share their specific experiences and help the team build empathy.
Share some inspiration. Gather some design stimuli that represent possible approaches to the solution. This can be work-in-progress prototypes, design mockups, or similar products. Whatever gets people thinking about new ways to solve the problem.
Sketch potential solutions. Present your problem definition, design scenarios, and inspiration to the teams. Then have each participant rapidly sketch as many solution ideas as they can in a limited time (6 ideas in 5 minutes is a good goal). Encourage them to ‘yes, and…’ each other’s ideas, identifying what works well and why. Set time limits for presenting and receiving feedback, ensuring everyone has a chance to be heard.
Iterate! Have them sketch again, incorporating the feedback. Encourage them to steal ideas from each other. Aim for two or three iterations. In the last iteration, have each team work together to make one big sketch, paper prototype, or storyboard, and share it with the rest of the room. Let everyone weigh in on what ideas to bring forward to the next phase of work.
Great design thrives at the intersection of disciplines and roles, and successful organizations effectively harness the creative tension between diverse perspectives. The most innovative solutions emerge not despite friction between viewpoints, but because of it, when that friction is channeled productively. The next time you face a complex challenge, look beyond technical skills and deliberately build your team with cognitive diversity. The spark of your breakthrough solution often lies precisely where these different worlds collide.
COMING IN TWO WEEKS:
Principle 4: Prioritize learning over output Okay, so you didn’t make the thing. But did you learn anything?
Thanks for reading Design is a Team Sport! Subscribe for free to receive new posts.
