Design as the Search for Less Wrong
Design as the Search for Less Wrong
Why Good Design Is Relative to Paradigm, Context, Time, and Culture
Summary
I have been designing for five years. Across five countries. For millions of users. Building products that millions of people depend on for financial access. And the most important lesson I've learned is not a design principle. It's a philosophical principle: there is no objective good design. There is only less wrong design for right now.
This is not cynicism. This is profound clarity.
When you spend five years shipping products, presenting them to different stakeholders, watching them fail and succeed, iterating based on context changes, you discover something the design textbooks never tell you: design success is not universal. It's paradigm-specific. It's time-specific. It's culture-specific. It's stakeholder-specific.
And that specificity is not a limitation of design. It's the truth of design.
In this essay, I want to explore what I've learned about why "good design" doesn't exist as a universal concept. I want to show how design operates the same way Thomas Kuhn described science operating—through competing paradigms that are fundamentally incommensurable with each other. I want to explain why cultural relativism isn't a trendy design philosophy but a necessary epistemology if you want to design across contexts. And most importantly, I want to show why accepting that there's no perfect design—only less wrong design—is liberation, not failure.
Design Paradigms
Thomas Kuhn did something radical in 1962 that completely changed how we understand knowledge itself. In "The Structure of Scientific Revolutions," he argued that science does not progress gradually toward truth through careful accumulation of facts. Instead, science operates through dominant paradigms—complete frameworks of assumptions, methods, and values that define what counts as a valid question and what counts as a valid answer.
Thomas Kuhn argued that science does not evolve gradually toward truth. Science has a paradigm that remains constant before going through a paradigm shift when current theories can't explain some phenomenon, and someone proposes a new theory.
Kuhn's framework applies perfectly to design.
For decades, design operated under a dominant paradigm that I'll call the Modernist Efficiency Paradigm. This paradigm valued:
Minimalism (less is more)
Universality (design principles apply everywhere)
Functionality (form follows function)
Rationality (users are logical decision-makers)
Innovation (new is better than old)
This paradigm was established by Bauhaus in the 1920s, reinforced by Swiss Modernism in the 1950s, and exported globally through design education, corporate culture, and tech industry adoption. By the 2010s, this paradigm dominated: Apple's design, Google's design, every design textbook, every bootcamp.
Under this paradigm, "good design" meant clean interfaces, white space, sans-serif fonts, minimal color palettes, and fast interactions. This was presented as universal truth. Objective. The right way.
But in 2015-2020, something shifted. Designers in Africa, designers in India, designers in Southeast Asia, designers serving low-income communities everywhere began to notice: this paradigm doesn't work for our users. The assumptions embedded in Modernist Efficiency weren't universal—they were Western, they were assumption-laden, and they actively harmed users in other contexts.
This wasn't a gradual refinement of the Modernist Efficiency Paradigm. This was a crisis. A crisis in science arises when confidence is lost in the ability of the paradigm to solve particularly worrying puzzles called 'anomalies'. Crisis is followed by a scientific revolution if the existing paradigm is superseded by a rival.
Design experienced anomalies:
Minimalist interfaces that confused users with oral communication traditions
Whitespace that felt wasteful in markets where bandwidth cost money
Sans-serif fonts that didn't work with non-Latin scripts
Speed-optimized flows that sacrificed trustworthiness for users who'd been defrauded
Innovation-focused design that abandoned users still dependent on legacy systems
The paradigm couldn't explain why its own "universal principles" failed locally.
The Incommensurability of Design Paradigms
Now here's where Kuhn's most controversial idea applies to design directly: According to Kuhn, the scientific paradigms preceding and succeeding a paradigm shift are so different that their theories are incommensurable—the new paradigm cannot be proven or disproven by the rules of the old paradigm, and vice versa.
Let me be very concrete. Take a specific design choice: whitespace.
In the Modernist Efficiency Paradigm: Whitespace is virtue. It reduces cognitive load. It's clean. Professional. Modern. Data shows that more whitespace improves usability metrics in testing with educated users with fast internet on high-end devices.
In the Context-Specific Paradigm (the emerging paradigm): Whitespace is wasteful. It's emptiness. It suggests the product is unfinished. It doesn't respect the user's time or data costs. Users in Kenya spending money per megabyte don't want empty space. They want density. Data shows that information-dense interfaces improve usability metrics in testing with first-time users with slow internet on basic devices.
Now here's the key: these two paradigms cannot argue with each other on their own terms. The Modernist says "Our testing data shows whitespace helps." The Context-Specific designer says "Our testing data shows density helps." Both are right, within their paradigm. But the paradigms are incommensurable. There's no neutral ground to judge which is "objectively" better because the testing conditions, the users, the devices, the assumptions are all different.
Kuhn suggested that truth is always relative to a particular paradigm. What is "true" within one framework might be nonsensical or false within another.
This is why you can't win a design argument by appealing to universal principles. Both designers are right. They're just operating in different paradigms with different valid truths.
The Resistance to Paradigm Shift in Design
Kuhn made another observation that's eerily applicable to design: According to Max Planck, "a new scientific truth does not triumph by convincing its opponents and making them see the light, but rather because its opponents eventually die, and a new generation grows up that is familiar with it." Because scientists are committed to the dominant paradigm, and paradigm shifts involve gestalt-like changes, Kuhn stresses that paradigms are difficult to change.
In design, this resistance is visible right now. Designers trained in Bauhaus principles, who've built successful careers on Modernist Efficiency, resist the emerging Context-Specific Paradigm. They'll say things like: "That design looks cluttered." "You're adding unnecessary steps." "Users want simplicity."
These aren't wrong observations. They're paradigm-bound observations. They're looking at design through the lens of Modernist Efficiency and seeing violations. But they're not seeing the lens itself.
The shift happens slowly. Younger designers grow up in a world where design must work for people with 2G internet, where whitespace means wasted data, where density means trust signals visible. For them, the Context-Specific Paradigm feels natural. For them, minimalism looks like negligence.
Over time, the paradigm shifts. Not because someone proved the new paradigm objectively better, but because enough people started living in it that it became normal.
Cultural Relativity in Design
What Cultural Relativism Actually Means (Not What You Think It Means)
Most designers misunderstand cultural relativism. They think it means "all perspectives are equally valid and we shouldn't judge." That's not what it means.
Cultural relativism is a methodological position: understanding beliefs and values within the cultural context that produced them, rather than judging them by the standards of another culture. It's not moral relativism (anything goes). It's epistemological relativism (how you know something is true depends on the framework you're using to evaluate truth).
People categorize, and thus experience, the world differently depending on their cultural and linguistic frameworks. Language is a means of categorizing experiences, and the existence of different languages suggests that people categorize and thus experience life differently.
Let me make this concrete in fintech. When you design payment flows, you're designing within a cultural framework that has assumptions about:
What money is
Who should have access to it
How trustworthy institutions are
What transparency looks like
How decisions should be made (individually or collectively)
What failure means
In a Western, individualistic, high-trust-in-institutions culture, a payment flow might be:
User selects payment method (individual choice)
System processes payment (trusting institution)
Confirmation sent via email (institution's word is sufficient)
This design assumes: the user wants choice, they trust the institution, they're comfortable with asynchronous confirmation, email is sufficient proof.
In a context with different cultural frameworks—collective decision-making, lower trust in institutions, need for synchronous confirmation, preference for agent verification—this exact same flow fails because the cultural assumptions are violated.
This isn't a design failure. This is a paradigm mismatch. The design was less wrong for one culture and more wrong for another.
How Different Cultures Define "Good Design"
Here's what I learned designing across Kenya, Nigeria, Uganda, Ghana: different cultures have different aesthetic and functional values, and these aren't shallow preferences—they're deep epistemological differences.
In Kenya, good design means:
Visible trust signals (agent logos, regulatory badges, payment methods visible)
Information density (respect for users' time and data costs)
Agent integration (design acknowledges that systems work through humans)
Redundancy (offline and online modes)
This isn't "less sophisticated" than Western minimalism. It's more sophisticated—it accounts for actual constraints and trust patterns that Western design ignores.
In Nigeria, good design means similar things but with different emphasis:
Payment flexibility (multiple methods because fragmentation is real)
Community integration (design for group decision-making, not just individuals)
Loyalty programs and incentives (because trust must be earned continuously)
Visual richness (colors, patterns that reference cultural traditions)
In rural Kenya or Nigeria, good design means:
USSD support (for basic phones)
Low data usage
Visible progress indicators (users tracking state of their transaction in real-time)
Agent touchpoints (design acknowledges that some humans need help from other humans)
These aren't different levels of the same thing. They're different frameworks for what design solves. Western design solves "how do we make interaction frictionless?" African design solves "how do we make systems trustworthy and accessible given our constraints?"
Both are valid. They're just not comparable on the same dimensions.
The Epistemology of "Good Design" Varies by Culture
Here's what I've realized: what counts as evidence for "good design" is culturally determined.
In Silicon Valley, good design is evidenced by:
User testing metrics (time on task, error rates)
A/B testing data (conversion rates)
NPS scores (would users recommend it?)
Aesthetic awards
In African contexts, good design is evidenced by:
Actual usage patterns (is the product still being used months later?)
Agent feedback (are middlemen saying users understand the system?)
Financial metrics (are users moving more money? more frequently?)
Community trust (are users telling friends to use it?)
Notice the difference. Silicon Valley tests design in laboratories. Africa measures design in actual economic life. Silicon Valley measures intention to use. Africa measures actual continued use.
Both methods are valid. They just prioritize different evidence.
When I show a design to a Silicon Valley designer and say "Look, users kept this product for six months," they ask "But what are the engagement metrics?" When I show a design to a Kenyan agent and say "Look, our engagement metrics improved 20%," they ask "But do customers actually make money with this?"
These are both right questions. They're just asking from different frameworks.
Design Is Not Timeless
The Temporal Dimension of Design
Design Is Not Timeless (Even When We Pretend It Is)
Here's something that happens every time I work on an older product: the design that was less wrong five years ago is now more wrong.
This is not because the old design was "bad" and we've discovered "good design." It's because context changed.
Take M-Pesa as an example. In 2007, when M-Pesa launched, the interface was supposed to be complex. Users were first-time phone users. They needed every step explained. The interface showed menus, options, confirmations. Users had to read. Understanding mattered more than speed.
By 2015, that same interface (which hadn't changed much) was still being praised. But not because it was elegant. Because it was trusted. Users who'd used M-Pesa for eight years knew exactly how it worked. The complexity that would confuse a new user was comfort to an existing user.
By 2025, that interface is still largely the same, and it's now iconic. It's not good design because of visual beauty or interaction speed. It's good design because millions of Kenyans have built their financial lives on it, and changing it would break their mental models.
The design didn't improve. Context shifted. The design that was less wrong in 2007 (necessary friction for first-time users) became even more right in 2025 (familiarity for habitual users) without the design changing at all.
This is temporal specificity of design truth.
How User Knowledge Changes Design Evaluation
When you launch a product, users are at baseline knowledge. They don't understand how the system works. Every UI element must communicate. This is when minimal, clear design works best. Users need to understand the system from cold start.
After three months, users have built mental models. They anticipate system behavior. They expect certain patterns. At this point, the design that worked for cold start might feel slow or over-simplified. Users are ready for more density, more power, more options.
After a year, users are experts. They want speed, shortcuts, power. They're frustrated by the guardrails that protected new users. The design must shift.
After five years, users are so habitual that the design becomes invisible. Changes feel wrong, not because they're bad, but because they violate learned behavior.
So which design is "good"? The one for day-one users? Month-three users? Year-one users? Year-five users? All of them are right for their time, and all of them conflict with each other.
This is why iteration isn't a phase. It's the permanent state. You're not trying to reach "good design." You're constantly designing for the current moment, knowing that moment will shift.
Paradigm Shifts in Design Expectations
Kuhn argues that science does not progress in this smooth, linear fashion but instead undergoes radical overhauls called paradigm shifts. If history has shown that even the most established scientific frameworks can be overturned, it raises an intriguing question: which of our current scientific paradigms might one day be seen as outdated or even completely wrong?
Design experiences the same thing. What's considered good design today might be considered wrong tomorrow when context shifts.
Instagram launched with a minimal interface in 2010. Users loved it. It was revolutionary. By 2020, users expected richness, personalization, options. Instagram added Stories, Reels, Feeds, Explore. The minimal interface was now considered boring.
But this wasn't "progress" toward better design. It was paradigm shift. Users' expectations changed. Social media shifted from "share a moment" to "maintain a presence." The design paradigm shifted from minimalist documentation to maximalist curation.
Is today's complex Instagram "better designed" than 2010's minimal Instagram? Only within today's paradigm. In 2010's paradigm, it would be seen as bloated.
This happens constantly in fintech. Ten years ago, security meant passwords. Now it means biometrics. Ten years ago, speed meant reducing steps. Now it means instant results. Ten years ago, trustworthiness meant obscurity. Now it means transparency.
The "good design" changes because the paradigm changes.
The Impossibility of Complete Solutions
Here's what five years taught me that design school never mentioned: you cannot solve a problem in totality.
Every solution trades one problem for another. Every choice sacrifices something. Every design is a series of conscious and unconscious tradeoffs.
Example from retention design: You want to prevent users from abandoning after missing a payment. You design a grace period system: "You missed a payment. Payment due in 3 days before device locks."
Have you solved the retention problem? Partially. You've made it possible for users to recover. But you've created new problems:
Some users see the grace period as weakness. They assume the system is desperate.
Some agents don't know grace periods exist and lock devices anyway.
Users who get grace periods but can't pay by day 3 experience worse failure than if they'd been locked immediately.
You've now created a support burden (users calling asking about grace periods).
So you've solved one problem and created three new ones. Have you made things better overall? Probably yes. But you didn't solve the problem. You rebalanced which problems exist.
This is true for every design decision:
You optimize for speed: You sacrifice trust (quick onboarding without verification feels risky).
You optimize for trust: You sacrifice speed (thorough verification takes time).
You optimize for accessibility: You sometimes sacrifice power (simple interfaces can't express complex options).
You optimize for power: You sacrifice accessibility (complex interfaces are hard to learn).
You optimize for mobile: You sacrifice desktop capabilities.
You optimize for desktop: You sacrifice mobile usability.
There is no design that optimizes for all dimensions equally. There is only design that makes explicit which dimensions you're optimizing for and accepts the consequences.
Understanding Wicked Problems Is Accepting Impossibility
Design works with wicked problems. Wicked problems lack definitive formulations and stopping rules, making solutions subjective rather than absolute, challenging traditional linear models that suggest problems have a clear set of identifiable conditions.
A wicked problem has:
No clear definition (everyone sees the problem differently)
No stopping rule (you never know when you're done)
No optimal solution (you can only make tradeoffs)
Every solution creates new problems
No evaluation of correctness (you judge on values, not truth)
Almost every problem in fintech is wicked:
"How do we serve underbanked users?" Different stakeholders define this differently. Regulators want compliance. Users want accessibility. Companies want profitability.
"How do we prevent fraud?" More verification prevents fraud but increases friction. Less verification increases fraud but improves usability.
"How do we balance growth and sustainability?" Grow fast and burn out resources. Grow slow and lose market share.
With wicked problems, there is no correct solution. There is only navigation of tradeoffs.
The honest designer admits this. Admits that solving one problem creates another. Admits that you're not finding truth but choosing which problems to carry.
Multiplicity of Truth
Each Stakeholder Operates in a Different Paradigm
After five years, I've learned that disagreement between stakeholders isn't because someone is wrong. It's because they're evaluating the design against different criteria, within different paradigms.
When you show a design to different stakeholders, you're showing the same design but they're seeing it through completely different frameworks:
The CEO sees: Does this increase revenue? Will this retain users? Is this competitive?
The customer sees: Does this solve my problem? Is this trustworthy? Can I accomplish my goal?
The engineer sees: Can we ship this? Will it be maintainable? What's the complexity cost?
The compliance officer sees: Does this violate regulations? Is this legal? What's our liability?
The customer support team sees: How many questions will this generate? Will users understand this? What's the support burden?
The marketing team sees: Is this differentiating? Can we message this clearly? Will this help acquisition?
None of these are wrong. They're all legitimate frameworks for evaluating design. They're just not the same framework.
When all stakeholders evaluate a design, you get feedback like this:
CEO: "Great, this should improve conversion."
Customer: "I don't understand how to do X."
Engineer: "This is too complex to ship in two weeks."
Compliance: "This doesn't clearly show the terms."
Support: "Users will definitely ask about this."
Marketing: "We can't message this clearly."
How do you proceed? You don't try to please everyone. You acknowledge the legitimate concerns across paradigms and make intentional tradeoffs.
You might say: "We're optimizing for compliance and customer understanding. We're accepting that this sacrifices engineering speed. We'll take six weeks instead of two. We're accepting that this might generate support questions initially until users understand the flow."
The moment stakeholders understand the tradeoff, agreement happens. Not because everyone's happy. But because everyone understands why the decision was made.
The Paradigm Matrix: How Stakeholders Define Success
I use a simple framework now to manage stakeholder paradigms. For each design, I create a matrix:
Dimension: Speed (time to complete interaction) CEO paradigm: More speed = more conversions Customer paradigm: Some speed, but not at the cost of understanding Engineer paradigm: Minimal speed complexity = easiest to build Compliance paradigm: Speed sacrifices verification completeness Support paradigm: Speed means users don't understand, more support tickets
So on the "speed" dimension, these aren't one shared truth. There are five different truths, all valid within their paradigm, all in tension with each other.
The design must make a choice: How fast should this interaction be? And explicitly state which paradigm we're optimizing for and which we're sacrificing.
When you do this, stakeholder disagreement becomes productive. Instead of "Is this design good?" you're asking "Which stakeholder paradigm are we optimizing for in this moment?"
Humans Vary Over Time
The same human is different tomorrow than today.
A user might be patient on Monday and impatient on Friday. They might value security one month and convenience the next. They might trust institutions this year and distrust them next year based on a single bad experience.
You cannot design for a fixed user because users aren't fixed.
This is especially true in emerging markets where people shift contexts rapidly:
A user might be a merchant paying for inventory one moment and a consumer buying clothes the next.
They might use their smartphone for business in the morning and for entertainment at night.
They might operate in formal systems (bank transfer) one day and informal systems (cash) the next.
The same person in different contexts is a different person.
Humans Vary Over Space
A Kenyan user in Nairobi is different from a Kenyan user in a rural area. Not because they're different people, but because their context is different.
In Nairobi: fast internet, multiple payment options, formal employment, digital-first services. In rural areas: slow internet, limited payment options, agricultural employment, agent-dependent services.
The same person moving from Nairobi to a rural area becomes a different person in terms of how they use technology. Their preferences shift. Their constraints shift. What worked for them in Nairobi breaks in the rural area.
So which design is right? The one for Nairobi users? Rural users? You can't optimize for both equally. You must make tradeoffs.
Some products optimize for urban first: fast loading, minimal steps, digital-first. They fail in rural areas. Some products optimize for rural first: offline capability, agent integration, simple interfaces. They feel slow in urban areas.
Neither is wrong. They're just optimizing for different spaces.
Humans Change, So Design Constantly Shifts
Because humans are not fixed—they change over time and space—design cannot be fixed either.
You ship a design. Users interact with it. They adapt to it. Their preferences shift. The design that was new and confusing becomes familiar and comfortable. But new users find it familiar and comfortable, which means they don't pay attention. The design that worked for month-one users fails for year-five users.
So you iterate. You change the design. Year-five users are happy. But now month-one users are confused again. The design that was optimized for one moment doesn't work for another.
There is no design that's right across all times. There's only design that's less wrong for right now, knowing that "right now" is always shifting.
The Framework
Step 1: Name Your Paradigm
The first step in designing less wrong is admitting: you're designing within a paradigm. You're not making universal design decisions. You're making paradigm-specific decisions.
Ask yourself:
What assumptions am I making about my users?
What cultural context am I designing for?
What time period is this design for (launch? year one? year five)?
What paradigm of "good design" am I operating in?
Be specific. Not "I'm designing for Africans" (too broad, encompasses multiple paradigms). But "I'm designing for first-time digital financial service users in Kenya with 2G internet access earning less than $10/day."
That specificity is where you ground your design.
Step 2: Map Stakeholder Paradigms
For each major stakeholder, identify:
What do they care about?
What evidence counts as success in their paradigm?
What are they willing to sacrifice?
Where do they conflict with other stakeholders?
Create a stakeholder matrix:
Dimension: Mobile usability Regulatory stakeholder: Must comply with accessibility standards Business stakeholder: Should work well on phones (that's where users are) Customer stakeholder: Must be usable with one hand while doing other things Engineer stakeholder: Must be implementable within technical constraints
Now map the conflicts. Regulatory might want full accessibility features (complex). Business wants simplicity. Customer wants one-handed. Engineer wants minimum complexity.
You can't please all. But you can make the tradeoff intentional.
Step 3: Make Explicit Tradeoffs
Don't hide what you're sacrificing. Make it visible.
"We're optimizing for compliance and usability at the cost of engineering speed. We're taking 8 weeks instead of 4 because accessibility features require more development and testing."
"We're optimizing for first-time user understanding at the cost of expert user speed. We're adding extra explanations that experienced users will skip."
"We're optimizing for trust signals at the cost of visual minimalism. We're showing payment methods, regulatory badges, agent logos even though it feels cluttered."
The moment you name the tradeoff, stakeholders understand. They might push back, but not because they misunderstand. They might negotiate, but on solid ground.
Step 4: Design for the Tradeoff
Once you've made the tradeoff explicit, design to serve it.
If you're optimizing for trust, make trust signals prominent. Don't hide them. If you're optimizing for speed, remove every unnecessary step. Don't add it back later. If you're optimizing for accessibility, design for the least able user first. Don't add accessibility as an afterthought.
The design should be evidence of your tradeoff choices.
Step 5: Measure What Actually Matters
Don't measure what's easy to measure. Measure what matters to your tradeoff choice.
If you've optimized for accessibility, don't measure conversion rate (which would favor speed). Measure completion rate among diverse users.
If you've optimized for trust, don't measure interaction speed. Measure retention, repeat usage, user confidence.
If you've optimized for compliance, don't measure user happiness. Measure regulatory compliance, risk reduction, legal defensibility.
Measure what validates your tradeoff choice.
Step 6: Iterate as Context Shifts
Your design was less wrong when you launched it. But context will shift.
Users will change. Regulations will change. Competitors will change. Market will change.
When context shifts significantly, your less-wrong design becomes more wrong. Iterate.
But iterate knowing what you're optimizing for. If context shifted, does your optimization still make sense? Or do you need new tradeoffs?
Design Encodes Power
Every design decision is a sociological decision. It distributes power. It determines who benefits and who doesn't.
A design that requires formal documentation benefits people with documentation. It harms people without. A design that requires English literacy benefits English speakers. It harms others. A design that requires fast internet benefits urban users. It harms rural users.
A designer who claims to be "neutral" is lying. You're always choosing who to serve and who to exclude.
The honest designer admits: "We're optimizing for users with smartphones, internet access, formal education, and English literacy. We're aware this excludes X% of potential users. We're making that tradeoff consciously because our business model requires it."
This is not evil. It's honest.
Society Shapes What's Possible
A design doesn't work in isolation. It works within societal structures.
A design requiring trust in institutions works in societies with trustworthy institutions. It fails in societies where institutions are corrupt. A design requiring collective decision-making works in societies with collective cultures. It fails in individualistic societies. A design requiring formal systems works in formal economies. It fails in informal economies.
You can't design your way out of societal constraints. You can only design within them or against them knowingly.
The best designs I've built acknowledge societal constraints and work within them. They don't pretend the constraints don't exist.
Good Design Supports Societal Values
Different societies have different values. Good design serves those values.
In a society that values community, good design should enable community coordination. In a society that values individual autonomy, good design should enable personal choice. In a society that values efficiency, good design should minimize steps. In a society that values relationships, good design should require human interaction.
These aren't universal. They're societal. And good design is specific to the society it serves.
Accepting Imperfection as Design Maturity
The Liberation of Accepting "Less Wrong"
For the first few years, I designed trying to reach "good design." I iterated trying to improve. I competed trying to be better than other products.
Around year three, something shifted. I stopped trying to find good design and started trying to find less wrong design.
This shift is liberation.
When you stop trying to be perfect, you can admit limitations. You can say "This design serves this segment and this time. It doesn't serve that segment. That's intentional."
When you stop trying to be perfect, you can focus on what matters: solving the problem you set out to solve, for the people you set out to serve, in the time you have.
When you stop trying to be perfect, you can negotiate with stakeholders from a position of honesty instead of defensiveness.
Design Maturity Is Accepting Iteration as Permanent
Immature design practice thinks: "We'll iterate until we reach good design, then we'll stop iterating and the product will be stable."
Mature design practice understands: "We'll iterate because context constantly changes. The product will never be stable. We'll constantly be redesigning for right now."
This is not exhausting. This is clarifying. You're not failing when the design becomes wrong. You're succeeding if you notice it's wrong and iterate.
The Honest Designer Admits
The most experienced designers I know don't claim to know what's best. They claim to understand the tradeoffs and make them intentionally.
They say things like:
"This design serves speed but sacrifices trust. I recommend we trade that off because our market prioritizes speed."
"This design requires a 6-week implementation instead of 2 because I'm optimizing for accessibility. That's the tradeoff I think we should make."
"This design works for urban users but fails for rural users. We can't serve both equally. I recommend we focus on urban first and plan for rural later."
They don't pretend certainty. They present options with clear tradeoffs. They let stakeholders decide if the tradeoffs are acceptable.
This is how you design across paradigms. Not by proving one paradigm superior. But by being transparent about which paradigm you're operating in and what that means.
Conclusion
After five years of designing, shipping, iterating, failing, succeeding, presenting to stakeholders, watching products in the wild, I've learned:
Wicked problems have no stopping rule, as in there's no way to know your solution is final. Solutions to wicked problems are not true-or-false; they can only be good-or-bad.
Design is the search for less wrong solutions to wicked problems in specific contexts at specific times for specific stakeholders operating within specific paradigms.
There is no universal good design. There is only:
Paradigm-specific design (working within a framework of assumptions)
Culture-specific design (serving a particular culture's values and constraints)
Time-specific design (appropriate for this moment, knowing it will shift)
Stakeholder-specific design (acknowledging different truths held by different stakeholders)
Context-specific design (appropriate for these conditions, not universally)
When you accept this, design stops being about finding truth. It becomes about making conscious choices with full knowledge of consequences.
You don't ask "Is this good design?" You ask "Is this less wrong than the alternative for our users in our context at this moment?"
And if context shifts, you don't claim the old design failed. You recognize that less wrong has changed. And you iterate.
This is not resignation. This is maturity. This is honesty. This is design that works because it admits what it can and can't do, and designs accordingly.
References
If you're reading this expecting to learn "principles of good design," I apologize. But I also won't apologize for redirecting you.
The moment you accept that good design doesn't exist only less wrong design for right now—you're ready to design across contexts. You're ready to operate in multiple paradigms. You're ready to manage stakeholder complexity. You're ready to iterate as context changes. You're ready to admit when you don't know and work toward knowing.
That's when design gets interesting. Not because you've found the answer. But because you've stopped looking for one answer and started negotiating between many.
Next
Product-Led Growth in African Fintech
THe description of the title
Product-Led Growth in African Fintech
THe description of the title
Product-Led Growth in African Fintech
THe description of the title
The Retention Pipeline
THe description of the title
The Retention Pipeline
THe description of the title
The Retention Pipeline
THe description of the title
The Convenience Threshold
THe description of the title
The Convenience Threshold
THe description of the title
The Convenience Threshold
THe description of the title
Design as the Search for Less Wrong
Design as the Search for Less Wrong
Design as the Search for Less Wrong
Design as the Search for Less Wrong
Why Good Design Is Relative to Paradigm, Context, Time, and Culture
Summary
I have been designing for five years. Across five countries. For millions of users. Building products that millions of people depend on for financial access. And the most important lesson I've learned is not a design principle. It's a philosophical principle: there is no objective good design. There is only less wrong design for right now.
This is not cynicism. This is profound clarity.
When you spend five years shipping products, presenting them to different stakeholders, watching them fail and succeed, iterating based on context changes, you discover something the design textbooks never tell you: design success is not universal. It's paradigm-specific. It's time-specific. It's culture-specific. It's stakeholder-specific.
And that specificity is not a limitation of design. It's the truth of design.
In this essay, I want to explore what I've learned about why "good design" doesn't exist as a universal concept. I want to show how design operates the same way Thomas Kuhn described science operating—through competing paradigms that are fundamentally incommensurable with each other. I want to explain why cultural relativism isn't a trendy design philosophy but a necessary epistemology if you want to design across contexts. And most importantly, I want to show why accepting that there's no perfect design—only less wrong design—is liberation, not failure.
Design Paradigms
Thomas Kuhn did something radical in 1962 that completely changed how we understand knowledge itself. In "The Structure of Scientific Revolutions," he argued that science does not progress gradually toward truth through careful accumulation of facts. Instead, science operates through dominant paradigms—complete frameworks of assumptions, methods, and values that define what counts as a valid question and what counts as a valid answer.
Thomas Kuhn argued that science does not evolve gradually toward truth. Science has a paradigm that remains constant before going through a paradigm shift when current theories can't explain some phenomenon, and someone proposes a new theory.
Kuhn's framework applies perfectly to design.
For decades, design operated under a dominant paradigm that I'll call the Modernist Efficiency Paradigm. This paradigm valued:
Minimalism (less is more)
Universality (design principles apply everywhere)
Functionality (form follows function)
Rationality (users are logical decision-makers)
Innovation (new is better than old)
This paradigm was established by Bauhaus in the 1920s, reinforced by Swiss Modernism in the 1950s, and exported globally through design education, corporate culture, and tech industry adoption. By the 2010s, this paradigm dominated: Apple's design, Google's design, every design textbook, every bootcamp.
Under this paradigm, "good design" meant clean interfaces, white space, sans-serif fonts, minimal color palettes, and fast interactions. This was presented as universal truth. Objective. The right way.
But in 2015-2020, something shifted. Designers in Africa, designers in India, designers in Southeast Asia, designers serving low-income communities everywhere began to notice: this paradigm doesn't work for our users. The assumptions embedded in Modernist Efficiency weren't universal—they were Western, they were assumption-laden, and they actively harmed users in other contexts.
This wasn't a gradual refinement of the Modernist Efficiency Paradigm. This was a crisis. A crisis in science arises when confidence is lost in the ability of the paradigm to solve particularly worrying puzzles called 'anomalies'. Crisis is followed by a scientific revolution if the existing paradigm is superseded by a rival.
Design experienced anomalies:
Minimalist interfaces that confused users with oral communication traditions
Whitespace that felt wasteful in markets where bandwidth cost money
Sans-serif fonts that didn't work with non-Latin scripts
Speed-optimized flows that sacrificed trustworthiness for users who'd been defrauded
Innovation-focused design that abandoned users still dependent on legacy systems
The paradigm couldn't explain why its own "universal principles" failed locally.
The Incommensurability of Design Paradigms
Now here's where Kuhn's most controversial idea applies to design directly: According to Kuhn, the scientific paradigms preceding and succeeding a paradigm shift are so different that their theories are incommensurable—the new paradigm cannot be proven or disproven by the rules of the old paradigm, and vice versa.
Let me be very concrete. Take a specific design choice: whitespace.
In the Modernist Efficiency Paradigm: Whitespace is virtue. It reduces cognitive load. It's clean. Professional. Modern. Data shows that more whitespace improves usability metrics in testing with educated users with fast internet on high-end devices.
In the Context-Specific Paradigm (the emerging paradigm): Whitespace is wasteful. It's emptiness. It suggests the product is unfinished. It doesn't respect the user's time or data costs. Users in Kenya spending money per megabyte don't want empty space. They want density. Data shows that information-dense interfaces improve usability metrics in testing with first-time users with slow internet on basic devices.
Now here's the key: these two paradigms cannot argue with each other on their own terms. The Modernist says "Our testing data shows whitespace helps." The Context-Specific designer says "Our testing data shows density helps." Both are right, within their paradigm. But the paradigms are incommensurable. There's no neutral ground to judge which is "objectively" better because the testing conditions, the users, the devices, the assumptions are all different.
Kuhn suggested that truth is always relative to a particular paradigm. What is "true" within one framework might be nonsensical or false within another.
This is why you can't win a design argument by appealing to universal principles. Both designers are right. They're just operating in different paradigms with different valid truths.
The Resistance to Paradigm Shift in Design
Kuhn made another observation that's eerily applicable to design: According to Max Planck, "a new scientific truth does not triumph by convincing its opponents and making them see the light, but rather because its opponents eventually die, and a new generation grows up that is familiar with it." Because scientists are committed to the dominant paradigm, and paradigm shifts involve gestalt-like changes, Kuhn stresses that paradigms are difficult to change.
In design, this resistance is visible right now. Designers trained in Bauhaus principles, who've built successful careers on Modernist Efficiency, resist the emerging Context-Specific Paradigm. They'll say things like: "That design looks cluttered." "You're adding unnecessary steps." "Users want simplicity."
These aren't wrong observations. They're paradigm-bound observations. They're looking at design through the lens of Modernist Efficiency and seeing violations. But they're not seeing the lens itself.
The shift happens slowly. Younger designers grow up in a world where design must work for people with 2G internet, where whitespace means wasted data, where density means trust signals visible. For them, the Context-Specific Paradigm feels natural. For them, minimalism looks like negligence.
Over time, the paradigm shifts. Not because someone proved the new paradigm objectively better, but because enough people started living in it that it became normal.
Cultural Relativity in Design
What Cultural Relativism Actually Means (Not What You Think It Means)
Most designers misunderstand cultural relativism. They think it means "all perspectives are equally valid and we shouldn't judge." That's not what it means.
Cultural relativism is a methodological position: understanding beliefs and values within the cultural context that produced them, rather than judging them by the standards of another culture. It's not moral relativism (anything goes). It's epistemological relativism (how you know something is true depends on the framework you're using to evaluate truth).
People categorize, and thus experience, the world differently depending on their cultural and linguistic frameworks. Language is a means of categorizing experiences, and the existence of different languages suggests that people categorize and thus experience life differently.
Let me make this concrete in fintech. When you design payment flows, you're designing within a cultural framework that has assumptions about:
What money is
Who should have access to it
How trustworthy institutions are
What transparency looks like
How decisions should be made (individually or collectively)
What failure means
In a Western, individualistic, high-trust-in-institutions culture, a payment flow might be:
User selects payment method (individual choice)
System processes payment (trusting institution)
Confirmation sent via email (institution's word is sufficient)
This design assumes: the user wants choice, they trust the institution, they're comfortable with asynchronous confirmation, email is sufficient proof.
In a context with different cultural frameworks—collective decision-making, lower trust in institutions, need for synchronous confirmation, preference for agent verification—this exact same flow fails because the cultural assumptions are violated.
This isn't a design failure. This is a paradigm mismatch. The design was less wrong for one culture and more wrong for another.
How Different Cultures Define "Good Design"
Here's what I learned designing across Kenya, Nigeria, Uganda, Ghana: different cultures have different aesthetic and functional values, and these aren't shallow preferences—they're deep epistemological differences.
In Kenya, good design means:
Visible trust signals (agent logos, regulatory badges, payment methods visible)
Information density (respect for users' time and data costs)
Agent integration (design acknowledges that systems work through humans)
Redundancy (offline and online modes)
This isn't "less sophisticated" than Western minimalism. It's more sophisticated—it accounts for actual constraints and trust patterns that Western design ignores.
In Nigeria, good design means similar things but with different emphasis:
Payment flexibility (multiple methods because fragmentation is real)
Community integration (design for group decision-making, not just individuals)
Loyalty programs and incentives (because trust must be earned continuously)
Visual richness (colors, patterns that reference cultural traditions)
In rural Kenya or Nigeria, good design means:
USSD support (for basic phones)
Low data usage
Visible progress indicators (users tracking state of their transaction in real-time)
Agent touchpoints (design acknowledges that some humans need help from other humans)
These aren't different levels of the same thing. They're different frameworks for what design solves. Western design solves "how do we make interaction frictionless?" African design solves "how do we make systems trustworthy and accessible given our constraints?"
Both are valid. They're just not comparable on the same dimensions.
The Epistemology of "Good Design" Varies by Culture
Here's what I've realized: what counts as evidence for "good design" is culturally determined.
In Silicon Valley, good design is evidenced by:
User testing metrics (time on task, error rates)
A/B testing data (conversion rates)
NPS scores (would users recommend it?)
Aesthetic awards
In African contexts, good design is evidenced by:
Actual usage patterns (is the product still being used months later?)
Agent feedback (are middlemen saying users understand the system?)
Financial metrics (are users moving more money? more frequently?)
Community trust (are users telling friends to use it?)
Notice the difference. Silicon Valley tests design in laboratories. Africa measures design in actual economic life. Silicon Valley measures intention to use. Africa measures actual continued use.
Both methods are valid. They just prioritize different evidence.
When I show a design to a Silicon Valley designer and say "Look, users kept this product for six months," they ask "But what are the engagement metrics?" When I show a design to a Kenyan agent and say "Look, our engagement metrics improved 20%," they ask "But do customers actually make money with this?"
These are both right questions. They're just asking from different frameworks.
Design Is Not Timeless
The Temporal Dimension of Design
Design Is Not Timeless (Even When We Pretend It Is)
Here's something that happens every time I work on an older product: the design that was less wrong five years ago is now more wrong.
This is not because the old design was "bad" and we've discovered "good design." It's because context changed.
Take M-Pesa as an example. In 2007, when M-Pesa launched, the interface was supposed to be complex. Users were first-time phone users. They needed every step explained. The interface showed menus, options, confirmations. Users had to read. Understanding mattered more than speed.
By 2015, that same interface (which hadn't changed much) was still being praised. But not because it was elegant. Because it was trusted. Users who'd used M-Pesa for eight years knew exactly how it worked. The complexity that would confuse a new user was comfort to an existing user.
By 2025, that interface is still largely the same, and it's now iconic. It's not good design because of visual beauty or interaction speed. It's good design because millions of Kenyans have built their financial lives on it, and changing it would break their mental models.
The design didn't improve. Context shifted. The design that was less wrong in 2007 (necessary friction for first-time users) became even more right in 2025 (familiarity for habitual users) without the design changing at all.
This is temporal specificity of design truth.
How User Knowledge Changes Design Evaluation
When you launch a product, users are at baseline knowledge. They don't understand how the system works. Every UI element must communicate. This is when minimal, clear design works best. Users need to understand the system from cold start.
After three months, users have built mental models. They anticipate system behavior. They expect certain patterns. At this point, the design that worked for cold start might feel slow or over-simplified. Users are ready for more density, more power, more options.
After a year, users are experts. They want speed, shortcuts, power. They're frustrated by the guardrails that protected new users. The design must shift.
After five years, users are so habitual that the design becomes invisible. Changes feel wrong, not because they're bad, but because they violate learned behavior.
So which design is "good"? The one for day-one users? Month-three users? Year-one users? Year-five users? All of them are right for their time, and all of them conflict with each other.
This is why iteration isn't a phase. It's the permanent state. You're not trying to reach "good design." You're constantly designing for the current moment, knowing that moment will shift.
Paradigm Shifts in Design Expectations
Kuhn argues that science does not progress in this smooth, linear fashion but instead undergoes radical overhauls called paradigm shifts. If history has shown that even the most established scientific frameworks can be overturned, it raises an intriguing question: which of our current scientific paradigms might one day be seen as outdated or even completely wrong?
Design experiences the same thing. What's considered good design today might be considered wrong tomorrow when context shifts.
Instagram launched with a minimal interface in 2010. Users loved it. It was revolutionary. By 2020, users expected richness, personalization, options. Instagram added Stories, Reels, Feeds, Explore. The minimal interface was now considered boring.
But this wasn't "progress" toward better design. It was paradigm shift. Users' expectations changed. Social media shifted from "share a moment" to "maintain a presence." The design paradigm shifted from minimalist documentation to maximalist curation.
Is today's complex Instagram "better designed" than 2010's minimal Instagram? Only within today's paradigm. In 2010's paradigm, it would be seen as bloated.
This happens constantly in fintech. Ten years ago, security meant passwords. Now it means biometrics. Ten years ago, speed meant reducing steps. Now it means instant results. Ten years ago, trustworthiness meant obscurity. Now it means transparency.
The "good design" changes because the paradigm changes.
The Impossibility of Complete Solutions
Here's what five years taught me that design school never mentioned: you cannot solve a problem in totality.
Every solution trades one problem for another. Every choice sacrifices something. Every design is a series of conscious and unconscious tradeoffs.
Example from retention design: You want to prevent users from abandoning after missing a payment. You design a grace period system: "You missed a payment. Payment due in 3 days before device locks."
Have you solved the retention problem? Partially. You've made it possible for users to recover. But you've created new problems:
Some users see the grace period as weakness. They assume the system is desperate.
Some agents don't know grace periods exist and lock devices anyway.
Users who get grace periods but can't pay by day 3 experience worse failure than if they'd been locked immediately.
You've now created a support burden (users calling asking about grace periods).
So you've solved one problem and created three new ones. Have you made things better overall? Probably yes. But you didn't solve the problem. You rebalanced which problems exist.
This is true for every design decision:
You optimize for speed: You sacrifice trust (quick onboarding without verification feels risky).
You optimize for trust: You sacrifice speed (thorough verification takes time).
You optimize for accessibility: You sometimes sacrifice power (simple interfaces can't express complex options).
You optimize for power: You sacrifice accessibility (complex interfaces are hard to learn).
You optimize for mobile: You sacrifice desktop capabilities.
You optimize for desktop: You sacrifice mobile usability.
There is no design that optimizes for all dimensions equally. There is only design that makes explicit which dimensions you're optimizing for and accepts the consequences.
Understanding Wicked Problems Is Accepting Impossibility
Design works with wicked problems. Wicked problems lack definitive formulations and stopping rules, making solutions subjective rather than absolute, challenging traditional linear models that suggest problems have a clear set of identifiable conditions.
A wicked problem has:
No clear definition (everyone sees the problem differently)
No stopping rule (you never know when you're done)
No optimal solution (you can only make tradeoffs)
Every solution creates new problems
No evaluation of correctness (you judge on values, not truth)
Almost every problem in fintech is wicked:
"How do we serve underbanked users?" Different stakeholders define this differently. Regulators want compliance. Users want accessibility. Companies want profitability.
"How do we prevent fraud?" More verification prevents fraud but increases friction. Less verification increases fraud but improves usability.
"How do we balance growth and sustainability?" Grow fast and burn out resources. Grow slow and lose market share.
With wicked problems, there is no correct solution. There is only navigation of tradeoffs.
The honest designer admits this. Admits that solving one problem creates another. Admits that you're not finding truth but choosing which problems to carry.
Multiplicity of Truth
Each Stakeholder Operates in a Different Paradigm
After five years, I've learned that disagreement between stakeholders isn't because someone is wrong. It's because they're evaluating the design against different criteria, within different paradigms.
When you show a design to different stakeholders, you're showing the same design but they're seeing it through completely different frameworks:
The CEO sees: Does this increase revenue? Will this retain users? Is this competitive?
The customer sees: Does this solve my problem? Is this trustworthy? Can I accomplish my goal?
The engineer sees: Can we ship this? Will it be maintainable? What's the complexity cost?
The compliance officer sees: Does this violate regulations? Is this legal? What's our liability?
The customer support team sees: How many questions will this generate? Will users understand this? What's the support burden?
The marketing team sees: Is this differentiating? Can we message this clearly? Will this help acquisition?
None of these are wrong. They're all legitimate frameworks for evaluating design. They're just not the same framework.
When all stakeholders evaluate a design, you get feedback like this:
CEO: "Great, this should improve conversion."
Customer: "I don't understand how to do X."
Engineer: "This is too complex to ship in two weeks."
Compliance: "This doesn't clearly show the terms."
Support: "Users will definitely ask about this."
Marketing: "We can't message this clearly."
How do you proceed? You don't try to please everyone. You acknowledge the legitimate concerns across paradigms and make intentional tradeoffs.
You might say: "We're optimizing for compliance and customer understanding. We're accepting that this sacrifices engineering speed. We'll take six weeks instead of two. We're accepting that this might generate support questions initially until users understand the flow."
The moment stakeholders understand the tradeoff, agreement happens. Not because everyone's happy. But because everyone understands why the decision was made.
The Paradigm Matrix: How Stakeholders Define Success
I use a simple framework now to manage stakeholder paradigms. For each design, I create a matrix:
Dimension: Speed (time to complete interaction) CEO paradigm: More speed = more conversions Customer paradigm: Some speed, but not at the cost of understanding Engineer paradigm: Minimal speed complexity = easiest to build Compliance paradigm: Speed sacrifices verification completeness Support paradigm: Speed means users don't understand, more support tickets
So on the "speed" dimension, these aren't one shared truth. There are five different truths, all valid within their paradigm, all in tension with each other.
The design must make a choice: How fast should this interaction be? And explicitly state which paradigm we're optimizing for and which we're sacrificing.
When you do this, stakeholder disagreement becomes productive. Instead of "Is this design good?" you're asking "Which stakeholder paradigm are we optimizing for in this moment?"
Humans Vary Over Time
The same human is different tomorrow than today.
A user might be patient on Monday and impatient on Friday. They might value security one month and convenience the next. They might trust institutions this year and distrust them next year based on a single bad experience.
You cannot design for a fixed user because users aren't fixed.
This is especially true in emerging markets where people shift contexts rapidly:
A user might be a merchant paying for inventory one moment and a consumer buying clothes the next.
They might use their smartphone for business in the morning and for entertainment at night.
They might operate in formal systems (bank transfer) one day and informal systems (cash) the next.
The same person in different contexts is a different person.
Humans Vary Over Space
A Kenyan user in Nairobi is different from a Kenyan user in a rural area. Not because they're different people, but because their context is different.
In Nairobi: fast internet, multiple payment options, formal employment, digital-first services. In rural areas: slow internet, limited payment options, agricultural employment, agent-dependent services.
The same person moving from Nairobi to a rural area becomes a different person in terms of how they use technology. Their preferences shift. Their constraints shift. What worked for them in Nairobi breaks in the rural area.
So which design is right? The one for Nairobi users? Rural users? You can't optimize for both equally. You must make tradeoffs.
Some products optimize for urban first: fast loading, minimal steps, digital-first. They fail in rural areas. Some products optimize for rural first: offline capability, agent integration, simple interfaces. They feel slow in urban areas.
Neither is wrong. They're just optimizing for different spaces.
Humans Change, So Design Constantly Shifts
Because humans are not fixed—they change over time and space—design cannot be fixed either.
You ship a design. Users interact with it. They adapt to it. Their preferences shift. The design that was new and confusing becomes familiar and comfortable. But new users find it familiar and comfortable, which means they don't pay attention. The design that worked for month-one users fails for year-five users.
So you iterate. You change the design. Year-five users are happy. But now month-one users are confused again. The design that was optimized for one moment doesn't work for another.
There is no design that's right across all times. There's only design that's less wrong for right now, knowing that "right now" is always shifting.
The Framework
Step 1: Name Your Paradigm
The first step in designing less wrong is admitting: you're designing within a paradigm. You're not making universal design decisions. You're making paradigm-specific decisions.
Ask yourself:
What assumptions am I making about my users?
What cultural context am I designing for?
What time period is this design for (launch? year one? year five)?
What paradigm of "good design" am I operating in?
Be specific. Not "I'm designing for Africans" (too broad, encompasses multiple paradigms). But "I'm designing for first-time digital financial service users in Kenya with 2G internet access earning less than $10/day."
That specificity is where you ground your design.
Step 2: Map Stakeholder Paradigms
For each major stakeholder, identify:
What do they care about?
What evidence counts as success in their paradigm?
What are they willing to sacrifice?
Where do they conflict with other stakeholders?
Create a stakeholder matrix:
Dimension: Mobile usability Regulatory stakeholder: Must comply with accessibility standards Business stakeholder: Should work well on phones (that's where users are) Customer stakeholder: Must be usable with one hand while doing other things Engineer stakeholder: Must be implementable within technical constraints
Now map the conflicts. Regulatory might want full accessibility features (complex). Business wants simplicity. Customer wants one-handed. Engineer wants minimum complexity.
You can't please all. But you can make the tradeoff intentional.
Step 3: Make Explicit Tradeoffs
Don't hide what you're sacrificing. Make it visible.
"We're optimizing for compliance and usability at the cost of engineering speed. We're taking 8 weeks instead of 4 because accessibility features require more development and testing."
"We're optimizing for first-time user understanding at the cost of expert user speed. We're adding extra explanations that experienced users will skip."
"We're optimizing for trust signals at the cost of visual minimalism. We're showing payment methods, regulatory badges, agent logos even though it feels cluttered."
The moment you name the tradeoff, stakeholders understand. They might push back, but not because they misunderstand. They might negotiate, but on solid ground.
Step 4: Design for the Tradeoff
Once you've made the tradeoff explicit, design to serve it.
If you're optimizing for trust, make trust signals prominent. Don't hide them. If you're optimizing for speed, remove every unnecessary step. Don't add it back later. If you're optimizing for accessibility, design for the least able user first. Don't add accessibility as an afterthought.
The design should be evidence of your tradeoff choices.
Step 5: Measure What Actually Matters
Don't measure what's easy to measure. Measure what matters to your tradeoff choice.
If you've optimized for accessibility, don't measure conversion rate (which would favor speed). Measure completion rate among diverse users.
If you've optimized for trust, don't measure interaction speed. Measure retention, repeat usage, user confidence.
If you've optimized for compliance, don't measure user happiness. Measure regulatory compliance, risk reduction, legal defensibility.
Measure what validates your tradeoff choice.
Step 6: Iterate as Context Shifts
Your design was less wrong when you launched it. But context will shift.
Users will change. Regulations will change. Competitors will change. Market will change.
When context shifts significantly, your less-wrong design becomes more wrong. Iterate.
But iterate knowing what you're optimizing for. If context shifted, does your optimization still make sense? Or do you need new tradeoffs?
Design Encodes Power
Every design decision is a sociological decision. It distributes power. It determines who benefits and who doesn't.
A design that requires formal documentation benefits people with documentation. It harms people without. A design that requires English literacy benefits English speakers. It harms others. A design that requires fast internet benefits urban users. It harms rural users.
A designer who claims to be "neutral" is lying. You're always choosing who to serve and who to exclude.
The honest designer admits: "We're optimizing for users with smartphones, internet access, formal education, and English literacy. We're aware this excludes X% of potential users. We're making that tradeoff consciously because our business model requires it."
This is not evil. It's honest.
Society Shapes What's Possible
A design doesn't work in isolation. It works within societal structures.
A design requiring trust in institutions works in societies with trustworthy institutions. It fails in societies where institutions are corrupt. A design requiring collective decision-making works in societies with collective cultures. It fails in individualistic societies. A design requiring formal systems works in formal economies. It fails in informal economies.
You can't design your way out of societal constraints. You can only design within them or against them knowingly.
The best designs I've built acknowledge societal constraints and work within them. They don't pretend the constraints don't exist.
Good Design Supports Societal Values
Different societies have different values. Good design serves those values.
In a society that values community, good design should enable community coordination. In a society that values individual autonomy, good design should enable personal choice. In a society that values efficiency, good design should minimize steps. In a society that values relationships, good design should require human interaction.
These aren't universal. They're societal. And good design is specific to the society it serves.
Accepting Imperfection as Design Maturity
The Liberation of Accepting "Less Wrong"
For the first few years, I designed trying to reach "good design." I iterated trying to improve. I competed trying to be better than other products.
Around year three, something shifted. I stopped trying to find good design and started trying to find less wrong design.
This shift is liberation.
When you stop trying to be perfect, you can admit limitations. You can say "This design serves this segment and this time. It doesn't serve that segment. That's intentional."
When you stop trying to be perfect, you can focus on what matters: solving the problem you set out to solve, for the people you set out to serve, in the time you have.
When you stop trying to be perfect, you can negotiate with stakeholders from a position of honesty instead of defensiveness.
Design Maturity Is Accepting Iteration as Permanent
Immature design practice thinks: "We'll iterate until we reach good design, then we'll stop iterating and the product will be stable."
Mature design practice understands: "We'll iterate because context constantly changes. The product will never be stable. We'll constantly be redesigning for right now."
This is not exhausting. This is clarifying. You're not failing when the design becomes wrong. You're succeeding if you notice it's wrong and iterate.
The Honest Designer Admits
The most experienced designers I know don't claim to know what's best. They claim to understand the tradeoffs and make them intentionally.
They say things like:
"This design serves speed but sacrifices trust. I recommend we trade that off because our market prioritizes speed."
"This design requires a 6-week implementation instead of 2 because I'm optimizing for accessibility. That's the tradeoff I think we should make."
"This design works for urban users but fails for rural users. We can't serve both equally. I recommend we focus on urban first and plan for rural later."
They don't pretend certainty. They present options with clear tradeoffs. They let stakeholders decide if the tradeoffs are acceptable.
This is how you design across paradigms. Not by proving one paradigm superior. But by being transparent about which paradigm you're operating in and what that means.
Conclusion
After five years of designing, shipping, iterating, failing, succeeding, presenting to stakeholders, watching products in the wild, I've learned:
Wicked problems have no stopping rule, as in there's no way to know your solution is final. Solutions to wicked problems are not true-or-false; they can only be good-or-bad.
Design is the search for less wrong solutions to wicked problems in specific contexts at specific times for specific stakeholders operating within specific paradigms.
There is no universal good design. There is only:
Paradigm-specific design (working within a framework of assumptions)
Culture-specific design (serving a particular culture's values and constraints)
Time-specific design (appropriate for this moment, knowing it will shift)
Stakeholder-specific design (acknowledging different truths held by different stakeholders)
Context-specific design (appropriate for these conditions, not universally)
When you accept this, design stops being about finding truth. It becomes about making conscious choices with full knowledge of consequences.
You don't ask "Is this good design?" You ask "Is this less wrong than the alternative for our users in our context at this moment?"
And if context shifts, you don't claim the old design failed. You recognize that less wrong has changed. And you iterate.
This is not resignation. This is maturity. This is honesty. This is design that works because it admits what it can and can't do, and designs accordingly.
References
If you're reading this expecting to learn "principles of good design," I apologize. But I also won't apologize for redirecting you.
The moment you accept that good design doesn't exist only less wrong design for right now—you're ready to design across contexts. You're ready to operate in multiple paradigms. You're ready to manage stakeholder complexity. You're ready to iterate as context changes. You're ready to admit when you don't know and work toward knowing.
That's when design gets interesting. Not because you've found the answer. But because you've stopped looking for one answer and started negotiating between many.
Next
Product-Led Growth in African Fintech
THe description of the title
Product-Led Growth in African Fintech
THe description of the title
Product-Led Growth in African Fintech
THe description of the title
The Retention Pipeline
THe description of the title
The Retention Pipeline
THe description of the title
The Retention Pipeline
THe description of the title
The Convenience Threshold
THe description of the title
The Convenience Threshold
THe description of the title
The Convenience Threshold
THe description of the title
Design as the Search for Less Wrong
Design as the Search for Less Wrong