• Skip to primary navigation
  • Skip to main content
  • Skip to primary sidebar

UXwanabe

Learn the softskill of UX and grow your design career

  • Home
  • Blog
  • Podcast
  • About

UX

How to choose which battle to fight as a designer

May 18, 2023 by Tim Chan

As designers, we have been told we should “learn to choose which battle to fight” because we can’t win every argument. However, no one has taught us how to choose which battle to fight.

When I first became a design lead managing a group of designers, I found myself in meetings all day with designers trying to figure out how we should react in different situations. 

Team A did not follow the design system, team B insisted to push for a design that hurts the UX and team C decided that accessibility does not matter. Every scenario seems unique and we have to come up with a response every time. 

Without a framework, we felt like we are constantly fighting fires. We became reactive. We wasted mental energy figuring out how we should react. It was unsustainable.

Eventually, I found a way. In this article, I will share a framework that helped me solve this problem and gain back my sanity — I call it the “Rules of Engagement” framework, it helps you clarify:

  • When you should fight a battle
  • How much effort to spend on each battle
  • How to fight effectively

Let’s get right into it.


Rules of engagement 

In military speak, “Rules of Engagement” refers to official orders that describe when and how a soldier should engage enemies in a combat situation.

The idea is to proactively think ahead of how you would react when different situations occur, instead of passively waiting for it to happen and then figuring out what to do. This way, you avoid knee-jerk reactions and can focus your limited mental capability on truly unique matters.

When to engage & effort to spend

Imagine your design team as a country under siege by design-related issues. You have limited resources, so you have to prioritize which cities to defend using a tiering system. For example:

  • Tier 1 city would be your capital. Spend all blood and sweat defending it at all costs. This is the hill to die for, DO NOT retreat!
  • Tier 2 cities are important. Put up a strong fight and only retreat when the casualty is too high.
  • Tier 3 cities are the outer-rim territories, you don’t want others to take over them too easily. Put up a decent fight then retreat when the attack is too strong to conserve energy.

Applying to design, this would mean figuring out “How do we categorize our issues and How should we respond”?

Your tier list might look something like this:

The beauty of this framework is twofold:

  1. It forces your team to align on which area is important versus which is not. You conceptualize what matters. There is no individual guesswork, nor a designer going rogue debating stakeholders on things that just don’t matter.
  2. It is liberating to not have to think each time. Since you have done the hard work upfront to decide how you would react ahead of time, you know what to do 90% of the case. You avoid getting sucked into endless debates that don’t add value to your work. You conserve your energy to focus on the 10% outliers.

How to implement this framework 

  1. Get a whiteboard and draw 3 rings with a bullseye in the middle, label them Tier 1 to 3 starting from the center. 
  2. Write down common issues you face on sticky notes, then put them on the rings according to their importance level. Obviously, developers missing the checkbox by 2 pixel does not count as a Tier 1 issue. Well, at least in my team.
  3. Decide the appropriate response per tier. e.g. Tier x means putting in y amount of effort to argue with stakeholders before you escalate.
  4. Do this exercise with other designers and document the rationale so you can reference it in the future.

You are going to have disagreements and debates on which area is important, but that’s okay! It is much better to have an internal fight now than wait until the issue occurs and scramble to find the right response. 

Multiple tier list

You might find it beneficial to have multiple tier lists depending on your situation. In my previous role, the company was organized around international markets. The strategic importance market — the one that makes the most revenue — gets the most attention from stakeholders, so it made sense for us to consider this in prioritizing our responses.

I had two tier lists, one for the market and another for the nature of the issue. 

When an issue arises, I will follow this procedure:

  • First, look at the market — Which market does this issue come from? Is it from a strategically important market? i.e. Hong Kong or Singapore?
  • Next, I will look at the nature of the issue — What does this issue fall on? Accessibility? Design alignment?

Then I simply respond according to the pre-defined action.


How to engage effectively

From cold call scripts to product FAQs, the most successful teams would actively seek out repeatable solutions and systemize them. From my experience, the most effective way to help the design team engage with stakeholders is to provide them with the following:

  • Sample response scripts— These are successful scripts used in the past collected from wise designers that one can plug and use according to different scenarios. For example, a sample script on “ how to deal with stakeholders that don’t want to follow design pattern”. Constantly ask your designers to provide feedback on the scripts so you can continuously improve them.
  • Design policy & rationale — Decisions the design team made that designers can refer to. For example, to handle the situation where stakeholders don’t want to follow the new design pattern, you can say “Our policy is to apply a NEW design pattern on every new design”. Then if stakeholders continue to push, the designer can give out the rationale.

Don’t have a policy yet? Just start making one up now. I am serious. “Policy” is just a fancy name for how your team makes decisions based on grounded rationale. Once you have referred to your rationales enough times, it will become a de facto policy. You just have to start writing it down now so others can refer to it later.

I have included an example of what your rules of engagement document might look like. You can visit this Notion page and create a template for yourself.

Now whenever an issue arises, you can look at the table to identify how important it is, how much effort to put into it, and know exactly what to say.

Benefits of this framework

