UXwanabe

Learn the softskill of UX and grow your design career

Product Design

How to choose which battle to fight as a designer

by

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! 

Why you fail to influence stakeholders as a designer

by

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! 

10 Lessons I learned working in a global bank as a designer

by

To wrap up 2022, I am sharing 10 lessons I learned working 4 years as a Product Design Lead in my previous role at HSBC.

Working in a big corporation like this is complicated, I have to deal with a lot of stakeholders, understand the rules, the un-spoken rules and at the same time trying to help the design team gain more influence.

These are the lessons I wished someone could have taught me when I first started. Hopefully you found these useful and avoid the same mistakes I made!

Warning: It is a long read, but I promised you will find value in it!

1. There is a glass ceiling that’s ok!

Let’s face it, it is unlikely a designer will ever become a CEO in a traditional bank. Having a “Head/VP of Design” or “Chief Design officer” is as good as it gets. It doesn’t matter whether management truly support design team or not, there is a glass ceiling. Why? Two reasons:

  1. Nature of business
  2. You are not actually building the product

Nature of business

Instagram cannot exist without their product because the product is the business. A traditional bank doesn’t sell digital products, their apps is just a way to make your day to day transactions easier, it makes money through mortgages, credit cards, loans and all other kind of financial products.

Just because a traditional company “went digital” doesn’t magically turn them into a digital business. In simple words:

  • The bank is not too screwed if nobody uses their app.
  • Instagram is totally screwed if nobody uses their app.

Bluntly put, the app just needs to be good enough for a traditional bank. If the rates and fees are good, customers has a very high tolerance level to their digital products. Hell, they don’t even want to stay on a banking app for that long, who really wants to use a banking app anyway? Have you heard anyone addicted to their banking app? Me neither.

You are not actually building the product

When you design and UI for the bank for whatever product they are selling, you are not building the product, you are building the digital representation of the product they are selling. Their “product” is whatever mortgages, credit cards, loans or wealth portfolio they come up with. You see, their product already exist in a form of digital document that is 30 pages long, and what you build is a sign-up form or dashboard for these products.

Wouldn’t it be nice if the UX is really nice? Of course! But in the end of the day, the specific details on product such as “rates” or “returns” are what matters, not the design. 

To recap, the nature of business limits the impact you are going to make since you are not actually building the product. And that’s ok! Design team doesn’t need to make it to the top for every company out there. It is important to understand strategically what you can gain from each company you work for. The ceiling doesn’t matter as long as there is still room for you to grow and someone to learn from. 

For me, my goal was to become a better strategic thinker and a better presenter. I had a great manager, and worked with other Service Design Leader and Design System Leaders that I learn a great deal from and that’s why I stayed for a long time even though I understood eventually I will hit a glass ceiling. Always have a plan on what you want to gain for each role and move on when you have learned everything from there.

2. Learn to influence or you are doomed

It is extremely important for us as designers to understand the fundamental reason why influence is an important skill to master as a designer. Everyone said so, but why? For getting a raise or promotion? For a happier design team? For your mental health? I argue that it is a matter of survival for the design team. Here is why:

  1. A team needs resources to survive
  2. Every team wants to survive (aka have a job and don’t get fired)
  3. There is limited resources in a company

A team that doesn’t have resources does not survive by definition. Following the same logic, the maximum survival strategy is to have as much resources as possible, ideally ALL the resources of the company.

Realistically, you can’t control all the resources in a company, but the bigger the pie the better. To get resources, you need people that owns the money to give it to you. People usually do it by:

  • Convince decision maker to give them more (you should do this)
  • Undermine other teams so decision maker won’t give money to other teams (you shouldn’t do this)

