User Experience

How to think about 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.

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

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.

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

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.

Startup
Agency
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.

Decision log

April 16, 2020 by Tim Chan

Imagine joining a UX team as the new designer wanting to learn about the product. There are two ways you can do it without taking your colleague’s time: you study the live product, or you read documentations about it. The most common form of design documentations are Wireframes. However, a wireframe only tells you part of truth, it tells you what design decisions has been made, it tells you the what, but it doesn’t tell you the why.

When we work on a project, we would have made a lot of design decisions based on user needs, stakeholder needs, research findings, time constrains, technology limitations.. the list goes on and on. If we don’t document these decisions down, we will be in a dangerous position where important project knowledge exists only in some designer’s memory. If that designer has moved on, the knowledge will be lost forever.

Without understanding the why, designers are forced to guess why things were designed that way. Every time we make a change, it is a gamble. The only solution is to systematically document project decisions, such that if future designers decides to make a change, they will have the right tools and context to help them make an informed decision. Let me introduce a tool that not only minimize design risks, but can also help you build a more mature UX organization — The Decision Log.

Benefits of a Decision Log

A decision log helps us to:

Remember things — When we write decisions down, we made sure we will have a reliable source of truth we can always refer back to it without forgetting it
Save time — By documenting what worked and what doesn’t, we made sure future designers will not waste time exploring dead-ends
Avoid going into circles — When we are exploring design options, it is easy to go back to square one and forget why we discarded it. When decisions is clearly documented, we made sure this won’t happen
Past on knowledge to others — When knowledge is written down, we are slowly building a library of knowledge where everyone can benefit and absorb it on demand

How to create a Decision Log

A decision log is a simple one pager document that sits inside the project folder. It has 3 components:

Screenshot
Decisions made
Rationale

That’s it. It really is that simple, now that every design you made is traceable and other people will no longer need to guess why you made that decision. The concept is not novel, our best friend — Developers does it all the time when they add comments to their code. Similarly, you should start writing a Decision log entry whenever a decision is made that will significantly impact the design, and you continue to do it through the project.

When in doubt, err on the side on over communication. The bad case scenario of writing something obvious is that readers ignores your sentence. The worse case scenario of not documenting a rationale is that you also forgot why you made that decision, then that information is lost forever.

Conclusion

As agile development and the introduction of Sprint has became the norm in every technology company, people seems to forget the true essence of the methodology is to learn quickly, not just do things quickly. The most efficient way to record and pass on that learning is to write it down. I hope you give this method a try and I can’t wait to hear from you the results!

How to design and implement a new process

April 4, 2020 by Tim Chan

Assume your normal output is x. If you want to increase your output, you need to produce x+1 kind of work. Here is the problem, if you have already reached you maximum capacity, how can you increase your output? The truth is, if all work comes through you and you are the bottleneck, you can’t. You will never increase your output this way.

The only solution is to improve the output from others around you. Why? Because while you are stuck on your maximum output, if you can increase the output from others, you are still producing x+1 kind of work. But how? If you look at human history, the answer is obvious, you must invent a machine and let others work on it.

As knowledge workers, a process is the equivalent to a machine in the information age, it help others to work more efficiently and not waste time on figuring out how to do things. The beauty of a process is that like a machine, once you set it up, it can continue to run itself even if you are not there.

Why we hate processes

Process nowadays gets a bad reputation especially for people working in technology companies where everyone is suppose to work in “Agile”. That is unfortunate, just because someone else’s process is bad, it doesn’t mean the concept of process is bad. It just means either they have designed a poor process, or they have set it up poorly.

Ultimately, people hate processes because most managers doesn’t know how to implement one in the first place. As a result, new processes gets ignored and is locked in the cupboard to never been seen again. In this article, I will talk about the foundation work you have to do in order to make your process work.

People falling asleep during process presentation

How to make a process work

The hardest part about designing a process is to get people to believe in it and to run it. A process will not work unless the following conditions are met:

Competence
Pain
Time
Buy-in

Competence