To recap, the “Rules of engagement” framework benefits the design team in the following ways:

  • Provides clarity — You know exactly when you should fight, how much effort to spend, and how to fight effectively. No more guesswork.
  • Empowerment — Your team feels empowered as they know how to handle different situations on their own. You can delegate decision-making to your team and free yourself from becoming the bottleneck.
  • Consistent response — Everyone on your team can act on your behalf and provide a high-quality response. You remove the scenario where Designers A and B will give different answers under the same situation.
  • Saves time — You can avoid unnecessary meetings since your team doesn’t have to come to you every time for answers.

I hope you give this framework a try. If you do please let me know how it turns out for you! 

Filed Under: Career development, Framework, Most popular Tagged With: Product Design, User Experience, UX, UX Design

Why you fail to influence stakeholders as a designer

April 28, 2023 by Tim Chan

If you were like me five years ago, you didn’t know how to influence stakeholders to make changes. You might have tried to convince stakeholders to do UX the “right way” according to what your bootcamp taught you or what you read online. They listened (not really, they just nodded while secretly swiping their phone), but nothing happened.

I know how you feel, I sucked at it too when I first start out. Throughout the years, I realized there is a process on how great designers have done it and I am eager to show you how!

There are two parts of this article. In Part I of this article, we will first understand why you fail to influence stakeholders, then in Part II (coming soon…), I will show you the step-by-step process on how to influence stakeholders without authorities.

Let’s start with Part I — why you fail to influence stakeholders.

Why you fail to influence stakeholders

There are three common pitfalls why designers failed to influence stakeholders:

  • Wrong mindset —You think your way is the only way
  • Wrong approach —You expected to sell it in one go
  • Wrong timing — You propose a new processes in the middle of a project

Let’s break it down.

1. Wrong mindset 

You know that boss. They went to a conference, they read it on Harvard Business Review or — god forbid — they went to a leadership offsite where you were specifically NOT invited, but they had to tell you anyway what a wonderful time they had in the company’s email. Now they are back with a new “strategic” direction and they want everyone to do things differently. This might be Agile or SAFe, whatever new framework was popular at that tim

Nobody likes that boss.

I have bad news, you are that boss when you did a UX bootcamp and want to change how everyone do things your way. The only difference is you are not a boss yet.

It’s okay! I was that person too when I first started in UX finishing a bootcamp, I wanted everyone to do projects the “right way”. You know, the “Start with the research”, “double diamond” method they taught us in the bootcamp.

Put yourself in your stakeholder’s shoes for a second:

Oh you took a course in UX? Well, I did a course in PMP, SCRUM, AGILE, SAFe, PRINCE2…etc with “Indutry recognized” certificate as well. Why is your method better?

This is actually a really good question you need to be able to answer if you want to influence others. Is the Design thinking way really better in this company? Maybe, maybe not. In most cases, there is already an established ways of working before a designer joins the company.

You will have to find out why the current process existed in the first place and what are their Pros and Cons. Challenging the status quo without fully understanding the context undermines stakeholder’s trust in you and lower your chance of being listened to.

Mindset shift

❌ Instead of — I know THE right way and everyone should listen to me.

✅ Reframe — I don’t know more than everyone, but I will spend time to understand why we do things the way we do here and propose how we can improve it later.

2. Wrong approach

Another common mistake I see from designers is to think one or two conversations is enough to convince people to make changes, and are discouraged when nothing happens. This is rarely how change works in real life.

Influencing is about driving change, and change is a process.

Expect any big changes to take time. It takes time to involve different stakeholders with multiple conversations and it takes time for you to form a coherent argument and find allies on your side. Preparation is key, so prepare to play the long game.

Mindset shift

❌ Instead of — I expect to influence others in one go.

✅ Reframe — I acknowledged change is a process. I play the long game to form a coherent argument and find allies on my side.

3. Wrong timing

Finally, designers often fail to influence stakeholders because they picked the wrong time to bring up a suggestion. For example, the project has already kicked off and the Product Manager has reached out to a designer for a solution — say they want a search bar and development start in 2 weeks.

I can imagine a lot of designers already started rolling their eyes in this scenario. Some might be frustrated and decide to tell their PM they need more time to do research right away. While it is obvious the company’s design maturity is low and the process is broken, making changes in the middle of a project is counterproductive and only breeds anxieties.

Let’s pause for a second to think about what is going through your counterpart’s head when they hear: “we should do more research now”.

“Why do we have to do research? How long would that take? Why can’t we launch first and gather user’s feedback later? Do I have to go back to all the stakeholders and have those alignment conversations again? Do I need a new estimation from the engineers? Will the project be delayed? Will that impact my KPI/OKR? My bonus? My career?”

When you make an argument at the wrong time, stakeholders often become hostile because they think you would hurt their interest. Instead of working towards a common goal that benefits everyone as a team, you become a threat to them.

So what should we do instead if you find yourself in the midst of a crappy process? Accept it. There is a right time for everything. Realistically, you can’t change much for the current project you are in, but you can work towards influencing stakeholders to make changes on the next one.

Remember, change is a process. Use this round as an opportunity to document the consequences of following the existing process and collect evidence to prove that it is broken. Did the solution work? Did the team create user value? Was the objective achieved? Was the design high-quality? Why should they care if it was not of high quality?

Don’t just go to your boss and say the current process is broken without any concrete evidence to back it up, you want to present it as a fact, not your personal opinion.

