Sometimes a Designer just needs to be a little dumb!

Why navigating “spectrums” is an important part of designing and building products.

AI-generated summary of this article:

Navigating spectrums is a central challenge for product designers. Striking the right balance between extremes such as being smart vs. dumb enough, incrementalism vs. big swings, product vision vs. customer voice, and treating everyone as a designer vs. owning the designer role is crucial for creating impactful products. By embracing the nuances and trade-offs inherent in these spectrums, designers can unlock more thoughtful, balanced solutions that combine the best of both extremes. The key is to regularly reflect on where you land on each spectrum, adapt based on the product, team, and goals, and maintain open communication with colleagues. Ultimately, the most effective designers are those who can fluidly navigate these tensions and find the right mindset for each unique challenge.

After about a decade of designing products, I’ve learned that a huge chunk of my role is about finding balance. It’s tempting to latch onto a single design philosophy or approach. For example, I used to think of myself as a “systems-centered” designer who designs with a bias towards informed, incremental bets, rather than partaking in the blue-sky thinking that was popular in the Design community for a time.

In some ways, I hope I do still fit that description … but more often, I find that the real skill is in balancing between methods of working, rather than following tight rules and formulas. In fact, I see teetering smoothly along the spectrum of differing approaches is the most “human” component of our work, in an age where more of our outputs are being codified, automated, and AI’d. In this article, I’ll explore four key spectrums I’ve encountered throughout my career and share some thoughts on striking the right balance for your product and team.

1: Being Smart Enough vs. Dumb Enough

One of the most challenging tightropes for a Product Designer to walk is between knowing a product inside and out and maintaining the fresh perspective of a new user. On the one hand, you need to be “dumb enough” to advocate for the outsider’s point of view — even for arbitrarily simpler solutions—when you’re surrounded by experts who live and breathe the product and tech. If user tests reveal that newcomers are struggling to make sense of your designs or getting tripped up by jargon, it’s a red flag that you might be too deep in the weeds.

I’ve definitely fallen into this trap before. On one project, we spent so much time immersed in the function and operational logic of a feature, that when I put a prototype in front of users, we found ourselves immediately changing the names that we used to approximately describe these features. It was a wake-up call that we needed to zoom out and remember what it’s like to encounter the product for the first time.

On the flip side, designers also need to be “smart enough” to handle complex problems and contribute efficiently. If you find yourself constantly playing catch-up on product knowledge or defaulting to others’ solutions, you might be erring too far on the side of being “dumb.” This can slow down the design process and erode trust with your collaborators.

Striking the right balance means knowing when to challenge assumptions and when to lean on your team’s expertise. I’ve found that openly communicating about my role and thought process helps me partner more effectively with PMs and engineers. Sometimes I’ll say something like, “I know I’m playing the ‘dumb’ card here, but remember that the users don’t consistently think or care about the same things that we do.” Other times, I’ll defer to my teammates’ deep knowledge and ask them to guide me to the most technically feasible solution (so, start designing from the tech rather than inevitably ending up there anyway).

The key is to stay curious and humble, even as you gain mastery over the product. Embrace the beginner’s mindset and keep advocating for simplicity and clarity, but also know when to trust your team and dive into the details.

2. Incrementalism vs. Big Swings

Another common tension designers face is between incrementally improving what’s working, and swinging for the fences with big (but often expensive) bets. It’s especially easy to get caught up in a “grass is always greener” mentality and vacillate between these two extremesf.

Incremental progress has its advantages: it allows you to build on proven successes and show steady forward motion. But if you get too bogged down in small optimizations, you risk ending up with a string of underwhelming releases that fail to move the needle or expand your product’s reach. I’ve worked on teams that fell into the trap of over-incrementing. We’d ship minor UI tweaks and extend existing features, but we found ourselves serving narrower needs and not moving big metrics. Our releases started to feel a bit stale and obscure, and our growth plateaued.

Knowing when to go big is crucial. Stagnant metrics, untapped user needs, and intensifying competition are all signals that it might be time to place some bold bets. But how do you evaluate potential moonshots? Start by pressure-testing the value proposition. Is it grounded in user research, a strong strategic rationale, or a core element of your product vision? Use frameworks like RICE scoring to prioritize based on reach, impact, confidence, and effort.

