Hey, I'm Leonard and I'm a Digital Product Designer.

Welcome to my site. I’ve penned down some of my experience as a Product Designer over the years. It's a 10 minutes read.

Read onDownload Portfolio
Introduction

I wanted to be read like a book. Slightly big font size, not too many pages and just enough professional lingo. There's a bit of bias but the stance is clear. In some ways, it's WYSIWYG. I've had the opportunity to look at some of the works of my fellow professionals and I've always wanted to know a little more. Beyond their awesome-looking works, what are they like? What are their thoughts? What can I suss out? A mini book would be good I thought.

Career

After completing 2 years of mandatory military service, I started off as a visual designer at a production house in 2013. I then worked as a part-time U/UX designer for 7 months at OTSAW.

In 2016, I entered the FinTech space, joining GoBear as a Product Designer. I mainly designed for GoBear's banking-related product lines.

I left GoBear to join SWAT Mobility in the transportation and mobility tech industry in 2018. I was hired as one of the founding members to spearhead the company's effort into the B2B space. To date, we've successfully turned the company's core technology into profitable products used by companies all over Asia.

Design

I was a design student. I studied Architecture at a Polytechnic and graduated with a Bachelor's in Communication Design from the Glasgow School of Arts.

A huge part of the way I approach design can be attributed to my days as an architecture student. The research, site analysis, human traffic analysis etc. The design process. Entry and exit points that complemented the study, form that followed the function of the space. The painful prototyping process where my paper models were filled with tears and sore fingers. I once went without sleep for three days.

This method worked well for me when I first started in 2013. It led me to understand that the principles of design are universal. The tools that we use and the environment that we're in might be different, but the principles remain the same.

Product design

Not everything is the same though. There are a couple of things that were idiosyncratic to the industry and I had to adjust and learn along the way. The job scope of a digital product designer is actually pretty huge. It ranges from something technical like screen design to something more academic like research.

There are a couple of things that, in my experience, I thought was pretty important to this role.

Modern software development

Digital products and their development processes completely threw me off guard. Where I came from, it's unheard of to build an MVP version of a building. It's not practical to design something without knowing how it would eventually look like.

There were days when I was completely dismayed by the state of the work. MVPs. If you weren't disgusted by it enough, you aren't doing it right. I read that somewhere. So, don't quote me.

Incremental software development might not exactly be an engineer's or designer's ideal playground but it does allow for the business to manoeuvre and change its course easily whenever necessary. This means that the way we work has to be nimble enough to cater to these situations.

The Design System has been the talk of the town for years now. I've never had the opportunity to work on a full-fledged Design System but it has always been a conversation between the engineers and the design team. At its very core, the design system is about scaling through reusable UI components. This would then enable the team to speed up the design and development process while maintaining consistency.

From the design team's perspective, wireframes, UI design and prototypes can be quickly created using existing components on Figma. This frees up time for us to focus more on the users and their goals.

Product changes and pivots will thus, have a lesser impact on design and frontend development because we largely work with what we have. 

Communication between the designers and engineers is key to making it work. I don't get to decide how the engineers would want to go about building it. It's their call to decide the whens, whats and hows to approach building a UI component library. Ultimately, it has to work for them. The UI library that we've created on Figma keeps design work consistent.

Next, I see scoping and communication between the product managers and the execution team to be crucial in digital product development. Product managers that operate primarily as a messaging vessel will never work. The more we communicate about ideas and direction, the better the execution team will be in managing code and design work.

From a design perspective, it allows us to design with the future in mind. Keeping design less rigid and more open to possible future expansion of a particular feature, for example. It also enables us to better understand certain compromises that we have to make and prepare the design to negate potential undesirable experiences with the product.

Designers and coding

Should designers code? There are articles published every year that touch on this particular topic. I find myself to be inadequate to practise design if I have no/low knowledge about how it's built.

The feeling is almost identical to when I was in Architecture school. As a freshie, I'd try to design these 1:250 scale monstrous organic-looking shaped structures because it's cool and also because the boards that we used to make these models were pretty strong so if the glue can hold it, why not?

While students must be creative and experiment, it's not at all practical. As I progressed as a student, my creativity became more controlled. Now, I'm more aware and have more control over how I want to approach a project. That only happened because of the knowledge regarding the details of construction that I've gained over time.