These are talking points you can bring up when you pitch your proposed solution later, so don’t be discouraged when things don’t go the way you want yet. Be patient and plan for the long game!

Mindset shift

❌ Instead of — I am frustrated that I can’t change how things work now.

✅ Reframe — I understand timing is important, I will take time to collect evidence on why the current process doesn’t work and use it to my advantage later.


Recap

Influence is hard, but it is also a skill that can be learned. Like any skills, the most important first step is to set yourself up with the positive frame of mind. Here is a quick recap on the mindset shift you can start implementing today:

✅ I don’t know more than everyone, but I will spend time to understand why we do things the way we do here and propose how we can improve it later.

✅ I acknowledge change is a process. I play the long game to form a coherent argument and find allies on my side.

✅  I understand timing is important, I will take time to collect evidence on why the current process doesn’t work and use it to my advantage later.

Now that we have our mindset straight, we will dive into Part II — How to influence stakeholders without authorities which will come out…really soon. 

The quickest way to get notified when part II comes out is to sign up to my news letter! 

Filed Under: Career development, Most popular Tagged With: Product Design, User Experience, UX, Ux Process

How to plan a successful career in UX

May 2, 2021 by Tim Chan

I was invited as one of the panelists to my friend Michael Tam (Global Design Director @ IBM iX)’s experience design course to share my industry experience with a group of UX students. Michael had sent me a list of questions beforehand and I have written down the answers I prepared. I thought it would be quite interesting to share it here because I always see myself as a better writer than a presenter!

I am the guy on the far right

How did you first enter into Expereince Design?

I wrote about that in my old post here.

Tips on First Steps/Interviews

First step is to acquire the knowledge you need. For me, the most effective way of doing this is by doing 2 things right — Read books & Ask smart questions.

Read — A lot of UX leaders before our time has put in the time to condense their lifetime learning into a consumable format, just read it! When I speak to a lot of wannabe UX designers, it amazed me how few people are willing to spend the time to absorb the knowledge that will actually help them get a job, most are just looking for a shortcut to get into UX. Let me be very clear, taking 1 or 2 courses DOES NOT make you a qualified UX designer. The lack of basic UX knowledge is the main reason UX students is not able to define the problem they are trying to solve clearly or are trapped into solving the wrong problems. If you are solving the wrong problem, it doesn’t matter how good your UI or prototype is.

Ask smart questions — This requires you to have the self-awareness of understanding the difference between:

  1. Things you don’t know the answer to and would be able to figure out on your own vs…
  2. Things you don’t know the answer to and would not be able to figure out on your own even if you try.

Never ask questions that you can figure out on your own. Senior designers like to help people in their shoes, but you should also respect their time. A good question demonstrates that you have done the work to try to find answers in the first place and had put in the time to think about the specific kind of help you needed.

Bad question: I have no design background, how can I become a UX designer? (JUST GOOGLE IT????)

Good question: I am a marketer who recently took a UX design course and is very eager to become a UX designer. I am keen to position my knowledge in planning marketing activities as a way to stand out to future employers that I understand service design and am able plan user activities. I am wondering if you were in my shoes, am I doing the right thing, if not, what would you do differently?

If you could go back in time, what’s the one thing you’d tell/change your younger self?

I would leave the start-up job early because I reached my plateau very quickly and I felt too comfortable. I would also be more consistent about writing and sharing about UX because writing helps bring me clarity on my thoughts, and it also helps to demonstrate my expertize and establish a personal brand.

Me giving comments on the student’s presentation

How to Plan a Successful Career in this Industry

Have a clear defined action plan on how to reach the next step in your career. Lets say you want to be a senior designer, how? Well, you need to find out what companies are looking for in a senior designer. Learn what senior designers do, learn how to do that thing and do it. Do online research on jobs ad and identify what are the gaps between skills you have vs what soft/hard skills is needed for the next step, then come up with a detailed plan (I recommend monthly) on how to close that gap.

Show the plan to you boss and invite them to be part of the process, most importantly, make them accountable. Say something like “I plan to be a senior designer in 2 years time, here is the plans I came up with that can help the company, the design team and myself grow, is there anything you would like to edit?”. Then, update them constantly during your regular catch up meetings. When the time comes, it is very hard for them to say no to you for the promotion when you have met the criteria you set together with your boss.

What are some of the best moves you have seen some young designers have made?

The best young designers I have seen have a strong personal brand, they made themselves stand out among others. They…

  1. Share their lessons learned along the way — Who are you and what is your story? For example “I am an auditor turned UX designer” will be an interesting one (Listen to my podcast if you haven’t already). Make sure you communicate your story clearly in your Linkedin, your portfolio, and every other form of communication! Start sharing everything you learn in the UX bootcamp on every social media as much as possible (read this book). Linkedin, articles on Medium, your own blog, Twitter, Instagram stories and whatever you can think of. Not many people do this, it takes hard work and it is preciously why you should do it because it helps you get noticed, it shows that you are driven.
  2. Built a strong network and add value to the community — Contributing to the local UX community and offering your help in their events. Winners always want to help winners. Let people know you are interested in UX for real, not just some wannabe that is slightly interested in UX and wasting everybody’s time. Start inviting people out for coffee or on Zoom calls. If people see that you are committed and driven, they will remember you and who knows? You might meet your future manager or employer in the design group, if they like you, they will also refer to their hiring manager friends, this happens all the time.