Be wary of pitfalls like under-investing in ambitious initiatives or disguising incremental work as game-changing innovation. It’s all too easy to slap a big name on a project—been there, done that—that’s really just a bundle of small optimizations. The holy grail is finding ways to make a big impact through incremental releases, but it’s easier said than done. I’ve found a few tips that help get things on the board:

1. If you’re building MVPs or incremental releases against a vision or problem statement, make sure that the early releases show you “signs of life” in positive qualitative (or even quantitative) feedback from your target users. Beware the trap where you keep insisting that “with one more optimization, this feature will start growing.”
2. Big bets always sound … big. Heavy. If the “effort” part gets scary, try to open up those problem statements with your Engineers to see if, indeed, it’s as effortful as you feared (or if there’s another way to approach the problem, with lower technical lift).
3. Get comfortable with owning your vision, and your hypotheses. If a feature sounds too good to be true, and you can build it, it might be worth prototyping it even if you can’t substantiate it with a lot of customer data or research.
4. Remember the value of marketing your features. Big releases will hopefully also drive big growth … but even when they disappoint, they’re great opportunities to talk to your customer base, to make big announcements, and to show that your team is thinking big.

3. Clear Product Vision vs. Customer Voice

Customer-centricity is the north star for many product teams, but an over-reliance on customer feedback can lead to short-term thinking and a lack of momentous vision. The most impactful products strike a balance between a strong opinionated perspective and an awareness of user needs. Without a clear, shared product vision to guide prioritization, teams can easily fall into the trap of implementing a grab bag of disconnected customer requests.

I’ve seen this play out firsthand. At times in my career, I’ve worked on teams that prided themselves on being hyper-responsive to customer feedback. Telling people that your company is customer-centric is one of those lines that everyone wants to say, so it can be hard to push back on being responsive in this way. Anyway, we’d jump on feature requests and pivot based on the latest bit of presumably-value-adding input. But because we sometimes lacked a strong central vision, our backlogs started to feel like a jumbled collection of one-off features. We were checking boxes, but we weren’t delivering opportunities for growth.

To counter an overemphasis on customer voice, rally your team around a vivid aspirational vision of your user’s journey and define your product’s “big picture” purpose. Use these as a rubric for evaluating opportunities and pushing past surface-level asks to uncover deeper user needs. While it’s important to be customer-driven, an opinionated product vision is essential for making tough trade-offs and maintaining a cohesive UX.

Remember, your vision shouldn’t be set in stone — it should evolve based on user insights and market realities. But without a clear point of view to anchor around, you’ll be rudderless in the face of conflicting customer feedback.

4. “Everyone’s a Designer” vs. “I’m the Designer”

Design is (famously, by now) a team sport. Collecting diverse perspectives and fostering co-creation across disciplines is a powerful way to generate solutions. But there’s a crucial balance between treating all colleagues as design collaborators and owning your distinct responsibilities and perspective as “the designer.”

As a designer, my role is often to be a catalyst and curator of great ideas, regardless of their origin. On my teams, it’s important to create space for non-designers to ideate and contribute to the design process. Some of the best solutions I’ve been a part of started as a simple idea from a sales rep, or a quick prototype from an engineer. Cultivating an environment where everyone feels bought in and creatively engaged can lead to more robust, well-rounded products.

However, there inevitably come moments where as the designer, you need to be the one to make the definitive call in order to maintain coherence and forward momentum. This can involve respectfully disagreeing with colleagues and asking for their trust in your design judgement. It’s a delicate balance — you want to foster a sense of collective ownership while still being willing to advocate strongly for what you believe is the right design direction.

The key is to approach these moments with humility and empathy, acknowledging the validity of differing viewpoints while articulating a clear rationale for your proposed path forward. I try to frame it as “disagree and commit” rather than digging in my heels. The goal is not to be the sole arbiter of design truth, but to create alignment around a shared vision so we can move forward confidently as a team. After all, even being “the designer” can’t guarantee that you’ll make the best decisions, it can still ensure that you’re making consistent ones, which has value to your product’s end users.