That is the competence of the individual who wants to make the change. Let’s assume that is you. You have to be good at what you do, or people would not respect you, and they will probably ignore you. Nobody wants to listen to “your ideas on how we can work better” if you are not good at your job.

If you have the power to force others to do things your way, you might think you are off to a good start, that is the wrong mindset. Yes you can get people to listen to you, but the process itself is a worthless piece of paper unless someone acts on it. To make a process work you must influence those that will be executing it.

You need to give people a good reason to do things your way, otherwise they will revert back to the old ways of doing things, and you will spend all day chasing them to follow your process.

Pain

Humans are creatures of habit, if they believe what they are doing is working, they will resist change. The easiest environment to apply a new process, therefore, is when people are frustrated, when they feel “someone should do something about this”.

Not everyone will feel pain the same way. Luckily for you, this pain is psychological and can be adjusted. Just like people in poor country doesn’t know they are living in poor conditions, you have to expose them to the reality and paint a picture of the wonderful life they could live if something changes. Once there is a comparison, people’s mind will start to change.

A person lying on top of a bed made of nails

Time

Don’t expect overnight success. A process is like a machine, it needs to warm up before it can fully function. You need time for people to discard old habit and get used to new way of doing things, and you also need time to refine the process itself. Implementing a process without the patience to see it through is a recipe for disaster. You need to set the right expectation to management and your team members.

Buy-in

Not only your peers might resist to change, people above you might also be the same. The human brain likes to choose the path with least resistance, once they have done something in the past successfully, when faced with similar problems, they tend to solve it in the exact same way they have solved it before.

Even if there is a “better” way, the brain tends to regard the new way as less efficient because learning the new way takes effort and there is a risk that you end up wasting time. This is why we tend to be reluctant to change.

Without buy-in from above and below, your process won’t work. The easiest way to sell to upper management is to get your team start doing things your way, then report it back to your bosses the changes you plan to make has already happened. That way, all management needs to do is to rubber stamp and make your process official. How to get buy-in from below? Let’s talk about this in the next section.

How to gain buy in from your team

When it comes to change, there will be 3 types of people:

Early adopter
Late majority
The uncooperative

Start by identifying the people that feels the pain the most and is most open to try something new. This person is the early adopter, you alone is not enough to convince other people to try the new process, you need a champion, someone that will help you to sell your process to the team. Ideally, that person has certain influence among the team. Look for someone that is senior or is well respected, if you can get that person’s buy-in, you are on a good start.

Then it comes the late majority, usually these group will start to follow once they see someone in their team has already adopted to the new process, especially if that person is someone they respect.

A person carrying a dial phone to a group of people using smart phone

You will have some uncooperative, I once had a person in my team refusing to read the new process claiming it was too wordy and confusing. I brought my laptop, sat next to that person and told her it is my job to make sure the process makes everyone’s life easier and if something is not working, I will change it right there and right in front of her.

As we walked through the document we discover some areas of improvement and wordings that are ambiguous, I made the adjustment right away and share the updated procedure with everyone. I believe my commitment and enthusiasm to make things work changed her mind, and she became one my best champions. The key here is not to see the uncooperative as the enemy, but to embrace it as an opportunity to make your process even better.

How to design a process

Document what is already there

There is always a process — although not official — a way of how people work, you want to document that. Talk to each team member individually instead of having a group chat. Two reasons: 1) to give everyone a chance to speak, 2) what people think they do and how they actually do things is sometimes different, talk to people individually will help you paint a clearer picture.

Approach this from a genuine angle, right now you are only curious to find out how they do things, respect how people work and don’t be judgmental. Once you have done this, let the person read what you have written down and confirm the steps. As you go through the document, people that have a weak or no process will find themselves a little bit uncomfortable because you have exposed them, acknowledge their feelings and keep emphasizing the fact that you are just here to document things and not judging.

Walking through people’s own process is a subtle way to help people understand they are not working very efficiently without telling them directly. They might even think “oh wait, this doesn’t really make sense, why did I do that…” to themselves. This process helps you plant the seed of changes you want to make in the future.

A person talking enthusiastically while another person take notes

Ask for suggestions