Experience Design & Business

How did you learn to define the real (design/or not) problems for a client/business?

If the problem is real, people will find a workaround or a hack to do that thing. Microsoft Excel team just looks at what popular macros people are creating and they will get a list of burning painpoints. If it is a good to have or not a real pain-point, people won’t do anything about it.

Tips on handling non-designers’ challenging me?

Different situation requires different strategy to handle. My quick tip is to assume good intention from stakeholders and take the time to listen to the question behind the question.

Are they asking you because they have their own agenda? Are they saying things just because they want to sound smart? Are they genuinely interested? Or do they want to do this as a power play (boss want to show who is in control)?

Rex Wong (VP of research @ JP Morgan), Ellen Wong(UX/UI Manager @ AXA), me (Product Design Lead @ HSBC), Micahel Tam (Global Associate Design Director @ IBM iX)

Do you think you have imposer syndrome?

All the time. I had it every step of my design journey, from before I got a UX job, I felt like a fraud, to when I actually got a job, all the way to getting a promotion as a UX manager to lead, I constantly feel like I am winging it.

Over time though, I started to “become comfortable being uncomfortable”, this means I expected it — imposer syndrome is like my old friend. The sign of having imposer syndrome means that I am growing in the right direction that I needed. If I don’t feel it occasionally, I might not be pushing myself hard enough or the job doesn’t offer me enough challenge.

I talked about imposer syndrome in early days of the career with my friend Anindita Saha (Service Design Lead at HSBC) in my podcast. Below is a transcript of what we talked about:

I remember I had written my CV…my very short CV at the time, on the top of my CV, I’ve written my name. In the second line, was supposed to say User experience designer. I remember I wrote down “user experience designer”, and then deleting it. Then writing it again, and deleting it. I was going back and forth about writing it. It took me 2 weeks to write down “user experience designer” and save it as a PDF.

This was 2012 in Hong Kong, UX was not a big thing yet. No one really knows what it is but I knew I needed to write it because if I didn’t, people will be very confused as to what I was trying to do. I felt like such a fraud, writing those words — user experience designer — second line of my CV, because I didn’t feel like I had enough experience to write those words down.

When I sent out my first job application, I was terrified. I had the impostor syndrome like “Oh my God, I’m writing this word down and what if I don’t live up to that terminology? What if I’m not embodying this term the way that it’s expected if someone actually interviewed me or even give me a job?”

I was terrified, but I had two minds. I had my terrified side of me and I had the logical side of me. The logical side of it was “if you don’t write this down, no one is going to know that you want this job, and then they can figure out whether you can do the job or not.”

It was really hard because normally what’d you put on your CV, is first you interviewed for that company and if you got the job, you got a title. Then you can put that title in your CV. For us, we have to make up our own title. We haven’t actually worked on a real job as a UX designer, so it was a very terrifying experience because we’re used to somebody else giving us that title, someone else giving us that label. Like you are this rather than us saying to ourselves, I am a [fill in the blank].

I think this is what we need — every individual needs to be able to say “I am this” not because somebody else tells me that I am, but because I know that I am, or at least I believe that I am. I want to be this, and you work towards that. If you want to be that person, you need to say it to yourself. It’s not something that we’re taught to do, we’re told we are something because somebody tells us that we are, and that’s wrong.

Future Trends in Experience Design

Where do you see the industry is going? How shall I get myself ready? Where do you see your future self would venture into?

I can’t predict trend, if I could, I would have already be rich with the bitcoins I should have bought! With that said, I think we should all focus on having a strong foundation ready such that whatever the “new big thing” is coming, we will be in the position to apply our knowledge to it.

If that answer doesn’t satisfy you and you are the kind of person that like to chase trend, another way I would answer this is you can start to pay attention to job boards occasionally to get a sense of what is coming and see is there something that you would like to learn, then proceed to acquire that knowledge.

For example, if you see there starts to be more chatbot designers job around and you are interested, then go ahead to build a chatbot on your own. Then when the trend actually became real, you will be away ahead of other people and would be in a position to say to your potential employer that you have done it vs other people that claims they would be able to learn it on the job.


I have a podcast called UXwanabe. A show that explores how to get into UX and navigate your design career in Hong Kong. The podcast is my attempt to solve the problem for the lack of resources for the local UX community in Hong Kong, you should check it out!

Filed Under: Career development, Most popular Tagged With: UX, UX Design

How to design your own UX process

August 7, 2020 by Tim Chan

If you search for “UX process”, you can find thousands of articles written on this topic. As a new UX person joining a team with no established process, you might be struggled on whom process to follow. I have been there before, and it was confusing.

The problem with following someone else’s framework is that it hardly sticks in your mind and it is easy to misuse it if you don’t fully understand it (As everyone worked in an “Agile” environment can testify). Since each company’s internal process and its UX maturity is different, it is hard to just pick one popular UX process and follow it.

In this article, I am going to walk you through a list of questions you should ask yourself in order to lead a design project from start to finish, and also explain why these questions are important. Based on these questions, you can form your own process that will suit yourself and your company.

Lets deep dive into this.

What problems are we solving?