Why can’t we just chill and not do anything? Why can’t you remain a small team and just do your own thing? Well, because the design team consume resources. Other team has the incentives to want to kick you out if they don’t think you are valuable so they can have a bigger piece of the pie (according to point #3 and the maximum survival strategy stated above)

Furthermore, there are 2 more uncontrollable factors that you can count on that are guaranteed to happen if you remain in the same role long enough. They are:

  1. Economy going south (already happened as per writing this article)
  2. Old management leaves and new management comes onboard

Whenever the above thing happens, the first thing the leadership team do is to see which team is non-essential. If you want to survive, part of your job is to constantly remind people with money why your team is essential. The art of convincing leaders and peers from other department is called Influence. The better you are at do it, the safer your team (and your self) is when things eventually go south.

3. Ask for forgiveness, not permission

It is a big company, if you ask for permission to do the right thing all the time, you can’t get shit done. The key is to do it anyway and think of a good way to say sorry if people complains. Make sure to inform your boss so they have your back before you do that thing.

For example, when I worked in the Staff digital team responsible for building tablet apps for staff to serve customers in the branch, I wanted the front-line staffs to test my design on their tablet. If I emailed the branch manager, I am 99.99% sure they will reject my request because it will “distract their work” and we didn’t have a relationship.

So I just went to the branch and have a “private” conversation with the staff there. Nobody knew I wasn’t a real customer and if the staff generally want me to go away they will just say so. Truth is, everyone in the branch is happy to be beta testers on new features and they didn’t report me to their boss because I made them feel important and I genuinely value their feedbacks.

A lot of times, what you think you cannot do is just a mental barrier. You can always do something, there are just consequences that may or may not occur. If you are in doubt, ask yourself “what is the worse that could happen?”, the reality is probably not as bad as you think. My general rule of thumb is do whatever you think helps your team as long as it won’t get you fired. Worked great for me so far.

4. Understand the REAL WHY

The difference between an order taker and a professional is the ability to take control of the situation. A professional knows what they are doing and won’t let other people boss them around. Have you seen a great doctor just let other people tell them how to do their job? No, they take control of the situation and ask questions.

Business said X, Legal said Y. Why? who exactly said that? Who the hell is “business” or “legal” anyways? Behind any enquiry, there is a real human behind it, why can’t we as designers apply empathy and understand their hopes, fears and dreams? What is their concern? What worries them? Is it a power move so that they feel they are in control of the situation?

In other cases, you want to show strength as well. Show people you won’t back down if the other side is not prepared for a fight. Anyone can throw out unsolicited opinion, very rarely do people work hard to form comprehensive statement based on facts. Have the courage to challenge what people say by requesting evidences to back it up! 

For example, if stakeholders insist to change a design that has worked in the past but they want to change it because they have a different OPINION, kindly remind them you do value their opinion (maybe not really, but you say that anyway because your parents taught you manner so you act nice), but this design has proven to work in the past, “what” are the evidence to support what they believe what they suggest will improve the UX? How confident are they?

If you change your design because other people demand it every time regardless of their seniority, you are a vendor, you are “just here to make things pretty”. You are an order taker. If you have a choice between being an order taker or being a professional, which would you choose? I know my answer.

5. Own your boundaries

You need to let other know your boundaries and stick to it, or someone else will set it for you. If you don’t want to join a lunch meeting, don’t join. If you don’t want to join a 7pm meeting, don’t join. (This doesn’t apply to teams that cross time-zone, in this case, do the fair thing where sometimes you have late meetings and other times the person in the UK does the same thing).

You have more power than you think. Sometimes we felt that we can’t say no to unrealistic demands, but what is the worse thing that can happen if you reject a stakeholders demand? Come and drag you to a meeting? Download Figma and draw it themselves?

Probably nothing.

The best they can do is complain to your boss, but if you have articulate your point clearly with evidence to backup your decisions and let your boss know up front, you have nothing to fear. 

Don’t let others dictate your workflow

Inevitably, someone will ALWAYS send an “urgent” email and demand a reply “ASAP”, as if whatever project they work on is always the most important project for the company. You will feel the impulse to pause everything you do and reply to that email.

Don’t do it. Two reasons:

  1. It probably isn’t urgent
  2. Rushing your reply will always make the situation worse 

It probably isn’t urgent

Think about it, what is really “urgent” in our role? Do we control the finance operation or the IT systems? Will the designers be able to do anything if someone hacks the system? Unless payroll made an accounting error where your CEO’s three-million bonus now shows up in your bank account and they want it back right now, nothing is urgent. 

Just because someone higher up wants an answer quickly so they don’t have to remember it and ask it again in the future doesn’t mean it’s urgent. It just means they will get annoyed if they can’t get an answer now. Just because someone came up with a deadline without consulting you doesn’t make it urgent either. It is their problem.

What happens most of the time is that nothing happens if you don’t reply to the email immediately, the other party will often send a follow up email a day or two later chasing you or send you a Slack message at 6pm the same day. As a rule of thumb, if the matter can wait until 6 pm or one to two days later, it is by definition not urgent. 

Have a list of priorities for your team and yourself. Everyday, create a checklist with no more than 3 items and work ONLY on those things. Mentally have a Standard Operating Procedure (SOP) on when you check your communication channels and how long it takes for your to reply. I set a rule for myself where I batch read emails in a specific time in morning and in the afternoon and never read it in between, this way I am free from distractions and focus on real work.

If an email comes it that do require your immediate attention, weight against your checklist and think “If I do not complete the tasks on my checklist and reply to these emails, will it benefit myself or my team”? Only reply to those emails if it is the later case. In the end of the day, you are not judged on how fast you reply to emails, you are judged on how well you can perform on your job. You work on your priorities, not someone else’s.

Rushing your reply will always make the situation worse

OK, let say the email is truly urgent and a project can’t go live today if you don’t reply to it right now. What do you do? Write a reply immediately and send it? Wrong.

Everything you wrote in haste are almost always not thoughtful enough and everything you wrote ill be used against you. I never had a good experience when I reply quickly to an important email, either my facts is off or the tone is wrong and I end up writing multiple follow up emails or have to eventually jump to a Zoom call to explain things. 

Take your time to collect information around the subject and compose a response but DON’T SEND IT YET. Send it to someone senior or someone you can trust for a second opinion to ensure you have covered things from different perspectives when the email is truly urgent. 

6. Process and documentation are your best friends

If you find yourself explaining same things over and over again to some people, it is time for you to create a process. There are two key benefits of creating a process:

  1. Process allows you to do more work with less time, why? Because once you wrote down how something works once you can point people towards that instead of explain things 1000 times. We are in business of deep work, this means that it takes time for a designer to warm up to get into a state of flow. While it may take you 10 minutes to explain how some things work, it will take you at least 30 minutes to warm up again to get into the state of the flow. 
  2. Another benefit of a process is it also helps other to repeat the success you had so you are making the team become more productive. For example, create scripts for the team to answer common stakeholder questions regarding design rationale. This is one of the ways you can scale your team and make yourself become more valuable because you remove yourself as the bottle neck.

Same logic applies to things like creating documentation on decision made for the project. I can’t remember how many times my team asked me for a decision I made about a design and it was a pain to go through all the email and Slack messages. Now I just simply wrote down important product decisions and ask whoever to refer to that document.

7. Policies gives you credibility

Do you hate it when you ask the same questions from two different person under the same department and getting 2 different responses? It happens quite often in a big company, it feels unprofessional and I certainly don’t want other team to feel the same towards the design team.

Stakeholders will often challenge your or are just generally curious — “Why did the design team made that decision and what was it based on?”

If your team had exist for a while and you haven’t codify your thought process, you are not running it very efficiently. Having a clear policy document helps free you the headache of coming up with an explanation ad-hoc, make your decision more transparent, and avoid giving contradictory answers. Ultimately, having clear policies will help your team earn respect from others because someone (you) has taken the time to think about how your team make decisions.

A policy is a way to articulate our thinking process. Once you articulate it, your rationale became clear. People can debate around it and you can work on improving it. If you have a good policies in place, you can save your mental energy to react to the outliers, not repeatable problems, the HARD problems. Most importantly, it allows you to scale the team because everyone on your team understand your rationale so they can act on your behalf. You remove the scenario where Designer A and B will give different answers under the same situation.

Creating a policy is not that hard, you start with the most common questions stakeholders ask and document what your team replies. Then, extract the most convincing argument or rationale from those replies and you have your version 1.0 of your design team policy. Basically, if someone asks your team a hard question. Ask yourself is this question likely to come up again/ has it already been ask, if so, create a policy to handle similar situations in the future.

8. It’s a marathon, pick your fight strategically

A real leader focuses on the big picture and pick their fight carefully. Your bigger goal for the design organization should always be demonstrating the value of design and drive design maturity of the business. You don’t need to win every battle, you just need to win the war. Otherwise, you will make too many enemies along the way and you will be so sucked into debates that you can’t work on the important things.

Picking a fight is an art on its own. Is it important to CC everybody when the developer misses the UI by one pixel? (Pro tip: no) What is something that you should never back down? Where do you draw the line? One helpful exercise you can do is to list out the design policies from your team. Then, as a team decide on which policies is the most important and rank them in descending orders.

For example, you might decide the following policy must be followed at all time: “We always conduct research on new features or when we work on project that lasts longer than x month” while the next one is negotiable: “all designs should follow the latest design system unless an exception has been obtained”. 

This way, you communicate effectively to your team what is strategically important and you can focus your effort on battles that are meant to be won and be okay to lose the less important ones without diverging from the big picture.

9. Make sharing your work your top priority

Share your work constantly instead of doing it as an after-thought — It is not other people’s job to know what you do. It is YOUR JOB to sell yourself and to educate other people the value of design, how it can help the business and how it can help THEM. 

In a big corporate, if a tree falls in a forest and no one is around to hear it, it doesn’t make a sound. One of the mistake I had was not putting enough time to selling our team to the wider organization, so our team are essentially invisible to the higher ups. Not good. As a manager, if you learned that your team didn’t have time to share their work because they are busy, guess what? It is your job to do it now. As mentioned in Point 2 above, this is essential to the long term survival of your team.

Think strategically on who you want to sell your work to, which project to sell, what is the message, the communication channel, frequency and what is the ask for the audience. What call-to-action do you want this person to do? More funding for your team? Public praises? Show up in the next usability session? You want to make it clear. Spend more time to figure out how to best position yourself in the organization and you will have an easier time climbing the corporate ladder.

10. Find the best and learn from them

It’s a big company, it is full of very bright people. However, by nature of normal distribution, 90% of people are mediocre, 5% are top performers, the rest are waiting to get fired. Focus your time on the top 5%. Analyze what they do, how they sell themselves, how they do problem solving. What are they doing that you are not doing? How can you close that gap?

I don’t have the brightness mind in the company, but it doesn’t matter. I can observe good people and learn from them. I used to keep a journal of top performers of the company and I constantly ask myself what is their mindset, what are they doing right now, and what would they do in this tough situation? 

If you are able to articulate WHY someone is good, WHAT makes them good and HOW you can close that gap, you will have a great lead in personal development.

How to interview for an UX position

by

Insights from a designer that became an interviewer.

Last week, I interviewed someone for the first time. It was for a junior UX designer position and for all my professional careers, I have been in the interviewee’s seat. Being in the opposite end of the table has been an eye opening experience for me, and I have learned few things that I wouldn’t have otherwise.

In this article, I want to share some insights I learnt that would help you interview better for an UX position, so here it goes.

Insight #1 — Your interviewer is on your side.

Look, I might have a Senior in my title, but I am just a designer that is looking for another designer to help me with my job. As an interviewer, I am not here to test you or throw you a challenge. I am actually on your side. Why? Because…

Company hires to solve a pain.

When a company decides to hire someone, they are in pain. They are at a point where they either A) Figured out putting the designers on over time just wouldn’t produce the same kind of work Bob did before he left 3 months ago or B) Needed to do something but they don ’t have the knowledge or time to do it themselves.