As a product designer, if we don't know code or basic programming, we're not going to perform to our fullest potential. Learning and understanding code has been a long journey for me. Beyond HTML and CSS, actual programming can be pretty daunting. There is little room for error and it's something that I have to practise a lot for it to make sense practically.

There were the occasional bouts of timeouts in my learning journey but I never gave up. The knowledge accumulates every time I pick up where I left off. It's been 10 years now and I haven't written shit. Maybe a few lines here and there to do up the site but yea, that's the state I'm currently at. Despite that, I still felt adequate to perform as a digital product designer.

The most important takeaway is that this knowledge, however shallow it might be, helps with communication and how I'd approach my work. Taking an online course is never going to make me an engineer but it makes me more aware of the engineering's perspective when I approach design.

In 2021, I picked up the pace and completed JS, Swift, the Command Line and Git on Codecademy. If my life is on the line, I think I'd be able to piece together a shitty but working calorie tracking app using Swift.

In hindsight, it's the same relationship between an Architect and a Civil Engineer.

Research

I had the chance to learn more about research in this line of work from some of the researchers that I've worked with through the years. I started by assisting in them in their work by providing prototypes for UTs, participating in focus groups, interviews and workshops that they'd run regionally.

I've learned a lot from these researchers and in-lieu of a research team, I've managed to apply bits and pieces of whatever I've learned. Naturally, not everything is as rosy as it seems. There is a couple of stuff that I find excessive and I had to be eclectic and adaptive for research to work in a different environment.

The more research work I do, the deeper I fall into the rabbit hole. Research can get a little too academic and I'm not a professional researcher. It did get to me. I found reprieve in Erika Hall's Just Enough Research. So much so that along with Donald Norman's DOET, the two books form the backbone of how I'd approach my work as a product designer.

Ultimately, as a designer, I need all the information I need to make the best possible design decisions. Research, be it generative or evaluative, is one of the many things I can do to achieve that.

Visual design

I had to create pixel-perfect screens in my first job back in 2014. I was in a software house and I had to churn out screens at a relatively high velocity. It required me to inspect sites and themes and recreate them to somewhat match a project's needs.

Not particularly pretty but necessary. I suppose that it's the equivalent of a chef's apprentice who starts by cleaning the kitchen.

Technically, this is perhaps the hardest part of the job. Choosing the right typefaces, adjusting various attributes of the font, creating an entire site etc. Not so much if there is an existing system, but it can take years to become a competent visual designer. Logically speaking, this is a hard skill and that's where the bar gets raised.

The root cause

There was this episode of Air Crash Investigations where an aeroplane broke up midair. They later concluded that the crash can be attributed to structural failure. As it turns out, the mechanics have been papering over cracks with sheets of metal. The crack grew larger over time which caused the unfortunate accident to happen.

Papering over cracks is akin to mindlessly putting bits and pieces of functionality on the UI. I think it is criminal for a designer to do that.

Created by Sakichi Toyoda, the 5 Whys is a popular Root Cause Analysis method. It was used by Toyota Production System for improving quality. The basic idea is to keep asking why even if a presumed cause has been found. This would naturally provoke a deeper inquiry which would then uncover the true underlying cause of a problem.

The 5 is more symbolic than it is semantic. It could be more, it could be less, it emphasises the need to keep probing until the root cause has been found.

Obviously, I don't go around asking "why" like a broken record. It could potentially be unsettling and counterproductive.

Intuition

I read up quite a fair bit about intuition and design when I was an undergraduate. In my line of inquiry, I sought to:

- find the difference between intuition and instinct 
- if intuition can be evoked by design

I've learned a lot during that period and I took a lot of that knowledge into my professional career as a Product Designer.

Intuition can be learned. It's less magic and more experience. The more you do something, the better you can intuit. A doctor can be intuitive about identifying symptoms but be clueless about robotics. I'm pretty sure we've all experienced it before. Excelling in something to an extent where you can anticipate an incoming right cross, an opponent trying to fake left and move right etc.

Sounds familiar? That's right. Intuition is a learned process; it draws on one's experience to make quick second decisions and logical assessments of an impending situation. 

Three paragraphs devoted to intuition before I drop the bombshell. 