Before you start designing anything, you need to understand WHY are you doing what you are being asked to do. If you don’t know what you are trying to solve, you can’t judge whether your design solves the problem or not.

Sometimes we are scared to ask why, the environment might make us feel like it is not politically correct to do so because it feels like we are questioning decision from higher up. Our boss might say or think “Why are you asking why? Do you think I made the wrong call? Can’t you just do as I say?”

Decorative image on: Consider what are you trying to solve

The problem with the word “Why” is that it is not welcoming, it feels like an interrogation. It focuses on questioning the person that made the request instead of the intention of the task. Instead, I advocate for using the word “What”. Consider the following:

1. Why are you using blue?

2. What are you trying to achieve by using blue?

“Why” seems like you are questioning someone’s decision, it can be interpreted as “Blue is a bad choice” where “What” invites for participation, it is a discussion: “What is your goal and how does blue help you achieve it?”. Now that we are comfortable asking What, here are some things you should ask when a task is handed to you:

  • What problem are we trying to solve and for whom? What are the pain-points?
  • What do users currently do without our solution? Did they invent some workarounds? This is an important question because if your problem is real and painful enough, people will try to find a workaround for it. Conversely, if you don’t see a workaround, the problem probably is not painful enough. Microsoft Excel does this really well. They basically look at what popular micro is being created and added it to their next release. This exercise helps you eliminate the imaginary problem like “some people might find this annoying” and give you a glimpse on how your design might end up. Sometimes your user’s hacky workaround is a great solution that requires minor modification.
  • What triggers us to solve this problem now? Understand the thought process of your boss will help you greatly as you can tie it to how you present your work. When you understand your boss better, you can feel his frustration or her urgency, and it helps you to avoid presenting a solution that takes 3 months to build when what you boss wants is a hot fix in 2 weeks.

Output

By the end, you should produce some sort of documentation that outline:

  • Why this project exists
  • What are the requirements

I like to add this knowledge into a document called a Project brief and keep it in a share drive such that there is a single source of truth, and I would also email stakeholders as well to keep everyone on the same page. Surprisingly, once it is written down, things become more concrete, and stakeholders are less likely to change their mind.

What is the scope?

Nothing gets done if there is no deadline. There is always room for improvement, there is always the next “minor polishing”. This article itself is also a product of setting a deadline and just hit the publish button whether I like it or not.

Decorative image on: Schedule

I can always come back for the typo or add a picture or two, but if I don’t publish anything, no one can read it, and I can’t add value to anyone’s life. For your project, get everyone involved and ask:

  • How much time do we have? Are we expecting a quick-win or a total redesign? There is no point in designing the perfect solution that takes 2 months if you only have 2 weeks to work on it. Instead, spend your time coming up with a perfect 2 weeks solution.
  • What does good enough look like? When do we know when to stop? At a minimum, your design should satisfy some bare-bone goals. i.e. The user should be able to add items to their cart. Any other good to have stuff like “comparison feature” or “add to my favorite” are Good-to-haves.
  • What use-cases or target user is not covered as part of this project? Having alignment on what you are not doing is just as important as knowing what needs to be done. Make sure this is well communicated to your stakeholders to avoid an unpleasant surprise in the future. e.g. Boss: I thought we are also curing cancer with this release and have already told the higher-ups, now I need to get everybody OT to work on this!

Output: MVP documentations, Out of scope documentation

Has anyone solved this problem before?

There is always more problems to solve than time available, as a smart designer, you want to avoid reinventing the wheel. First, you need to find out has the wheel already been invented. This means:

  • Look inward. Internally, has any teams within your organization faced this problem and solved this? Is it applicable to your case? Is there something we can reuse? Failure to do this step is how inconsistent designs, duplicated pattern and wasted effort occurs. If you company is big enough, someone else from another department has probably solved this before. Make sure they are aware your project exist and talk to them.
  • Externally, how did other companies solve this problem? This goes without saying, if you work in a FinTech, look for what other Fintech company is doing, if you work in e-commerce, look at what other similar company is doing and so on. What can we learn from them? What can we apply to our case? What are they not doing well that should we avoid?

Output: Case-study, Lesson-learned

How does the existing stuff work?

If you are adding a new feature on top of an existing design, you better know how the thing works inside out, or you might break things. Look at existing documentations, play around with the live site, and speak to developers to find out about any tricky logic, interactions or quick fix from the past that has been put together that is vulnerable to big changes.

Decorative image on: Two guys discussing on a document

What is our solution?

Now we start to design the actual thing. You can create sketches, lo-fi wireframe or hi-fi designs, prototypes…etc. It really depends on what you think is best for your company. During this process, consider:

  • What are the different scenarios and use cases? What would your design look in other languages? What does it look like on different screen sizes? Different platforms?
  • What happens when users don’t follow “the right way?” Have we covered all edge cases? If users can add one item to the basket, can they add 300? What does it look like if they do that? Do we allow it? If not, how does the UI convey that to the user? How long are items stored in the basket? Do we need to tell that information to the user? Why or Why not?
  • What are our rationales to make certain decisions? Throughout the design process, we are going to learn a lot of things and make a lot of decisions, are we just going to let that sit in our brain or are we going to make the effort to document it such that other designers and future generations can benefit from our lessons?
  • If we propose this design, does it also impact other areas of the existing design? Who needs to know about this? Other designers? Other developers? Other product managers? Do they have resource to support you?