Hiring people costs a lot of time and money. Especially in the time where everyone can take a weekend course and slaps a “UX designer” title on their LinkedIn profile. It takes a tremendous amount of time just to figure out whether someone actually does UX or UI, or is just simply does not have a clue there is a difference.

The interviewer’s job is not to screen out people — screening out people is just a by-product. His job to find someone to fill a role that they desperately need as soon as possible, so he can get back to do his work, the work he is paid to do and hopefully get a raise he deserved.

This is were you come in.

Insight #2 —The interviewer wants you to be THE ONE.

Any decent company gets hundreds of resume sent to their mailbox when they post something on the web. By nature of normal distribution, 80 % of them are mediocre, 10% of them are terrible. The hiring manger have to sort through the pile of resumes and hopefully find those 10% that is qualified, then persuade them to work for him.

Imagine being a hiring manager. You start screening for potential match, finding and arranging time that works for both sides, coming in at 7 a.m or staying late after work because your candidate can’t take a day off, then during the interview, the candidate does not show up. Or when they do show up, they completely blew it and have no idea what they were talking about. Maybe you found someone that was really good, but you don’t have the budget for what they asked for. In other cases, after a few rounds of interviews and an offer was given — just before you think the dust is settled — the candidate turned you down and has accepted an offer from a competitor.

