Why I became a UX designer

I enjoy coding because it allows me to make digital things with both hardware and software. I studied computer engineering at the University of Waterloo then I was a developer for 8 years. I worked on software which dealt with automotive manufacturing to investment banking. However coding wasn’t the favourite part of my job. The part of the job that I enjoyed the most was gathering information on the business problem and working on what the solution should be.

In an enterprise environment the role of gathering of business information was designated to the business analyst. I did that for a while and produced documents which listed the functional and non functional requirements. Although I learnt a lot about the business, I was missing out on the other side of the applications — the users.

What inspired me?

Most designers I worked with, I never saw. I gave them the requirements and they gave me a design back. The designs missed out the real purpose and was just putting the lipstick on my Visio diagrams. I didn’t like this process but was there a better way?

This all changed when I worked closely with one designer who did interviews and workshops with users before he even touched Illustrator. He gathered information about the business and produced documents in a visual manner with sketches and wireframes. The business were more responsive in reviewing the requirements of the project and provided more insight on what their needs were. I wanted to create the same collaborative process.

My colleague recommended that I read Undercover UX by Cennydd Bowles and James Box. This book was helpful by showing me where and how I can incorporate user experience design processes into a process which did not have it initially.

What did I have to do?

Over the next two years I refined my process as a developer to include some of these practices of sketching, wireframing, interviews and workshops in my day to day role. I knew I was doing something right when traders who are strapped for time were asking for wireframes so that they can discuss concepts for new features. Working in this environment also meant that I didn’t create huge amounts of documents but just the necessary ones.

The next step was making the jump from developer to designer. All I had at the moment were financial trading applications, how could I relate this to other types of apps? I needed a wider breadth of experience. I invested personal time into a few personal projects and helped out a start up designing a mobile payment experience. I managed to get a job at an UX agency which focused on financial services.

Once in my new role, I knew there was still much I had to learn. Using different tools like Omnigraffle and Axure were easy to learn but the major ones was handling design critiques, design principles and presentations. Thanks to the feedback from people I have worked with, it has helped me improve along this evolving journey.

How do I feel now?

Moving from being a developer to a designer allowed me to keep solving problems. Instead of the how, I am now approaching problem solving by focusing on the why.

There are a lot of similarities and parallels between the worlds between business analysis and UX designer. User stories and system diagrams versus personas and experience maps. Data flows versus user flows. For a while we have treated these activities as being separate worlds. But the software we build have those two sides — the business and the user. One can’t be without the other. It is one product.

The biggest lesson to date for me is that UX design cannot be done alone. It requires business, technology and user research to come up with the right user experience. This makes me wonder how this industry will evolve in the future as we become more collaborative.

For more stories of other UX designers who came from a development background, here is an excellent write up from Boon Chew about his journey.


What is good design?

In my early design interviews, I was asked “What makes good design”, I answered “Good design is design that create delight”. Coming from the development world looking into the world of design that’s what I thought. I was wrong.

“Good design is design that creates delight.”

Delight to me were the little animations that appear in page to pre-filling a form on a page. But are these moments of delight good design if the overall experience had no purpose?

As a developer I was copying the latest trends in design when designing my user interfaces. Round and shiny buttons? Yup did that. Flat design? Yup did that. Following these trends taught me how to use design tools better. I thought that if I knew how to create the latest designs then I would get validation on Behance or Dribbble that I was a good designer. But is it good design if people like the way it looks?

Design is about more than just aesthetics. So what makes it good or bad? How do you evaluate design?

As a hobby I like to cook. Watching how the great chefs describe how they cook and how they can make simple ingredients shine. Every ingredient brings a certain flavour to the dish. Every ingredient has a purpose.

What is the purpose of a design element? For each design element the purpose of it is to be useful in solving a problem. The hypothesis driven design approach from Maximilian Wambach has changed the way I approach design. It is how I frame my design tasks:

If [action]
Then [outcome]
Because [customer need/problem]

Design hypotheses focuses the design so that each decision to add or remove an element has to contribute to solving the problem. If it is not helping solving the problem, then it has no purpose. If it has no purpose then why have it?

“Good design solves problems”

This way of approaching design works no matter if you are working with shiny buttons or flat ones. Delight can only come after you first make the design useful.

Design works when you are solving problems.