Output: End-to End user flow, High-level sketch, Decision log, Interactive prototype

How do we know our solution works?

A design proposal is considered feasible when it, at a minimum:

  • Achieves the business goal
  • Can be built within a reasonable time-frame
  • Can be understood by the user

This means two types of people need to look at our work:

  • Internal people — Stakeholders
  • External people — Customers/Users
Decorative image on: A women thinking

Has our internal people agreed to this?

Do developers thinks your design is feasible? Does it require a big change to existing code base? How long would it take? Are there other simpler way to achieve 80% of the result but can take much less time?

Do other designers think we are following the established guidelines? If the design is not part of the guideline, do we need to update the guidelines?.

Do product people think the design achieved their goal? Do brand people think the design is on brand? If you are working on FinTech or highly regulated industry, have you consulted Subject Matter Experts or Legal or any relevant people to make sure your design complies to regulations? e.g. Can you create a One-click to order button?

How much time does the approval process take from all of these people mentioned above? Did the project plan take into account the back and forth? One of the major reason for project slip is that project plan failed to recognize that takes time for people to come into consensus. This won’t happen to you as a smart designer, you will make sure to bring this up during meetings and talk to the right people.

Output: Review session, approval log

Do customers understand our design?

Normally, we want to make sure the answer is Yes to this question before the product goes live. Until we test our designs to the real people who are going to use it, the designs are not validated and we are living in our own bubbles.

In a lot of companies, testing is always thought as a luxury, but the nature of it doesn’t change. Users has to test it no matter what. If you don’t test the design before launch, the shift just became after launch. We are testing the live product to real customers instead of prototypes. Anyway, if we are commit to test before launch, we need to figure out:

  • What format do we want to test? Sketches? Lo-fi/Hifi wireframes? Prototype?
  • Who to test? How long does the recruiting takes? How many people do we need? Who runs the test?
  • How much time does it take for us to organize the findings? How do we present our findings? In what format? To whom? What do we expect to do with our findings?

Output: Usability testing

What do people downstream need?

Now that our designs are ready, it is time to send it to someone else to work on it. Branding people might want to pick the right images, copywriters need to know which area needs copy. In an ideal case, everybody required to make the project happen are involved during the inception of design, if not, we need to spend some time to explain to them how the thing works.

Decorative image on: People discussing around a document

Consider: When will they need it? In what format? Are there enough time for them to review the design and ask questions? For example, you need to tell them:

  • For Copywriter, this area needs a new copy, and we are trying to tell the user about how x works
  • For Branding people, this area needs some stock photo, and we are trying to do y
  • For Developers, this area we are re-using existing component and this area requires new ones, and this is how the animation should work

In some companies, someone else is charged of figuring this out for you, but if that someone does not exist, it is on you. In essence, make sure people downhill knows what it is expected of them and in a format that they understand.

Output: Final UX & UI specifications.

How do you know the design is properly implemented?

Once developers has build something, how are you going to find out it looks and works as you specified? Do you communicate with QA people on what to look out for?

If you are going you review the build, how will you do it? Are you going to eye-ball it? Or use Chrome Developers tools to look at the elements? What if it is a mobile app? What tools should you use than?

How much time do you need for the review? Where do you report the bugs? How do you report the bugs? Are everything tracked and documented?


That’s everything I can think of that requires you to think about when you want to see through a design from beginning to launch. Hope this article helps you in your process and please leave a comment if you have any questions.

p.s. I am aware that product development is a continuous cycle and the design shouldn’t stop when a product is launched. But as the scope of this article is about seeing through from start to launch, what after launch is out of scope.

Filed Under: Framework, Most popular Tagged With: Design, Process, User Experience, UX, Ux Process

How to find the right kind of mentors as a junior designer

July 3, 2020 by Tim Chan

I see this mistake a lot when it comes to design mentorship program. Junior people all wants to talk to the most senior person in the room, but are oblivious of the fact that such approach will have a limited benefit to their career development. This is a mistake because contrary to your intuition, picking a less senior person as a mentor is probably the better choice.

Here is why it is not a good idea to find someone with 20 years of experiences as a mentor when you first started out:

Although they can offer you general direction for your career, they far too removed from what is was feel like when they first started.

I learned this the hard way after trying to offer advise to someone that was trying to get into UX. When faced with a situational question, I realized that I started to mix up what I did versus what I will probably do, my memory was fading away. After all, it was almost 8 years ago since I got into UX.

I certainly lost touch on how it was like as a junior designer. The struggle had now became a distanced memory. Though I can still offer reasonable advise, they certainly did not come from my best thought output. If my advises were a tool to be used in a battle, it would be a rusty dinner knife instead of a sharp Samurai sword.

My brain has been preoccupied by current matters. My skills sets has been transformed to serve the managerial role, such as how to manage a UX team, setting design directions, stakeholder managements…etc. Those are the things that I have been thinking, living and breathing everyday. Those are the things I am most qualified to talk about and can have meaningful contribution to the conversation for anyone wants to discuss on such matter, or is interested to grow into this role. Anything else, I am not best person to talk to.

Who to look for instead

