My first three years: making things pretty
I started my career the way most designers do — obsessed with how things looked. Beautiful gradients, perfect type, smooth animations. My portfolio was a gallery of Dribbble-style shots. If a screen looked good at 2x zoom in Photoshop, I considered it done. I was a visual designer who happened to work on digital products.
This approach worked fine at agencies, where clients judge work by how it looks in a presentation. The deliverable was a set of polished mockups. What happened after handoff was someone else's problem. I did not care about edge cases, loading states, or error messages. Those were 'details' that engineers would handle.
It took me about three years to realise: I was not designing products. I was designing posters that happened to have buttons on them. The wake-up call came from a developer who showed me the live version of a screen I had designed six months earlier. It looked nothing like my mockup. Buttons were misplaced. The type was wrong. I got angry — and then I got curious. Why did it diverge? Because my design never accounted for real data, real constraints, real user flows.
The project that broke me (in a good way)
The turning point was the Valmont Legacy Redesign project. This was not a single app with a single user type. It was five applications, dozens of user roles, real-time data from physical sensors in fields across the US. There was no way to approach this with pretty screens alone. I had to understand irrigation science, dealer workflows, regional regulations. I had to design systems, not surfaces.
For three months, I barely opened Figma. I spent my days in meetings with domain experts, reading technical documentation, and mapping information architecture on a whiteboard. It was uncomfortable. I felt like I was not doing 'real' design. But when I finally started designing screens, they came together in weeks — not months. Because I actually understood the problem.
That project taught me: the quality of your design is directly proportional to the quality of your understanding. You cannot solve a problem you do not understand. And you cannot understand a problem by only looking at the surface.
Questions I ask now that I never asked before
Early in my career, my kickoff questions were: what colours do you like, what is the deadline, can I have the logo in SVG? Now my questions are completely different. Who is the primary user and what is their worst day? What happens if this feature fails silently? How will we know if this design is working — what is the metric?
These questions do not feel like design questions. But they are. They shape every decision I make. If I know the user's worst day, I design for that day, not the happy path. If I know the failure modes, I design error states that actually help. If I know the success metric, I can prioritise features that move that number.
This shift from visual designer to product thinker did not happen overnight. It took years of watching my designs break in production to realise that the pretty parts matter less than the functional parts. A beautiful button that nobody clicks is still a failed button.
Advice for my younger self
If I could sit down with the 24-year-old version of me, fresh out of design school and obsessed with gradients, I would say three things. First: learn to write. Not copywriting — just clear, structured writing. Most design problems are actually communication problems. If you cannot explain your thinking in plain English, you have not understood the problem.
Second: learn to say no. Not every feature request is valid. Not every stakeholder opinion is equal. Your job is to be the advocate for the user, not to make everyone in the room happy. Saying no with evidence behind it is a skill that will earn you more respect than saying yes to everything.
Third: ship things. A shipped design with 80 percent polish is worth infinitely more than a perfect Figma file that never reaches a real user. Real experience comes from seeing your work used — from watching people get confused where you thought it was obvious, from fixing bugs you did not anticipate, from iterating based on data, not taste.