As you walk through the process with each team member, ask them where they think the process can do better, put the focus on the process and not the individual. This might take a few times as some member of your team might not be that vocal, work with the people that is most vocal first. Some will rant about things or complain about management, while you may not have the power to do much, it is important that you acknowledge the comments and write it down as this helps sending the message that you care.

Prioritize

List out the problems you found and categorize it into two groups: 1) Things that you can fix and 2) Things that someone else can fix. Start with group 1 as this will give you momentum to tackle group 2, which is often more tricky. You should also invite your team members into this prioritization exercise to make them understand you are doing this for them.

Write the new process

Keep your new process simple at first, once you have wrote it, try to turn off your brain and follow the process as it is, and see do you know exactly what to do. Send it to a each team member individually and ask for comments. Once you are ready, send it to your boss and tell him this is going to be the new way of doing things. You boss should be OK if you have followed the suggestions I made in the earlier sections. Next, send out the approved process to everyone and set up a meeting to explain how the new process works and address questions.

Observe and improve

Make sure you stay humble and tell your team this process is just an hypothesis on how we can all do things better and you are learning about it as much as they do. Set up a time to review the process with the team and refine it constantly. Be open to criticism.

A process is not about A telling B what to do, it is about how the group can figure out a better way to make their life simpler, and more importantly, happier. If one wants to make a process work, one must start with understanding the people.

How to interview for an UX position

February 1, 2019 by Tim Chan

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.

Designing bank’s money transaction UI

December 24, 2018 by Tim Chan

A while ago I worked on a redesign project of a banking website. One area of the website in particular has caught my attention. Here is what it looks like:

This is a money transaction form, the purpose of it is to allow users to transfer money to another party. First you select which account you want to transfer your money from, then to whom and how much. Finally, you select when you want to send it, which the bank calls it the Transfer schedule.

Transfer schedule comes with 3 options:

Now
Transfer on [-Specific date-]
Monthly transfer on every [-Date-] from [-Month-] to [-Month-]

The first 2 options seems pretty straightforward. If you want to transfer money, you can either do it now or do it later (i.e. on another date). However, the third option feels weird to me on first glance. I couldn’t say why until I put in some dummy dates and read it aloud:

I want to “Money transfer on every 5th between August and December”.

This statement is logically correct and I understand what it means. However, something doesn’t feel right. Why?

Because nobody talks like that.

This is why this form sounds weird when you read it. It slows me down and let me wonder “What does this option mean?”

I decided to fix this.

Why does this matter

You might wonder why does this matter? Can’t user figure things out eventually?

You are probably right. Users probably can figure things out on their own if you give them enough time. The thing is, this kind of things adds up, when people say a website or an app is hard to use, most of the time they are not referring to one particular feature, but with all the tiny annoyances or inconveniences such as the above example as they experienced it.

Users are here to get things done, they want to come in, do what they want to do, get out and get on with their life. Our job is to translate what the business needs into an interface that users understands, such that they can input what is needed, and get on with whatever that they wanted to do.

Lets see how we can make our user’s life a little bit easier this time.

The approach

When it comes to transaction, there are only 2 things the bank needs to know.

The date
Whether you want to repeat the transaction. If so, until when.

One trick I like to use is to imagine how things would happen in real-life. This helps to design the form in way that it feels more like a natural conversation. Lets say we are having a conversation with the clerk at the counter. The conversation probably goes like this:

Hi there, what do you want to do? — I want to transfer money.

How much? — $1000.

To where? — This account.

When do you want to do it? — 5th August.

Anything else? — Yes, I want to repeat the transaction until December.

The redesign

Here is my updated version on the “When” part.

Couple things is happening here. First, I added an option where users can quickly select the date of Today since it covers a majority of the use-case. Second, I added a simple checkbox that says “Repeat monthly”, once checked, it reveals another drop-down where user can select the end of the monthly repeated cycle.

The last part of the money transfer conversation becomes:

When do you want to do it? — 5th August.

Make this a monthly transaction? — Yes, until December.

Doesn’t this sound better? Feel free to comment and let me know what you think!