In an industry often fixated on clean interfaces, a deeper view of design is emerging. One that understands products as systems, not just screens, without dismissing the importance of craft. In this interview, Ahmad-Tijani Bashorun, a Senior Product Designer at a US Enterprise healthcare company, reflects on what it truly takes to design well. Drawing from his work across healthcare, fintech, and consumer-facing products, Bashorun reflects on the lessons he has learned so far and how designing in high-stakes environments has shaped his thinking. From high-stakes software to everyday digital tools, Bashorun explores responsibility, rigour, and why great design feels effortless only because of the work that came before it. Excerpts.
You often say you “make experiences,” not just interfaces. What does that distinction mean to you in practice, and how does it change the way you approach a new product?
When I say I make experiences, I’m talking about everything a user goes through before, during, and after they interact with a product, not just what they see on a screen. Interfaces are important, but they’re only one layer of a much bigger system.
In practice, this means I spend a lot of time understanding what someone is actually trying to do, what constraints they’re operating under, and what success or failure looks like for them. The interface is simply how that thinking eventually shows up. Approaching products this way helps ensure we’re solving the right problem, so that what we design looks good and works well.
Long before design was a formal role for you, you were paying attention to how things worked and where they didn’t. How has that early instinct for observation shaped your design mindset today?
That instinct is still central to how I work. I’ve always been curious about why certain things feel easy while others feel unnecessarily difficult. Even before I knew what product design was, I paid attention to small frictions and patterns in everyday systems. Today, that shows up as a habit of observation before action. I try not to jump straight into solutions. Instead, I observe how people behave, where they hesitate, what they complain about, and what they work around. Those moments usually reveal more about a system than any feature request.
You have said that complexity doesn’t live in interfaces, but in the problem itself. How do you uncover that hidden complexity when entering a new domain or system?
I start by separating symptoms from causes. What users complain about is often real, but it’s usually a surface-level expression of something deeper. I try to understand the user, the business context, and the constraints that shape the system. That includes what success looks like, what failure looks like, and where incentives are misaligned. Once you understand those layers, the complexity becomes clearer, and meaningful simplification becomes possible.
Many teams focus heavily on what’s visible on screen. What risks do you see when design efforts stop at the interface level instead of addressing underlying systems and constraints?
When design stops at the interface, teams risk treating symptoms instead of problems. You can make something look clean and minimal while the underlying experience remains frustrating or inefficient. That often leads to products that appear simple but feel confusing in use. Addressing underlying systems and workflows is harder, but it’s the only way to create experiences that actually hold up over time.
In your work on care management software, design decisions can have real-world consequences. How does working in high-stakes environments change the way you think about responsibility as a designer?
It makes responsibility very concrete. In high-stakes environments, confusion isn’t just inconvenient; it can affect real people in real ways. Working in that context reinforces the idea that designers are not neutral participants. I see my role as being accountable for how a problem is translated into a solution. Even though design is collaborative, I believe designers often sit at the focal point between a system and the people navigating it.
You have stated that “design is not neutral.” Can you expand on how values get encoded into products, even when designers believe they’re being objective?
I believe neutrality can exist in intention, but not in outcome. Every design decision reflects a set of priorities, whether that’s speed, efficiency, profit, accessibility, or control. Even choices that seem purely technical or objective shape behaviour and outcomes. Acknowledging that reality allows designers to be more thoughtful about the impact of their work instead of assuming they’re simply implementing requirements.
Simplicity is often treated as the ultimate goal in product design, but you are cautious about that framing. How do you distinguish between true clarity and oversimplification?
True clarity comes from understanding the problem deeply. Oversimplification happens when teams focus on reducing visual elements without addressing the underlying complexity. A product can look minimal and neat and still miss the point entirely. For me, simplicity is a result, not a goal. When the problem is well understood, clarity tends to follow naturally.
You argue that delight is the outcome of rigour, not visual polish. What does rigour look like in your design process, and how do you know when you’ve achieved it?
Rigour shows up in the unglamorous parts of the work. Understanding users properly, aligning with business realities, testing assumptions, and being honest about trade-offs. I know we’re getting it right when users move through an experience without friction and feel confident using it again. Delight, in that sense, isn’t about surprise. It’s about trust. That doesn’t mean visual quality is optional. I care deeply about how things look. Visual craft is part of the experience, not separate from it. Sometimes people use process as an excuse for poor execution, but that’s a misunderstanding of rigour. When an experience feels genuinely delightful, it’s because every part of the process mattered, including the visual decisions. Craft is not decoration; it’s how clarity, care, and intent become tangible.
As AI becomes more embedded in products, you view it as infrastructure rather than spectacle. How do you decide when AI should be visible to users and when it should stay in the background?
I tie that decision to user goals. When AI is doing something generative or making meaningful decisions, users should be aware of it. When it’s simply assisting, like correcting grammar or reducing manual effort, it doesn’t need to announce itself. The mistake many products make is introducing AI for its own sake. Deep integration matters more than visibility. AI should support the experience, not dominate it.
Looking ahead, you avoid big predictions and focus instead on meaningful problems. What kinds of challenges energise you most, and what does “good work” look like to you at this stage of your career?
I’m energised by problems that matter to people and systems that clearly aren’t working as they should. Good work, for me, is work that challenges me, helps me grow, and creates real impact.
At this stage, I’m focused on continuing to build, learn, and apply what I know to problems that feel worth solving, rather than chasing titles or trends.