Most interviews takes at least an hour, realistically you can only do 3 to 4 interviews a day. Sometimes a bad interview just completely ruins your mood and you start to question whether there are still good people out there, and you can’t focus on your work for the rest of the day.

The point is, interviewing people takes a lot of energy from the hiring manager. It is exhausting. In the end of the day, the hiring manager just wants to go to his boss and say “This is our guy, give him an offer”. This means that he is secretly hoping that this interview — the one you are having right now — would be the last one he has to give. He wants you to be the one.

Why am I going so lengthy about the hiring process? Because I want you to have empathy. Hiring managers is people too, they have their own hopes, fears and dreams. As an UX designer, you should already know what empathy is don’t you? Once you start to treat your interviewer as a person and understand their pain-points, you will start to operate in a total different level.

Now off to some tips about how to interview for an UX role.

Tip #1 — Defend your work, not yourself.

When the interviewer asks you about the design decision you made on your project, it is easy to get defensive because you see it as an act to question your ability in delivering good work. You are defending you instead of your work.

In fact, I would argue you shouldn’t even defend your work. Defend implies having your guards up and fighting off anything that is coming to your way. Once you start doing that, you put yourself in a disadvantage. You are not ready for a discussion, you are ready for a fight. You are now fighting to justify why you should be in this room instead of selling why you should be right fit.

