Sketching Solutions

How to Guide Your Team When Design Resources Are Limited

Throughout my career, I’ve gone through periods where there wasn’t a designer on the team—or at least not a full-time one.

So how do you handle that as a team without turning your product into a UX escape room?

Most of the time, things go smoothly if engineering mainly needs to make adjustments to existing pages or build based on patterns already in the product. You expand current features by adding fields, buttons, etc., using similar parts of the UI as inspiration.

But there will be moments—hopefully many—where new pages need to be created or larger UI elements have to be added. And how often have you been in that situation? You’re in a refinement session, there’s a lot of discussion about possible solutions, and your spidey-sense starts tingling. Old memories surface, you’re having flashbacks to that one feature where everyone thought they were aligned—until the devs built a beautiful but completely unexpected non-useable surprise. The person I’m angry at that moment is always myself. How could I have failed to support them in understanding the user’s situation.

So how do you walk the tightrope of giving your team the freedom to define solutions, while still guiding things in the right direction? My two go-to methods:

Simple sketch we’ve made during a refinement

So how do you get started?

I began with a wireframing tool, which helped me learn some best practices and common used wireframe components. But wireframing entire pages can be time-consuming. That’s why I’ve recently gone back to sketching—on paper or a tablet. It’s quicker and keeps you from going down a rabbit hole of creating high-fidelity mockups too early.

That said, sketching isn’t always the answer. I avoid sketching if the solution involves a major overhaul with multiple iterations. In those cases, a more detailed design in Figma or other tool is worth the time.

One last thing: Let your team solve stuff themselves

I don’t sketch or design every change, and that’s by design. Why? Because I encourage engineers to define and build solutions on their own.

I want them to solve problems based on their understanding of the user’s needs. That way, they become creative problem solvers—not just feature machines. (Think: missionaries vs. mercenaries.)
I don’t want to be the bottleneck. I’ve seen teams delay shipping because they’re waiting on the PM to write the perfect requirements document, validate a design, review specs, test the feature, and give some final yay or nay. No thanks.

I try to make myself—and others—replaceable by equipping the team with enough context, trust, and tools to get from problem definition to release. Autonomy is the goal. Alignment is the superpower.