To gain the most from your mentorship program, you should look for someone that is just one level above you, someone that has just done it, or is currently doing it. For example, if you want to get into UX with no design background, talk to junior designers that just landed their job. If you are a junior designer, seek mentorship from a Senior Designer instead of the Director of UX.

Seek out the “just made it” person if you want immediate actionable advice, and the seasoned veteran if you want general guiding principle for life. Don’t mix up the two, or you will be wasting your time and theirs. Hope this helps!

Filed Under: Career development Tagged With: Mentor, UX

What it’s like working in Agency, Startup & Corporate

May 2, 2020 by Tim Chan

An illustration of a group of people chatting

Picking an industry is hard when you first started out as a UX designer as you hardly know anything about them. It is even harder in Asia, as there weren’t many resources that is written around this region.

Having born and raised in Hong Kong, and have worked in Agency, Startup and Corporate, I want to share with you my personal experience and feeling on what it is like working in there, such that you have more idea to help you make a decision. Remember to not just take my word for it as every company is different.

Agency

Pros

Exposure to clients — The advantage of being an outside firm is that you can navigate around the client’s corporate structure and have chances to meet and present your design to C-level stakeholders directly. This forces you to become good at public speaking and if you can impress clients, you will be on a smooth path to promotion.

Experience the whole UX design process — You will have the opportunity to run user interviews, do prototyping, run usability tests… all the standard UX process. The reason you get to do all that is because nowadays firms charge clients for all these activities, so it is good for you that you can put all these UX artifacts into your portfolio.

Huge earning potential — The salary is competitive, and there is also opportunities to earn more. When you become a manager, your job became a sales person with design background, and you will have to fulfill a quota and bring in clients. You get commissions a for the clients you bring in and if you are good, the earning potential is much greater than working in-house.

Perks — To retain people, the company is willing to spend money on events such as boat trips, Hackathons, game nights…etc. There are also a lot of learning resources that you can tap into, if you have the time to read it.

Exposure to different projects — You don’t have to worry about getting bored or feeling stuck working on the same project for too long because there is always variations on the type of clients that comes from different industries.

A morden agency office
Photo credit: The Secret Little Agency

Cons

Stressful— Agencies in Hong Kong can be very stressful. Leaving work at 10 p.m. and working on holidays/weekends is not uncommon. I have had the unfortunate experience to witness someone worked 30 hours straight and another person worked until 4 am to prepare for a client presentation.

Workaholic culture — People in agencies are willing to give up their personal time to get things done. They would take weekends into account as workdays, and I have also seen people asking for manager’s permission to leave work “early” at 7 p.m.

Poor project management —For an agency, taking in all the clients they can when the market is good is all that matters. Higher up decides the deliverable date with clients and designers where not part of the project planning meeting. This leads to the firm taking in more then they can digest, and as a result the downstream suffers from impossible timeline.

Improper UX deliverable — On the surface, UX designer gets to do standard UX process such as user research. However, these activities are often not completed in a professional manner due to the lack of formal training on UX methodologies and lack of time to properly digest and analyse research findings. In the end, it just became a checkbox item in the deliverable that says “we done it”.

Lack of knowledge sharing — Due to the stressful environment, turn-over rate is really high. The consequences of this is that knowledge is not well documented and passed on. People are forced to keep reinventing the wheel on occurring problems such as “Techniques on handling clients” or “How to run workshop” since they don’t know what is the best way to do things.

Unclear project goals—People that pitches the deal to the client, the designers that do the work, and the people that represent the client are all different group of people. Hence, communication problem occurs as designers has no idea what the sales people sold to the clients. What is the project goal? What is the customer’s pain-point? The answer usually exist in vague form such as “The goal is to rebuild the client’s website and the pain-point is the website is really outdated”. In this kind of environment, designers is nothing more than glorified pixel monkey.

Startup

AirBnB office
Photo credit: AirBnB

Pros

Get to wear many hats — In a startup, there isn’t a lot of people around, so you get to do a lot of things. Apart from design, you might have to work on the project plan, write copies and even do a little bit of QA. It gives you the learning opportunity to understand the different kind of jobs that contributes to make a software company work.

Flat culture —There very few layers in the chain of command, this means quick decision making process and often times this is what a UX designer need because this gives them the freedom to try new things, fail, and iterate their design.

Rapid promotions — It is much easier to get a promotion because there are not many people around, and startups is often more generous to offer promotion as a way to retain their employees, as an alternative to huge salary raise and as an incentive to make employee stay longer.

Encourage innovation — For startups, they are still figuring out what is the direction for the company, so the culture encourages innovation and coming up with new ideas. It is much easier to get management approval on trying out new technology or new frameworks.

Flexible working hours —Most startups don’t need your physical present, for that reason, more and more company has allowed their workers to work on flexible hours and work from home as long as work is delivered on time.

Cons

Low pay —Unlike Sicilian Valley or the western scene, startup around here is not known for their high pay, according to Startups HK:

Hong Kong startups will start off at HK $15,000 for fresh grads / junior level and will pay up to $60,000 per month for advanced designers, which works out to about US $23,000 and $93,000 a year respectively.

That’s why they usually make up for it in coffee machines, ping pong table, snacks, couches and beer Friday etc.