Here is a little trick to avoid being defensive: Assume good intentions. This means assuming the interviewer is genuinely interested in understanding how you make decisions.

Think of the interview process as an usability study and the interviewer is your user. Examine questions coming out from the interviewer with a scientific lens and treat this as an opportunity to improve your presentation skills. He is confused about something you said or did. Why is he confused? What doesn’t he understand? What does he mean by saying that? Why is he asking this question? Does he have other ideas about the project that you haven’t thought of?

Tip #2— Answer the question

It is easy to get defensive when the interviewer asks you about certain choice you made. When you haven’t thought about it, it puts you off guarded. You don’t want to be seen as a designer that hasn’t thought through things, so you start going in circles and making things up, but you are not really answering the question.

This puts the interviewer in a weird spot because he will start to wonder if he ever asks you to justify your decision, will it take him 15 minutes every time to get to the bottom of things?

Its OK to not have answers to things. We have all worked for someone and we understand that in the perfect world we want to do everything “properly” such as running analytics to see whether our design performs better than the old one, or run surveys to record users satisfaction about the new design.

Of course the world is not perfect and business is full of constrains, so an answer like “No we did not measure whether the new design perform better because the problem was urgent and we needed some fixes real quick. Our new design was based on our own experience and industry best practices. We hope that we can go back to revisit it when we have the budget in the future.” is sufficient in most cases.

Tip #3— Lead the interview

When the interviewer asks you to walk through your portfolio, he is asking you to lead the presentation. He is no longer leading the interview now, you are. You own the stage, so start act like a leader and act like you know what you are doing. For the next 10 minutes, the stage is yours.

Tell them what the problem was, and the kind of research you did to uncover things you didn’t know before. Tell them the surprises, then tell them the kind of designs you tried and how you picked the final winner.

This is the part you should not screw up. I will give you the benefit of the doubt when I am the one asking you questions that is not related to your portfolio, because you might not have thought about it. But questions about your portfolio? It is your work and you should know it by heart. I assume you have practiced your presentation at home. You should know your stuff inside out, you should expect when and what the interviewer is going to ask you and be able to answer any questions with confidence.

Don’t literally walk through your slides pages by page though, you should adjust your presentation based on the audience. For example, the Head of Marketing might want to focus more in the before vs after and the results, while the UX manager might focus more on the process you went through. Adopt your pitch such that you keep your interviewer engaged.

Tip #4 — Make it hard to say NO to you.

As mentioned in Tip #2, in the end of the day, the hiring manager just wants to go to his boss and say “This is our guy”. What this means is that as an interviewee, you should do everything you can to make it hard for the interviewer to say NO to you.

How?

By removing all hesitations the interviewer might have about you. As an UX designer, apply the technique you learnt from UX and treat yourself as a product, then identify your flaws and solve them one by one. Ask yourself; “If I were in the interviewer shoes, what kind of questions will the interviewer have in his mind that I need to address as soon as he meets me? What are his biggest concerns? Which part of the interview process will he likely to drop-off (decides I am a NO-GO)?

Sometimes you don’t have to be the best designer out there to get a job, you just have to be better than everyone else that came to the interview, and this simple thought exercise might give you the extra edge.

Conclusion

While we as UX designers are good at designing user experience for digital products out there, it is easy to lose sight that we are in fact a product too. And how we position ourselves, and how much we understand about our users — determine whether the product — us, will sell or not.

If you can get an opportunity to interview someone, or just simply sit-in quietly and take notes, do it. It was a truly eye-opening experience for me and I guarantee you will learn a lot about how to become better at interviews. Until next time, may you apply empathy to everyone around you.

How to design for constrains

by

A case study on designing loading state

I like to consider design as a spectrum. On the left hand side, you have the Minimal Viable Product (MVP), the absolute bare minimum you can do to ship the product. On the other end, you have the Dream UX design, where I define it as the “If I have infinite time and resources this is what will I do” kind of design.