I do not test everything that I've designed. Very often, I'd let small builds slide. I make design decisions based on the product's goals, findings, feedbacks, applications of certain design principles and with a hint of intuition. Hence, I rely heavily on my communication with the product managers, actual users and staff who are in regular contact with users and clients.

Time is a huge factor as well. From a startup's perspective, it's faster and less expensive to quickly roll out features to learn and quickly iterate if necessary. I cannot compare my work to that of a researcher's year-long study.

When I conduct tests, it needs to be worthwhile. Be it an epic level feature or a general usability audit of a product, it needs to provide the team with insights and value.What is not doing well? Are the users having difficulties progressing in some of the tasks?

A rule of thumb that I thought was useful was to test the riskiest ideas with the highest reward.

Usability vs usefulness

After concluding a day's UT:
Someone: Do they like it?
Me: Huh?

I have to be clear on the objective of the kind of test that I'm conducting. For example, I'm only looking for issues on usability in a usability test.

I wouldn't exactly know if a user liked or disliked it. I don't know if they're saying they liked it to be courteous or not. I can only objectively tell if a design is succeeding or failing from a usability perspective.

Usefulness is a completely different topic altogether. According to NNG, Usefulness is Utilities plus Usability. When a product is usable and has the necessary tools to help the users complete their goal, it is thought to be useful.

Utilities are built over time. What to build could be dependent on several factors. It could be the market that you're trying to enter, findings from a release, competitor analysis etc.

From a designer's perspective, most of what I do revolves around the usability aspect of the product. While we partake in the process of what to build, I'd say that a huge part of what I do revolves around the usability of the product that we're designing.

Data

I've never been super hands-on with quantitative data. I'd generally know of existing and impending monitoring or research plans but I've never run, lead or conclude quantitative research. That's largely because I've had the luxury of having Product Managers and analysts providing us with these findings.

I always thought that the difficult part of this process is making sense of the data. Why are visitors dropping off at this part of the funnel? Why are users not accepting rides? Why are users not clicking through? The whys.

I've seen the easy way out. Cosmetic changes like repositioning or resizing CTAs, moving UI elements around etc. while not making any effort to get to the root cause. Without getting to the root cause, we're just mindlessly fiddling around with the changes, hoping that something would work. Sort of like how I deal with coding sometimes. Haha.

By understanding the root cause of a problem, we can then come up with a hypothesis that we can latch on to guide us through the design process.

Experience

I've been working at startups all my life. I'd say I've gotten a good hang of it. I've seen products go from zero to having users saying the app suck in my face. I've gone from primarily a pixel-pusher to a more patient, collaborative and system-centric designer. I'm not even sure if that's entirely a good thing. I've lost some and gained some.

There are a couple of takeaways that I thought were very impactful and it shaped me into the designer and person I am today.

Startups must be lean

One of the first books that I've read when I entered the industry was Jeff Gothelf's Lean UX. Beyond UX, it describes how software can be better built and the importance of collaboration. It primed my mind to embrace a completely different way to approach design.

Some of the ideas and principles that I've read are practices that we'll find in most modern tech startups. It's not as prevalent years ago but it's definitely the norm right now. MVPs, incremental releases, development methodologies etc.

I find that productivity through structured and proven methods is one of the best bets a startup's got in the battle against time. Different situation call for different methods and there are a couple of methods that I'd default to. I've gone through a couple of GV's Design Sprint. There are a couple of methods that I like and have used independently in different situations. Mapping the challenge ahead and identifying key areas that the team can agree to take on is crucial to set expectations right off the bat.

Pretending it's magic in Alan Cooper's About Face is another one of my favourites as well. It forces us to rethink an existing design that might be limiting the way we think.

Adopted and made popular by IDEO, How Might We reframes statements, comments, accusations(?) and problems etc. into questions. This simple switch in the way we frame statements turns challenges into opportunities.

Be it the various methods Product Managers use to do prioritisation, Nir Eyal's Hooked Model, Donald Norman's Approximate Model or using affinity mapping to make sense of various data points, these methods reduce waste and encourage collaboration between teams. Most importantly, we can expect outcomes from it. It is frustrating to be in a long meeting or an unstructured "brainstorming" session with no conclusion or actionable items.

Development methods

I was at a startup where the backlog items were in the tens of thousands. We were supposed to be Agile. Funny. We did our daily standups, worked in sprints, had a Scrum Master, an Agile coach, and some even recited the manifesto during lunch. The last, I kid. 

