When we start working with a new organization on a design system, there’s a lot we don’t know. We need to understand the organization, the product, and the team.
What are they trying to accomplish? What’s getting in the way? What’s working? What isn’t? But there’s a limit to how much you can learn by asking questions. Very quickly, we need to expand our insights to include learning by doing.
With my background in UX and design, this way of working feels familiar. I’ve spent years planning and designing digital products, and one thing continues to prove true: you can learn a lot before you start creating, but you learn something different once you dive in. Exploring a few ideas, trialing them, and adjusting based on what you learn gives you confidence before you commit too heavily to one direction. I see a proof of concept in much the same way.
Two Primary Modes of Learning
Think about learning a new tool. You first might start by reading about it, watching videos, or seeing how someone else uses it. You are a sponge, observing from every angle. But eventually, you shift into a second learning mode, where you open the tool and actually start using it.
In our work at Sparkbox, experience gives us a strong place to start. We can rely on lessons learned from past design system work, but history also tells us there isn’t one approach that works for everyone. Individuals, teams, and organizations all work differently. So we need space for both types of learning: first discussion and observation, and then learning by trying things ourselves. That second mode lets us explore options and start answering questions like: What worked? What didn’t? What needs to change?
A proof of concept helps us move from learning about a problem to learning through solving it. We build on what we think we know by trialing different pieces and parts of the system and seeing what actually happens. These small trials help us learn what works before committing to a larger solution, increasing the odds that what we ultimately build is the right fit
The Point Isn’t Just to Prove that Something Works
The name “proof of concept” can make it sound as though we already have an idea and our job is to demonstrate that it’s correct. In my opinion, that kind of thinking misses the true value. A proof of concept gives us room for trial and error in a smaller, quicker space before we’ve committed too heavily to a single solution.
These smaller, quicker proofs of concept let us trial the solutions we expect might work, but just as importantly, they uncover blockers no one saw coming. No matter how much you whiteboard, there are some issues you simply can’t see until you start building. Just like a “fresh set of eyes” can help when reviewing a product, a proof of concept gives our team a different view of the system and helps us catch larger, hidden issues before we build on top of them. The last thing we want is to keep adding more baggage to a system when there’s a foundational issue that needs to be addressed first.
Once those issues are uncovered, we can quickly iterate and adjust. We all know the saying, “we learn more from our mistakes than we do from our successes,” and that idea is foundational to learning through a proof of concept. Sure, we can create perfectly curated components and assets, but if they’re difficult to use and update, we may have just shifted the problem instead of solving it.
A proof of concept gives us room for trial and error in a smaller, quicker space before we’ve committed too heavily to a single solution.
A Proof of Concept Should be the Right Size
Not every proof of concept needs to be a big undertaking, and in our experience, many aren’t. Maybe an existing design system is fundamentally sound, but the team is struggling with one piece of it. Great! Let’s look at that piece.
Another organization may have tried repeatedly to make its system work and realized the foundation itself needs to change. Now we have more to explore and a few assumptions to test as we consider a new setup.
We also increasingly hear from teams that their design system needs to evolve to support AI or agentic workflows. Maybe they have an approach in place that isn’t working effectively, or they’re still figuring out what that approach should be. In that case, we can explore different options within the company’s approved toolsets before committing to a larger solution.
The important thing is to right-size the work to what we actually need to learn. We’re big believers in not overdoing something when a smaller effort can move the work forward. A proof of concept should give us enough room to learn without becoming a giant exercise simply because somebody put “proof of concept” on the project plan.
What if We Don’t Have Time?
Sometimes the need for progress feels too urgent for any discovery or proof of concept, and we understand that. We have been there. Proof of concepts, or any kind of experimentation, can sound slow and, frankly, expensive.
But skipping a proof of concept doesn’t eliminate risk. It just changes where the risk occurs. There are things we aren’t going to know until we start trying, including which ideas work and which blockers we haven’t discovered yet. If we uncover those things during a proof of concept, we can build on our successes or change direction while the investment is still relatively small. If we uncover them while building the full solution, changing direction can mean undoing work, rebuilding, and involving a whole lot more people.
That background in UX is probably also why I think about the power of a proof of concept much like user testing. We can use experience, research, and best practices to make educated decisions about a product, but eventually, we need to put something into practice and see what happens.
We don’t user test because we expect everything to be wrong. We test because finding the things that are blockers early gives us room to adjust. A proof of concept gives us that same opportunity. We spend time learning early so we can move into the larger investment with more confidence.
Removing experimentation or testing doesn’t remove the possibility of failure. But it can make failure a whole lot more expensive.
Removing experimentation or testing doesn't remove the possibility of failure.
Leave Room for the Plan to Change
There’s one more reason I like creating space for experimentation, which is that it changes how team members provide feedback. In our experience, individuals behave differently when they know something isn’t set in stone and they are helping craft the final solution. When we say, “We’re trying this, and we would love your thoughts,” folks are more willing to question it, challenge assumptions, and offer new ideas. If we say “review this new solution or direction,” the conversation can quickly narrow to feedback on the solution in front of them.
A solid proof of concept helps us move into the next phase of a system with more confidence because we’ve learned enough to choose the next direction thoughtfully. We’ve tested our assumptions against real work. And, maybe most importantly, we haven’t made being wrong a disaster. We’ve made it part of how we get to something better.