The challenge for every designers is to push their design towards the right hand side as much as possible while considering about the constrains. In a company, this typically means time and resources. How one can embrace this constrain and thrive in this environment is what separates novice and seasoned designers.

In today’s article, I want to walk you through how I designed loading states for Vyond, a start up I previously worked for. Where we slowly tweak our designs based on different constrains and finally coming up with something that strikes the balance between UX and available resources. Lets get right into it.

Background

When we were redesigning the Vyond product the Video Maker a year ago, we took a lot of shortcuts to hit the schedule. As a result, we didn’t create any loading states and is causing some frustrations to our users. Now that we have time, we decided to fix this.

Why is loading state important?

Loading states is a way for a system to tell users that it has received their command and is now working to make things happen for them. Without a loading state as a feedback, users won’t know what is going on and it violates one of the top 10 principles of usability design — Lost of control.

Understanding the problem — Talking to Engineers

To create good loading states, first we need to understand how things are loaded in the back-end. At this stage, you basically ask 2 questions:

  1. Can it be done?
  2. If yes, at what cost?

Here is an example, in the below UI, we are going to display a row of templates for the customer to use. We want items to load one by one from left to right. Can it be done? The short answer is yes. However, developer told us that there is no way to control which item to load first because items comes with different file size, and they will appear as soon as they are rendered. Which means item 3 might show up before item 1 if the file size is smaller.

← Expectation: we want items to load from Left to Right | Reality: items shows up in whatever order they want depending on its size→

The only way to load item from left to right visually is to wait for all items to finish loading, then displaying them one by one from left to right. This means users will spend more time waiting and staring at the blank state. This goes against one of the purpose of the loading state, which is to mask waiting time!

The importance of talking to Engineers

As you can see from the example above, understanding whether our ideas is feasible up front saves us time from designing something that will never see the light, and we can spend our time to focus on something that can actually work.

Another important thing from this exercise is helps us to have a better understanding roughly how long each component will load, so we can design appropriate on each scenario.

In case you are curious, for the above example, we decided to use skeleton loading in the end to help mask loading time.

Continue iteration

Let me show you another example. In the below UI, when user clicks an item from the left panel, the item will show up on the blank area on the right hand side.

Here is how the interaction works:

  1. Click an item from the Library.
  2. After a short loading time, the item is shown on the Stage.

Originally when you click an item, nothing happens. You will be staring at a blank canvas for 2 seconds before the item finishes loading and pop up. The delay and lack of feedback makes user feel the system is not responsive and triggers user to repeat their action. Which causes user to add multiple items unintentionally, and they have to wait even longer.

The Dream UX vs Reality

To approach this task, lets start with the dream UX, the holy-grail:

In an ideal world, when you click an item, item is shown immediately on the blank area.

This is what The Dream UX looks like, zero loading time!

Of course in the real world, items can’t appear instantly because it takes time to load them, but I don’t take “impossible” for an answer until it was proven, so I decided to ask the question:

Is it possible to render items immediately when we click on it?

The answer is yes…with a cost. Item takes time to load, if we want to have the appearance that items is shown immediately when we click on it, we have to preload the items in the backend. It is similar to when you download a big file, you decided to browse Facebook for the duration. Since you are preoccupied, you have the perception that you are not waiting for it to download, but the file is still taking its time behind the scene.

To achieve the “immediate response” effect, we need to “hide” the preload time somewhere such that users don’t feel like they are waiting for us. When user enters the Vyond app, we show them a loading screen before the app is fully loaded. Can we add this loading time to the loading screen?

Loading screen for Vyond’s Video Maker app

Yes we can! This is how we imagined the flow would look like, after the “Item loading” time has been absorbed by the “App loading” time:

The Item loading time is absorbed by the app loading time

Here is the catch, we have more than 20,000 items in our library. If we preload all these contents in the loading screen, this will take us more than 5 minutes. That’s quite a long time to wait, compared to the time to loading an item which only takes about 2–3 seconds.

Expectation vs Reality. Putting Item loading time into App loading time actually makes loading longer

Someone on our team suggested that can we preload only the items “above the fold” — items that are visible to users without them scrolling. The problem is that having instant access to those items doesn’t help us to achieve our goal of having 0 loading time, since this approach only benefit only roughly 100 items that is above the fold.

This is a time for us to pause and ask ourselves the big question —Is it worth to keep thinking about this direction?