What went wrong then? I think that adopting the Agile way of software development is more of a belief than a method. Few understood what it stood for, the ones who understood weren't convinced. It has to be a collective effort for it to work.

It's easy to understand why though. The struggles of releasing features incrementally. Everybody wanted the perfect application or feature. Every story seemed like an epic. Every story seemed to revolve around the creator than actual users. A development process that felt more like a project than actual product development.

At another startup, we've managed to roll out multiple products and product lines within the span of the three years. I was part of the pioneer group and.. nope, we weren't exactly agile. It was an eclectic mix of Agile, Waterfall, Kanban and whatever worked. We stopped pretending and we did what we all felt was right as a team.

Squads

Marty Cagan's Inspired is truly inspirational. It's an idea that I've tried and failed but still believe in. My first experience was a colossal mess. I didn't even know who's in my squad. Resources were spread a little thin the second time. However, in that second experience, I felt what an autonomous, cross-functional and collaborative squad was capable of. We made decisions together. We faced our failures together. We were committed to our squad's goals. Eventually, we had to restructure due to a limitation in manpower.

Context switching was kept to a working minimum. On the other hand, the design team were in constant communication to ensure the consistency and quality of our work.

This is how I felt organisations should be run. Squads within squads. Every squad has a few goals and indicators to measure performance. Minimising red tapes is crucial to productivity.

Relationships

I see, hear and talk to some of my colleagues more than I do with my family members or close friends. Each of these people brings a little something to the table.

Product managers

The one that binds everything together. I always thought that managing prioritisation and moving things around the JIRA board is always the easy part of the job. It's like a Product Manager's basic starter pack. It's extremely low level, non-technical and there are materials out there that will get anyone started on the job. How to write a story, what is the Agile development process, what is a Scrum Master, various methods to go about prioritising work etc.

However, the difficult part of the job, is what binds the product team together.

IMO, a PM is the team's go-to source for knowledge. Be it about prioritisation, product vision, KPIs, performance, stakeholders' expectations. It's a lot to ask for, to be honest. This is extremely crucial because they are at the crossroad of information. What they do with all the information is what defines a PM. Being in this position gives them the best vantage point to make the best product decisions. 

The future can be difficult to read and there's no formula to guarantee the success of a product. The PM's job is to steer the product toward success, more often than not, one step at a time. Furthermore, the definition of success may change during the process. Therefore, I'm not a big fan of long-ass roadmaps.

To do that, a good PM utilises the help of the team to make decisions. Again, more data points to aid in the decision-making process. Making product decisions with the team brings the team closer. Respect and trust are also earned during this process. No one likes a know-it-all or an information hogger.

Lastly, I find that a strong PM is also a good stakeholder manager. Everybody has an opinion and wants to get their shit built. Saying no and picking the right battles are just some of the things a PM have to do for the good of the product. A PM that bows to every request don't bode well for the product and its team.

This is a very difficult position to be in and because most of these skills are soft, it's also very difficult to hire. As a designer, I find myself working to the best of my abilities when I have complete trust in the PM. It's a team game, success or failure.

Engineers

These are the guys I try my best to learn from. Together, we push the limits to what we can build. As I've mentioned earlier, I picked up coding to help me make better design decisions. It's helped me scope my work to fit timelines and requirements. I find that constant communication and trying my best to think like an engineer allow me to produce my best work for a given situation.

Apart from that, I also find that some of the best ideas often come from the engineers. Yea, saving my ass.

Designers

I currently work with 3 other designers while I serve as the team lead. They've been an absolute delight to work with. I oversaw the recruitment process and the initial goal was to look for well-rounded designers. I thought the recruitment process was a huge success. All of them got up to speed and were able to accept feedback and brush up on certain aspects of the job that they weren't confident in. We latched on each other's strengths to get our job done and in the process, we've created a robust design team.

Although I lean on the side of design principles and logic, nonetheless, I find that design can sometimes be subjective. Different designers have different ways to achieve a goal and we all meant for the design to be the best for the users. Mistakes are inevitable but whichever way we take, the truth would eventually lead to a better design.

Again, I rely on relationship building to get the best out of myself and those around me. Identifying the strengths, weaknesses, traits and personality quirks of my colleagues goes a long way.