Q&A

I stick closely to strong conventions. If you respect platform norms and familiar UX patterns, people can naturally rely on their existing knowledge to navigate your app.

Think of something simple, like shower faucets. You should know how to use them. Yet, if you have traveled enough, you have probably encountered at least one hotel faucet you could not figure out. Not because you are stupid, but because it is not only different from every other faucet you have used, it is different from almost anything else in your life. The same applies to design. When you use patterns your audience already recognizes, they already know how to interact with them.

Still, any moderately complex app eventually runs into constraints or overwhelming choices that need simplifying. That is when progressive disclosure is really helpful. For instance, placing a "more" menu near primary actions maintains a clean UI while still making extra functionality easy to find. Design tools do this all the time: bold, italic, and line-height are prominent, while advanced options like kerning or superscript live behind a nearby "more" affordance.

Larry Wall, creator of Perl, famously said: "Easy things should be easy, hard things should be possible." I take that to mean that some features are inherently complex. For those cases, good documentation or tutorials are the last resort, but they are still perfectly acceptable.

It is usually the small things users only notice when they are missing. Consider pressing return in a code editor: it often automatically indents your new line based on the structure of the code. That did not happen by accident. Someone took the time to implement it. If you had to manually indent each line, you would become annoyed quickly, whether consciously or subconsciously.

Another subtle example is automatically placing focus into input fields when they appear, letting you start typing immediately. It is about anticipating the next tiny step and quietly taking care of it for the user.

There are countless opportunities like these in both software and hardware: the ribbon that helps you pull batteries out, the teapot spout that pours cleanly, or drawers that close gently instead of slamming. They show deep empathy for the user. They often require real engineering effort, but they make experiences feel better even when users cannot quite explain why.

I start by trying to understand the problem fairly deeply: the technical challenges involved, the constraints, the business needs, and the surrounding context.

From there, the path varies. Often the idea starts taking shape while I am doing something unrelated, like walking, driving, or lying in bed. I mentally review similar patterns, related products, and possible approaches. Then I move into a design tool and begin visualizing the concept. As I sketch details, edge cases reveal themselves and I solve them in real time.

Other times, I go straight into code, especially when the interaction itself is the question. I will prototype the behavior first and then layer on visual polish and micro-interactions.

When I am working with a team, I love using a whiteboard to figure out the flow together with designers, engineers, or PMs. It should be a safe space to explore, share ideas, and debate tradeoffs.

When presenting an idea, I like using Keynote or a prototype to tell a story: define the problem, explain the challenges, walk through the happy path, and then address important edge cases at the end.

Before every major release at Apple, we held dedicated pixel-spotting sessions. Designers, lead engineers, and managers got together and meticulously reviewed every flow, from the main use cases to tiny edge cases. We captured visual issues and the kinds of micro-interactions that make an experience feel smoother and more considered.

The point was not to debate priority or argue about validity in the room. We simply noted everything. Later, we triaged the list and decided what needed to be fixed before launch. It was amazing how many details surfaced in those sessions.

Getting better at design is similar to improving at chess. It is less about memorizing explicit rules and more about building pattern recognition through repeated exposure and practice.

I would start by closely examining apps you admire. Screenshot them, study their interactions, and try to understand why certain patterns feel intuitive or polished. As you build a mental library of UX patterns, you naturally start combining them into more cohesive designs of your own.