As product designers, it is always important to keep asking yourself this question. Because you always have limited resources and a lot of problems to tackle, spending more time on this problem means you will spend less time on another problem.

In the end, we decided that we have tried our best for this 0 loading time direction and it didn’t work. Let’s find another way.

Building the gap

OK so we can’t show items instantly on the canvas, but we can try to do other tricks to mask the loading time. Below are some ideas:

Idea 1 — Real size selection box

  • When user selects an item, show its selection box but without the item inside it, the selection box has the same size as the item the user selected.
  • Display the real item when it finishes loading

What I like about this idea — It is clear that the item is loading and it helps to mask loading time

Why this idea does not work — Showing a real size selection box requires the server to load the size data of the item, this means until it can get that data, users are still staring at a blank screen and the loading time remains unchanged.

Idea 2 — Fake selection box

  • When user selects an asset, show a fake selection box. The fake selection does not represent the size of the Real item.
  • The fake box is replaced by the actual item when it finishes loading.

What I like about this idea — It gives instant feedback that the item is loading.

Why I don’t like this idea — After all, the selection box is fake and does not represent the actual size of the item being selected.

Idea 3 — Thumbnail images

When user selects an asset, show its thumbnail. Thumbnail is replaced by the real asset when it finishes loading.

What I like about this idea — It gives instant feedback and gives users a preview of the real thing as early as possible.

Why this idea was shut down — This idea seems really good on paper, however when I took this idea to the development team, I was told it would take more time to code it then we had planned. Which brings me back to the topic of this article — How to design under constrains.

Design is about trade offs. On one hand, we have and ideal solution that might deliver 90% of value to the user, but it will take 5 days to code. On the order hand, we have an Okay idea that will deliver 70% of value to the user, and takes 1 day to code.

In our case, time is limited, so we have to choose what is the best design within the constrain. Not what is the best design.

Making a choice

In the end, we went for Idea 2. We chose a box size that represents 80% of all item’s size. Which means that in 80% of the cases, the fake selection box is the perfect size and it represents the actual size of the item selected. I was actually surprised that it looked way better than I thought. Another reason why you should do prototype.

Here is what it looks like in the end:

Case 1: Item selected has the same size of the Fake selection box.
Case 2: Item selected does NOT have the same size with the selection box, the REAL size is rendered afterwards

The constrain of time forces us to focus on what really matters, it forces us to make a choice. We chose Idea Two that takes 1 day to code versus the other option that will take 5 days. It is the best design based on the given constrains because we want to solve customer’s problem tomorrow, not 5 days later. For us, delivering value to customers is the only thing that matters.

Sometimes we might think: “If only we had more time, we would have the perfect design”. The question is, perfect for whom? Perfect for the company? Perfect for the customer? Did customers really asked for perfect? Or is it for our own designer ego? In the end of the day, giving your friend a present on their birthday is way better than the “perfect” gift that is late. Embrace imperfection. Embrace constrains.

Conclusion

A dream design is just that — A Dream. The real world is a place full of constrains and a lot of things is beyond our control. We as designers, are problem solvers, not dreamers. The sooner we understand this, the better we will become. I would like to end this article from a quote from General Patton:

“ A good plan, violently executed now, is better than a perfect plan next week.”

The perfect design is the one that makes users pain point go away today, not tomorrow. Until next time, may your constrains helps you become a better designer 🙂

Disclaimer: I am no longer a Vyond employee and I’m not posting on behalf of Vyond.

There are no quick fixes in product design

by

Throughout my years in product design, I had been through numerous occasions where supposed “quick” or “small fixes” turns out to be complete scope creep, or they created problems that drains time in the future because of hasty decisions made in the past. It is a nightmare.

What is a quick fix

A quick fix is whenever one faces with a problem — without close examination — decided that the problem is a small one and thus gave it little time to work on. Sometimes one even made up a solution on the spot without consulting matter experts (aka Design by meetings).

So what is wrong with doing things quickly when you knew the problem was small? The problem is this exact “this must be a small problem” mindset.

Let’s break down why this is bad thinking.

1. You assume you understand the problem

Problem comes in many forms. Often, you need to spend some time to carefully study them in order to reveal their true nature. When you are just look at the problem from the surface and try to come up with a solution, it is like trying to finish someone’s sentence without understanding the context. You are no better than guessing.

The quick fix mindset makes you stop digging to the root cause of the problem and makes you jump right into the solution. It forces you to believe that you know it all, and prevents you from looking deeper.

