Beyond Best Practices: The Case for Contextual Design Thinking

The Comfort of Best Practices

In design and product development, few phrases carry as much weight as "best practice." It sounds safe, proven, and universal. Something you can rely on when decisions are unclear. Something that's been validated by others — maybe even by the biggest names in the industry.

And sometimes, best practices really are the best path. They save time. They reduce risk. They help align teams quickly. But there's a danger in following them too closely — or too unquestioningly.

Because "best" doesn't mean "perfect." It doesn't mean "permanent." And it definitely doesn't mean "right for your product."

When Best Practices Become Blind Spots

I've seen this pattern repeatedly throughout my career. Teams adopt a "best practice" because it worked for a successful company, only to discover it doesn't fit their context, users, or constraints. The result? A solution that looks right but feels wrong.

I have seen teams follow a pattern from a successful product — only to discover their users value something different (trust, transparency, speed, or simplicity). A direct clone looks familiar, but it misses the real need.

I have also seen dashboard designs copied from the “obvious” market leader, while the actual workflow was different. When the job-to-be-done changes, the best practice becomes a blind spot.

The Contextual Design Approach

Instead of starting with "what's the best practice here?", I start with "what's the real problem we're solving?" This means:

• Understanding your users: Not just demographics, but their actual behaviors, motivations, and constraints
• Analyzing your context: Your technical constraints, business model, competitive landscape, and team capabilities
• Identifying the core problem: What are you really trying to solve, and why does it matter?
• Designing for your reality: Creating solutions that work within your specific context

Learning from Others, Not Copying Them

This doesn't mean ignoring what others have done. Best practices are valuable starting points—they represent proven solutions to common problems. But they should be treated as hypotheses, not gospel.

When I research how other companies solve similar problems, I look for the underlying principles, not the surface-level implementation. What user need were they addressing? What constraints were they working within? How did their solution evolve over time?

"The best practice isn't the one that worked for someone else—it's the one that works for your users, in your context, with your constraints."

Making Contextual Decisions

This approach requires more upfront work. You need to understand your users deeply, analyze your constraints honestly, and be willing to question conventional wisdom. But the results are worth it.

You end up with solutions that feel right because they are right—for your specific situation. Your users get experiences that actually solve their problems. Your team builds confidence in their decision-making process. And you avoid the trap of building something that looks professional but doesn't work.

Embracing the Uncertainty

The uncomfortable truth is that there's no universal "best practice" for most design decisions. The right answer depends on your context. This uncertainty can feel scary, but it's also liberating—it means you have the freedom to find the solution that actually works for your situation.

So the next time someone suggests following a best practice, ask: "What problem was this solving? What context was it designed for? How does that compare to our situation?" You might discover that the best practice is exactly what you need. Or you might discover that you need something completely different.

Either way, you'll be making a decision based on understanding, not just following someone else's playbook.