Weak brand —If your the startup is not well-known, people don’t know what you do and might also have wrong perception on your design ability because startup tends to have a more relaxed hiring restriction compared to big companies. i.e. People with less or no formal design experience is hired

Lack of structure —A company that is just starting out will not have a strong structure. You will be expected to figure things out on your own with no guidance. Oftentimes you will not be able to get the feedback you want when you needed it. For example, it is impossible to gain any good design feedback if your manager is not a trained designer.

Lack of resources — Startup usually does not have a lot of spare resources to go around, so sometimes they will not be able to pay for the seminar you want to go to or spend money on usability testing, less bonuses…etc.

Lack of Job security — Unlike an establish corporation, a startup can go out of business any time if they run out of funding or fail to find product market fit.

Work gets repetitive — In a startup, you might be only working on one product or one app. This can get boring pretty quickly after 1 or 2 years.

Lack of growth — Because of the small team size, the likelihood of meeting someone smarter than you is much smaller compared to a company with a bigger team size. In the worse case scenario, you are the smartest UX in your design team, and that severely limits your ability to grow.

Corporate

A photo with a group of people holding gears

Pros

Resources — Corporate has money. They can afford to invest in their designers on luxurious items such as paying them to go to conferences (e.g. Nielson Norman Conference), setting up a design system team, creating a UX copy writing team, or even hire a team of researchers. This helps to take some of the burden off the UX designers and everyone can also learn from the experts from these areas.

Brand — A big corporate with a good brand helps people to understand who you are and what you are capable of. Working in a well respected company quickly implies your ability.

Well paid — Smart people can command high salary, and big corporate can afford to pay them that amount and that also benefits you. This also means you have a higher chance to work with smart people compared to small companies that couldn’t afford them.

You can specialize — In a small company, you might have to wear many hats, for example, UI design, copy writing, and run your own research. This may not be ideal if you prefer to focus on just doing one thing. In a big company, things are more specialized and you get to go deep on a subject.

Change jobs without leaving the company — With so many products and projects with their own budget and management team, a big company can be seen a collection of mini-companies. If you are not happy with where you are, you can apply to other teams and start fresh without the hassle of leaving the company.

Good perks — Above market norm on paid vacation days, good coverage on medical, insurance, housing allowance…etc.

Big impact of your work— As a designer’s own satisfaction, it feels good to know that your work that can be used by a lot of people.

Cons

Everything is slow— Project often involves multiple stakeholders and decision makers, and this inevitably slow things down and impact the efficiency. Project takes at least 3 months to complete compared to 3 weeks in a startup. For those that are impatient, this may feel incredibly slow.

Work on a small part — You become a small cog in a big machine, this means that sometimes you are working on a small part of the product or doing changes on existing design, instead of building brand new product for features from scratch.

Politics —This is inevitable when the place is full of people. It is common to see people fighting for attention & resource. You don’t have to be a part of it, but you must learn the rule of the game, and how to deal with it.

Difficult to get recognition — In a big company, one must work extra hard to gain noticed, otherwise you boss might never know what you do (or even that you exist). If your work is not recognized, it is very hard to get a promotion.

Illustration of 2 person connecting with each other

Conclusion

Depending on your UX journey and what you want in life right now, there are two strategies you can use in terms of finding the best industry that suits you:

  • Prioritize getting a UX title
  • Prioritize learning

Prioritize getting a UX title

If your resume doesn’t say you are a UX designer, you can basically forget about big corporate and agencies if you go through the front-door of applying online. You will never get pass HR. If you knew someone inside or you can strategically reach out to the hiring manager, that is another story.

Generally speaking, you would have better luck to work in a startup as the barrier of entry is much lower. Here is how I rank the difficulty of getting into each of these industries with zero design related background.

  1. Startup
  2. Agency
  3. Corporate

Prioritize learning

If the most important thing for you right now is to grow, you should start with a big corporate with a mature UX team. Corporate has the right structure, people and resources to help you achieve that goal. Be careful though, just because you are dealing with a big company, it doesn’t mean the UX team and its process is well established. Make sure you find out about their UX team size before you apply.

However, big corporate is hard to get into as they prefer to hire people with more experience. In that cases, consider going after agencies. While it maybe stressful and demanding, you get to learn a lot of the soft skills such as presentation skills and the art of addressing stakeholders concern, which will be useful for the rest of your career.

Now if everything else fails, go for startups where the barrier of entry is lower. You still get to learn and do a lot of different things such as research, where in a big company it will be considered as someone else’s job.

Filed Under: Career development, Job interview Tagged With: Careers, Review, User Experience, UX

  • Go to page 1
  • Go to page 2
  • Go to page 3
  • Go to Next Page »

Primary Sidebar

UXwanabe newsletter

About

Hi, I am Tim Chan, I want to help you get promoted as a design lead!

Previously, I lead a team of 10 at HSBC as a Product Design lead.

I share my experiences, mindset & strategies on how to climb the design ladder in my newsletter.

Recent Posts

  • Are your design policies a “House rule” or “The Law”?
  • How to choose which battle to fight as a designer
  • Why you fail to influence stakeholders as a designer
  • 2022 in Review
  • 10 Lessons I learned working in a global bank as a designer

Copyright © 2025 · Genesis Sample on Genesis Framework · WordPress · Log in