2. You believe the quick answer is the right answer

Let’s just say the problem — is in fact — a small one. You want to find an elegant answer that takes the minimum effort to implement. That doesn’t mean that you would be able to find the solution quickly.

Since you already skipped ahead and decided that this will be a quick fix, you assumed that there must be a quick answer. You jump right to the first answer you came up with and assume it will work. You want it to work.

The problem here is that design is ambiguous; there might be many right answers — all depending on what you are looking for. But if you think there’s only one right answer, then you stop looking as soon as you find one. You can’t see the good ideas behind you by looking twice as hard at what’s in front of you.

3. You decided that everything is going to be okay

Now that you have picked a solution to work on, the next step is to execute it — the standard creating wire-frame and writing specification stuff. The problem now you see, is that since you already decided that you solution is the answer to the problem, it has to work for you. You became overly optimistic or even, tunnel visioned.

Should we talk to the developers to see whether our idea is feasible or not? Nah…my design is simply and shouldn’t be that hard to implement, there is no time for that. What if users do x instead of going through the desired path? Nah… I don’t think user will do that, it is an edge case.

You are likely to make bad calls with this way of thinking. You won’t see the damage you have made. Not today, not tomorrow, but when it is time to pay your debt, it will hit you hard.

4. You create design debt

The shortcuts you took and the little things you ignored will pile up. They became debts to be paid in the future. Since each components is intertwined with each other, the time it takes to solve a problem in the future is not linear, it is exponential.

Quick design almost always means there is a lack of documentation, both on describing how the feature is suppose to work, and more importantly, why the feature was designed that way. No matter how nonsense it seems now, the old logic exists for a reason. You have to be very cautious in adding new stuff while making sure you understand how the old stuff works, and if you choose to ignore the old design, you are very likely to walk into trouble.

Design debt — once accumulated — becomes a bad debt, one that is possible to pay. This is how a legacy system becomes untouchable. Touching one feature means going through the documentations of 10 other features. If you did not fully document how each these features work and why they were designed that way, chances are, the risk of changing it is too high and you are forced to stay away from them.

5. Your crappy design is permanent

If you messed up and the design doesn’t work, your crappy design is going to be permanent. Why? Because you have already worked on it. Your team, or even you would believe that you would improve it in the future. This won’t be the case.

The further away the promise, the easier it is to make. And the more painful it is to ultimately deliver. When the time comes to fulfill the promise, employees would rather be working on newer, cooler ideas rather than old promises. No one wants to put aside progress to make up for the past.

This thing has already been worked on, so it will get shuffled to the bottom of the to-do list. To your users, your crappy design is permanent.

Something cooler

Why do we like quick fixes

What is going on in our mind that makes us like quick fixes so much? I believe there are 3 main reasons.

We want peace of mind

When problem arises that wasn’t something we anticipated, we felt uncomfortable about it. Our first reaction is to find a quick way to make it disappear.

One way to do this is to trick yourself into believing everything is going to be okay. The logic goes “I don’t want to deal with this right now, so whatever came up is going to be a small task”. Hence, we became overly optimistic in both the severity of the problem and our ability to resolve it. It didn’t really matter how big the problem really was, as long as you can get away from it.

We want to work on something cooler

We tend to pay attention to things we care about (Don’t we all?). Small problems always comes with an unattractive batch on them. It feels small, it feels redundant. It feels like we were not going to have a fun time solving it.

More importantly, we are not going to gain much credit on fixing small issues. You might even want to hide the fact that the problem exists, because they shouldn’t exist in the first place if your designs were good. We would chose to ignore the small problems it if we were given the choice.

We are tight on schedule

This is most common reason. There is a deadline and the resources is tight, then this problem came up and it seems that you have to squeeze some time to fix it. You compromise for quality and tell yourself there won’t be next time, of course, there is always a next time.

Conclusion

There is nothing wrong with wanting to fix a problem with the minimum amount of effort if possible, that is what we should strive for. However, do not mistake you intention of using small effort to fix a problem translates to the problem being small.

Slow down. Fight the impulse of jumping to conclusion right away. Spend some time to investigate, bring in the expertise from different employees and discuss together.

If you are really in a rush, time box the time needed to investigate. It is better to spend some time to understand the problem now, than to realize a few months down the road your design doesn’t solve the real problem.

And if you really don’t have time to do all this, know that you are trading quality for speed. Your bad design will always come back to haunt you in the future. Know your debts and plan for it.