Another pitfall to avoid is getting so caught up in collaborative design that you shortchange the craft and execution. It’s easy to spend all your time facilitating workshops and soliciting input, but at a certain point, you need to roll up your sleeves and produce polished design solutions. Striking the right balance means carving out dedicated “maker time” to apply your hard-earned design skills while still leaving room for collaboration and iteration with your teammates.

At the end of the day, your unique value as a designer lies in your ability to combine a broad strategic perspective with deep practitioner expertise in interaction design, visual design, and user research. Effective collaboration means knowing when to open the floor and when to make the tough calls that keep everyone aligned and moving forward.

Conclusion

Navigating these spectrums is a Designer’s central challenge, and the root of the role’s bigger opportunities. By embracing the nuances and trade-offs inherent in our work, we can unlock more thoughtful, balanced solutions that combine the best of both extremes. The spectrums I’ve explored here are deeply interconnected and shape almost every aspect of how we approach design challenges.

My advice? Set aside regular time to reflect on where you’re landing on each spectrum and recalibrate based on your product, team, and goals. Have candid discussions with your colleagues about how you can work together to find the right equilibrium. And remember that this is a dynamic, ongoing process — what worked for one project or one stage of growth may need to shift as circumstances change.

Ultimately, the most impactful Designers—and, yeah, often the most “senior” ones—can fluidly navigate these tensions and find the right mindset for the moment. They’re willing to zoom in and out, to balance short-term wins with long-term vision, and to embrace both user empathy and bold original thinking. By becoming more comfortable navigating qualitative spectrums, you’ll be better equipped to design products that are ambitious yet achievable, innovative yet intuitive, visionary yet grounded in real user needs.

👋 Hey again! You just read another AI-assisted article

I’ve been working with AI’s to increase and improve my outputs. My prior pass at this was working with GPT-4 to turn my own notes into an article about the power of AI summaries (especially for platforms set up specifically for reading or dissemination)

Why Substack (and Medium) should introduce AI-assisted summaries

This time, I used Claude 3 Opus to help me put together the article: it’s developed a reputation for more natural-sounding writing (vs. otherwise powerful competitors like GPT-4). Here was my process this time around:

1. Think of the conceptual structure (spectrums), and the types of spectrums within it. (This happened naturally over time, and I started jotting down the spectrums).
2. After considering each, I recorded my own voice and just spoke through all of them, in a train-of-thought ramble about the article, each spectrum, and my desired structure for the whole thing. I have strong feelings on each topic, and was able to simply speak them aloud rather than truly “composing” the article by hand.
3. I ran the recording —it ended up being about 40 minutes—through Notta to transcribe it into written text. I’m hopeful that in the future, I’ll be able to do this directly in the ChatGPT (or Claude) app instead of this 3rd party translation layer.
4. I fed the file to Claude 3 Opus and asked it to help me assemble the article from these rambling notes. I also provided several writing samples from my other articles on the internet, and asked Claude to mimic my voice (to mixed, but some, success).
5. I worked out several versions with Claude, asking for different lengths, structures, and corrections. Honestly, working with Claude I found that often giving the model less structure to work with gave me better results, and allowed the model to work without risking inventing new content (that wasn’t from me).
6. I took my favorite draft and edited it by hand, including some substantial cuts, additions, and rewrites. Honestly, this part took a few more hours than expected, and I’m only barely comfortable with the end result as an example of my ideas, strongly communicated.
7. I generated the accompanying images using DALL-3 via ChatGPT. I usually prefer Midjourney for image creation, but in trying to create a series of images, it was helpful to explain this to ChatGPT, generate revisions, then apply some of my own edits and expansions using Affinity Photo 2.

The results are … positive, but not bulletproof by any means. This is a method I’ll likely try again—honestly, it was pretty fun just speaking aloud to my phone in an unstructured way rather than having to sit down and write an article, like I was writing a college essay again—and I do think it saved me substantial time. But all of the time I saved early (in not having to outline the article) did end up coming back to haunt me in terms of quality loss and editing/writing time at the end. It seems there is still a role for the human in this process, yet.