Good UX ideas and concepts always come down to solving user’s problems.
A cool, super-innovative idea that doesn’t solve a user’s problem doesn’t provide much value.
Which takes us to look into users.
What are the given user’s problems?
When we think about user’s problems, we need to be open and flexible to the definition of “user’s problems”.
User’s problems are not necessarily just about “doing a task A in product B is a pain in the ass” type of concrete, visible things.
It could be something invisible, or something more fundamental.
So how do you identify those problems?
It comes down to talking to users, observing users, asking questions to users, and carefully understanding user’s frustrations and desires both through what they say AND what they don’t say but kind of hint that they desire.
All these can be done through an exploratory user research.
Exploratory user research does not have to be formally conducted.
You can do it through a simple 1 on 1 interview, as long as you have key questions and some stimuli prepared.
You can even do it in an informal way if there’s a tight budget and schedule constrains.
But it’s extremely important to talk to users or someone familiar with user’s tasks and needs.
Important thing is that you keep asking questions to drill down to the core of a problem. And you can start from anywhere.
For example, if you have a specific report page of a particular web application that you want to improve, the questions are:
How do users currently use this report page?
What value does it give to users?
What concrete actions can users take from this report?
… and so on and so on.
Don’t focus on trying to come up with good ideas.
Rather, focus on user’s problems empathetically.
Understand users’ problems, distill those problems in to core problems, and try to solve those core problems in the simplest way possible.
UX designers are in a way privileged to have an ability to visualize abstract visions and ideas into something concrete such as design sketches, prototypes, and scenario movies to drive things forward.
And when you visualize ideas and concepts, the important thing is a big picture.
This big picture goes back to a fundamental user’s problem that I mentioned previously.
Visualization always stimulates people, and help them further think through things that they never thought of if it were not visualized.
As long as you are clear with the user’s problem, you should be fine.
The very first version of your visualization might be crappy, but the most important thing is that you started.
Once started, a positive feedback loop kicks in, and that gets you moving.
Dyson is one of the most popular brands in home vacuum cleaner category. I’ve been a Dyson customer for the past decades. The model that we currently use in our household is called “dyson cinetic big ball animal +”. It’s the one without washable filters. Overall, I highly respect Dyson as a company, as a brand, who innovated the product category by introducing bag-less vacuum that didn’t lose a suction power.
According to Dyson,
“It is so efficient it captures the dust that blocks cyclones and clog filters, so it doesn’t lose suction.”
Still I get frustrated whenever I clean up the dust bin.
Because I feel like I can never get rid of all the dust inside the cyclone!
Obviously, a large chunk of dust that fills up the bin can easily be removed when you detach the dust bin, open the lid and drop the dust collected.
The plastic bin itself is good.
It’s detachable from the cyclone, and you can actually wash it with water.
But the problem is, the cyclone part itself.
When you use a brush to scrape off dust, and tap on the cyclone to get the dust out from the inside, the dust keeps falling down and it never seems to stop.
Because the dust particles are so tiny, it seems that millions of dust particles are sitting inside the cyclone at all times which never seem to clear.
Those may not be clogging the cyclone because each dust particle is so tiny, and the cyclone may still be working fine, but the fact that all these particles never seem to go away kind of bothers me.
I wish that dyson comes up with a way to clean its own cyclone itself, potentially by reversing the direction from suction to blowing mode so that it can get out all the tiny dust particles out of its cyclone system, for example.
The idea of a machine having its own cleaning mode is nothing new.
We see those in dishwashers, ovens, juicers and so on.
An air pump to inflate an air mattress for camping has a reverse mode to deflate the mattress too.
The same concept could potentially be applied to a vacuum cleaner.
I know that this could be a big challenge to do in a vacuum cleaner because if you activate it by accident, it will be a disaster, spreading all the tiny dust into the room.
But it’s an interesting problem to solve.
Maybe it comes with a special cleaning bin that you can attach the vacuum hose onto, and only after securely attaching the special cleaning bin, a cleaning mode can be activated to blow out dust inside the cyclone to the cleaning bin.
The cleaning bin should be a simple bin that you can wash with water.
Now this might be adding another extra hardware piece.
And I’m not an engineer, so I don’t know if this is even possible from a technical point of view.
But it might be worth it if it works well.
Or they might be already working on it. Who knows?
If they solve this problem, I will be a lot happier!
As a UX designer, especially if you primarily work on digital products, it’s an interesting exercise to think about UX problems that we experience on a physical product like this.
This may seem like a trivial thing, but when you think about the end to end user experience of a vacuum cleaner, cleaning the bin, cleaning the vacuum itself is part of that larger end to end user experience.
In a way, its kind of ironical if a vacuum cleaner which is meant to clean things cannot clean itself.
Many people seem to struggle to find out whether UX is the right fit for them, especially when considering a career switch from a different field. Since UX is such a large umbrella field that includes so many different disciplines within, it’s hard to understand from the outside what it’s like to be a UX designer and what makes you a good fit to pursue a career in UX.
Aside from more obvious practical knowledge and skills that you need such as UX principles, methodology and research fundamentals, there’s another side of the coin which is more about traits and mindset.
Throughout my career as a UX designer, I observed great designers and learned from them. Over time, I noticed there are 12 traits that a great UX designer has, which I’d like to share with you.
So here’s a list of 12 traits.
Great at collaboration
Eager to experiment
Understand how UX impacts business
Let’s take a closer look at each one.
1. Continuous learner
The field of UX is constantly expanding and evolving. The underlying technology is also continuously evolving. There are always so many things that you need to learn, whether a new methodology, process, technology, tools, or trends. To be a UX designer means you live through a constant stream of new information. If you love learning new things, UX gives you that exciting, never-ending opportunity to learn throughout your career.
User experience is something that varies from person to person. When you and I use the same product, the user experience that you have will be different from what I have.
What this means is that understanding how other people think is an essential part of UX design process. You need to be humble to be open for other people’s comments and critiques. Whether it’s positive or negative, you will learn a lot from going through this if you open up.
3. Great at collaboration
UX design is like a team sports. In today’s complex environment, most of the time a UX designer works as part of a UX team, which may consist of UX designers, UI designers and UX researchers.
A UX team is typically part of a larger product team, which consists of PM, engineering, a UX team, and potentially more.
In addition, UX designers often function as a facilitator of various different teams beyond just PM and engineering. UX designers also find themselves serve as an evangelist to educate people from other groups not familiar with UX. Especially when working as a facilitator or an evangelist, you need to be great at collaboration.
In some cases, this facilitation of multiple teams could potentially enable changes that have larger impacts to a customer’s overall journey of a product rather than the user experience of the product user interface itself. A product user interface might only be just one part of a larger end-to-end experience a customer goes through.
4. Problem solver
A UX designer solves a user’s problem. The focus should always be solving a user’s problem, rather than crafting a shinny, cool user interface, which is always very tempting. Being a problem solver also means you should be able to spot problems in the first place, and define that problem clearly in order to start solving it.
5. Less ego
The core of user-centered design practice is that a product or a service should be designed for a user, not for a UX designer. It’s so easy for UX designers to get personally attached to their own designs. It becomes your own baby. I’ve been there too. And it’s so tempting to have a personal attachment to your design, because that makes it a lot easier to put your hard work on it.
As human beings, probably it’s not possible for any of us to become completely free of our own ego. Nevertheless, it’s important to keep your ego in the background as much as possible. In order to work effectively, it becomes critical that your ego is not at the forefront.
6. Do-er mentality
As much as UX designers are thinkers, they are do-ers at its core. All the great thinking need to be distilled into a concrete, tangible output through actions. Do-er mentalitypowerfully drives this when you take all the stakeholders’ feedback and user research insights, to come up with design solutions.
7. Eager to experiment
Every single UX project is different with a countless number of variables. UX designers maneuver these and try what makes the most sense under given condition and data collected. Great UX designers are eager to experiment with new ideas, concepts, processes, methodologies to see what works and what doesn’t. To find out, you need to give it a try. Only through hands-on experiments, you’ll find the best solution for a given problem in front of you.
8. Curious observer
During usability test or user research, you need to shut your mouth, and be a curious observer carefully observing how users interact with your prototype, card sorting exercise, or whatever stimuli you may have. When you ask questions to users, people tend to answer what they think the right answer should be, rather than how they really feel. By observing how participants behave, take actions in particular ways with particular expressions and body languages, you uncover a lot of things not verbally mentioned.
When I or my colleague UX researcher conduct a user research and use a prototype created by myself as a stimulus, it’s always so tempting to interrupt a struggling user and let her know how to complete a task I gave her. But I need to control myself not to do so, so that I don’t ruin the research with my ego.
Especially when I listen to users describing their pain points when using a product or a service, I need to be empathetic so that I can put user’s shoes to really understand and feel their frustrations from their perspectives.
10. Good listener
A UX designer needs to talk to various people including users and stakeholders. I need to be a good listener when listening to PM, engineers and other people from a larger product team to understand product requirements, constraints and business context. When I listen to what users have to say during user research, it becomes even more important to focus on listening, rather than trying to show off how cool my prototype is. When I conduct a user research and ask a probing question to a participant, I often feel an urge to want to drive the conversation towards a conclusion towards my hypothesis. But I should remain patient, listen carefully, and minimize any chance of manipulation as much as possible, so that I get a quality result, not what I want to hear.
11. Understand how UX impacts business
UX designers advocate users as much as possible. What’s often been ignored is that UX is still part of business. A great UX concept that user test participants absolutely loved does not work in reality if it’s too expensive to build under a given constraints. This means UX designers need to have a good understanding of how UX impacts business, so that they don’t propose unrealistic concepts and solutions just because users loved those.
12. Good storyteller
When presenting UX concepts or user research findings to a larger product team, UX designers need to become a good storyteller without getting egoistic. At the end of the day, UX designers create user experience for users, not for themselves. This storytelling is not about promoting how great I am, or how great my UX team is, for example. Rather, it’s about how a proposed user experience solves user’s problems in a way that is realistic, effective, and delightful. The way I tell a story matters. It affects how my collaborators feel that they want to support me or not. When my storytelling is filled with so much ego, I won’t be able to get much support.
As you can see below, all these twelve traits are deeply inter-connected with each other.
Many of these can be learned and acquired, especially #11: understand how UX impacts business.
Some people might have some of these more naturally than others.
Going through these 12 traits and see if all or some of these feel natural to you or not might be helpful to picture yourself and think whether you have the right traits and mindset to become a great UX designer or not.
Having the right traits and mindset are more important than it may seem.
I used to think that traits and mindset are not so important, but I learned otherwise through my own experience. It matters a lot.
So previously I shared my experience with Amazon customer service chat.
At that time, it was for my order of a physical product.
At the end, the product arrived a few days later as the customer service chatbot suggested.
But tracking pages on both Amazon and USPS websites never showed that update, which gave me a mixed feeling.
This time though, it was about a protection plan for a device that I purchased on May 30th.
This protection plan was supposed to be delivered via email within 24 hours, because basically it was just a policy document.
But I did not receive it even after the 24 hour had passed, so I initiated a chat session on June 2nd.
Here’s how the messaging assistant responded.
Your package with this item has shipped and it’ll arrive by Fri, Jun 05.
Since it was coming from an Amazon seller who handles their own shipping, you can email them to find out next steps.
If you don’t hear back in 48 hours, come back and we can help.
This sounded as if it will be delivered physically.
Also it contradicted with what Amazon initially informed me when I was placing the order, which was that “Your protection plan documents will be delivered via email within 24 hours of purchase.”
So I asked the messaging assistant to connect to a customer service agent, a live person.
When I described my concern to an agent, she replied me as follows:
I will send an email to the seller to send you the policy.
Your protection plan documents will be delivered via email within 24 hours of purchase. Remember to check your spam folder.
If you don’t receive it, send an email to email@example.com with your plan order number and they will resend.
This is their contact number. xxx-xxx-xxxx. You can reach out to them via this number. Does this help?”
So I checked my spam folder, but did not find anything.
And when she finally sent an email to the seller, I did receive an email from the seller probably triggered by the Amazon agent’s email.
And then a few minutes later, I did receive the protection plan from the seller via email.
When I asked the agent on why the messaging assistant initially gave me the wrong information, she simply said:
Please ignore that. I have verified with my leadership team. It does not deliver physically.
Since I did receive the product via email after the agent sent an email to the seller, it’s all good now.
But because I had a mixed feeling about this,
I expressed my concern to the agent while the chat session was still on:
I’m a bit concerned about the wrong information that I got from the chatbot for my future purchases. If it’s a chatbot glitch, it should be fixed as it’s very confusing for a customer.
The customer service agent replied back:
I concur. I will pass along this information to the dedicated team. Thank you for highlighting.
Again, the reason why the chatbot initially gave me a wrong information might be just a software glitch.
But I wonder, if the chatbot was programmed intentionally to give a canned answer with an arbitrary delivery date a few days later just to ease a customer’s concern and buy some time for them without actually checking the details in their database and shipping logs.
Or simply Amazon may not have an ability to check purchased product’s delivery details for those with 3rd party sellers.
I don’t know.
Amazon’s customer service chatbot works well overall.
It’s great that you can initiate a session anytime whenever you have any issues.
Still, it seems to always give me some concerns.
And I hope that they fix these glitches, especially given that Amazon is considered one of the most advanced tech giants with wealth of development resources.
Before this pandemic, I used to go to cafes quite often. When I did, I would do my work, read books, or just chill out, with a nice cup of coffee. When I stay at a cafe for some good amount of time, naturally I need to use a restroom. That gave me quite a bit of opportunity to experience and put my thoughts on UX of public restrooms.
From my perspective as a UX designer, public restrooms have so many UX problems that can go wrong, and it’s a really interesting opportunity space to think through user experience at various levels.
I know, it’s nothing fancy, rather disgusting in a way, right?
Public restrooms are weirdly unique spaces in a sense that it’s a private tiny space in the middle of a public area.
It’s a space where hygiene is at the front and center.
It’s also a place where your user experience is heavily affected by how a previous person used it.
A user experience of a public restroom is a combination of human behaviors, psychology, and physical interaction design.
From my cafe experiences, one of the most shocking things that I found was that many people didn’t wash their hands!
I knew that not everyone washes their hands after going to a restroom.
But I was quite shocked to witness that there were so many people who didn’t wash their hands at all!
I was only able to observe this in mens restrooms where a public sink was exposed so that I could see people not washing their hands before exiting the room.
This scared me because some restrooms had sinks hidden inside a locked door.
In this setup, you never know if a previous person came out the door with their clean hands or not.
I wonder if the pandemic changed people’s behaviors, now that a thorough 20 second hand wash has become an expected behavior from healthcare professional’s perspective.
Another thing that I experienced was that I came across many times with a toilet bowl where a previous person did not flush.
This is quite depressing.
But unlike hand-washing, this could be the result of technology flaw, such as auto-flush mulfunctioning, or a person flushed manually but the toilet had some mechanical flushing problem which resulted in not completely flushing the remains.
Or it could be that it did flush but the flushing power was not enough to remove everything in the toilet bowl.
But either way, if you care for the next person, you should make sure that everything is completely flushed before you leave.
In today’s pandemic situation, we are all tested whether we only care about ourselves, or we have a conscience enough to care for others.
Be it a social distancing, or wearing a mask in public, all these are not just for ourselves but for others to prevent infections.
Will people change their behaviors towards something better once the pandemic settles down?
My guess is yes to certain extent, but may have a very little effect to those who need to change the most.
Humans are lazy.
It’s very hard to change people’s behaviors unless there’s a huge benefit in doing so.
Which brings up this question:
Is there anything that a user experience designer can do to change these people’s behaviors?
A user experience designer understands human psychology and human behaviors.
I don’t have an answer for it, but it’s an interesting, challenging problem to solve.
This reminds me of the urinal fly: a picture of a fly in the urinals at Amsterdam Schiphol Airport.
According to them, it reduces about 50% of the spillage, because many men tend to aim at this target.
This is a clever idea taking advantage of human behavior and psychology of men and implemented the design.
Maybe a similar line of thinking could be applied to solve hand-washing and flushing problems.
It’s been more than two months since the last time I went to a cafe and used a public restroom.
I am curious to see how this pandemic affected people’s behaviors or not.
By the way, in this article, I touched upon hand-washing and flushing problems. But there are so many other UX problems in public restrooms too, which I might want to write at another time.
Competitive analysis — I am not talking about competitive market analysis such as market share, revenue, value proposition and number of customers, which are typically done by PM, a product manager. I am talking about a competitive analysis of a user experience of competitor products as a UX designer.
If you do it with the right approach, you can learn a lot of things, which will greatly benefit your UX work.
In this article, I would like to share one of effective approaches to conduct a competitive analysis in a UX project.
1. See a big picture first
Many people might be tempted to jump right in to a competitor’s product, and start analyzing every single element of its interface right away.
But this is not a good idea, as it makes you get caught up on all the interface details without understanding a bigger picture.
The purpose of competitive analysis, or competitive benchmark is to learn from other products so that you can create something better.
The key is to see a big picture first, rather than getting caught up in details.
2. See things in context
A user experience happens when there are:
This means that it’s important to always see things in context, put yourself in user’s shoes, and focus on a user experience from a user’s point of view, NOT from a UX expert’s point of view from a distance.
Because we as UX designers are UX experts, we tend to take experts’ point of views almost instantly by default without realizing it unless we pay a close attention not to do so.
3. Define a focus area, then experience products as a user
It’s usually better to define a focus area that I want to compare across competitors, depending on the focus and scope of a project.
If I don’t have any particular focus area, it’s generally best to look into a primary task a product offers, what the product is meant to do.
For example, if I am trying to create a user experience for a new travel booking service, I would want to do a competitive analysis on competitors’ travel booking sites.
When I think about travel booking sites, the primary goal for users are to book flight+hotel+car in the best deal possible.
Logically, I would try all the competitor sites such as Expedia, Hotwire, Kayak and so on to actually do a booking as a user, and document every step of my experience by taking screenshots, notes, and screen recordings.
I may want to do this in both PC web and mobile (iOS, Android).
4. Create a customer journey map
Above #3 will result in creating a customer journey map of the primary task flow of all the competitors.
At this point, I typically would have accumulated ton of findings and insights, such as strengths, weaknesses, uniquenesses of each competitor, documented along the way.
5. Expand to surrounding areas if needed
Going through primary tasks across multiple competitors will open up surrounding and relevant new questions.
For example, I might want to find out how a user discovers these travel booking services in the first place, whether via Facebook ads, Google ads, direct email marketing, or simply search in Google.
How do competitors appear in a search result?
How do competitors do their SEO — search engine optimization?
How do competitors do follow-ups once a booking is completed?
What are the confirmation emails that they send out?
Among these, I can decide on which area to further conduct competitive analysis depending on my project goals and my resource constrains (man power, timeline/etc).
Competitive analysis could be a powerful tool
Competitive analysis, or competitive benchmark might sound tedious or overwhelming, but it’s not.
As long as you understand the core principles and set a clear focus and goals, it becomes a powerful and valuable tool to strengthen your design output.
Competitive analysis is also not something rigid that you have to follow one particular way. You should feel free to adapt to your own needs.
For example, if you are working on an additional specific feature for a particular product, you can just look into that specific feature.
Look beyond direct competitors
You don’t necessarily need to limit yourself to only looking into direct competitors of your product either.
Look beyond direct competitors.
This is not a competitive market analysis, the focus is user experience.
For example, if I am working on a travel booking product and looking for some reference and inspirations for a wizard, I can look into healthcare products or financial products too. Or if I’m looking for an efficient way to apply an advanced filter, I may look into online retail stores.
Often times, I find better examples of what I am looking for from totally different, unexpected industry or field.
Every single product is different. When you look into a reference from a different field or even from the same industry, you need to understand the specific context that each product has, because those might be quite different from your product.
The reason for doing competitive analysis is not to copy competitors blindly, but to gain insights through learning from others, to shed light to your project from a different perspective, then to help improve your design.
As long as you do it with this in mind, your competitive analysis will be beneficial to your project.
In this world, so many people have tried so many things already. It’s literary impossible to learn every single relevant thing that was ever created by everyone. And it is possible that this cool new interaction design concept that I just came up with might be something that a dozen other people have already tried a few years ago.
However, just spending some time on researching competitor products or relevant features and interactions of other products will give you a lot of learning opportunities and insights that you may not have thought of.
I always get a huge benefit from doing a competitive analysis whenever I work on a UX project.
You’ll be surprised how much you can learn from competitive analysis, how much it inspires you.
Many UX educations tend to put UX in isolation, and disregard the importance of UX/PM/engineer collaboration. But in reality, a success of a project/product from a UX perspective is more affected by how well a collaboration among these three disciplines is executed, rather than what a UX team or a UX designer alone can do.
When I was younger, I used to think that a UX designer has a tremendous power and influence on a user experience of a product, and thus it’s the quality of UX designer’s design output that ultimately impacts the quality of the final product’s user experience the most.
This still holds true, but only if other critical condition is met successfully.
And that critical condition is, UX/PM/engineer collaboration.
I learned this the hard way through various failures, which I would like to share with you.
Collaboration with PM (product manager)
UX is not the only product value
A product value consists of outcome and experience. Outcome is a functional aspect of a product or a service, what it does. Experience is more about emotional quality, how you feel when using/experiencing a product or a service. UX obviously covers the experience part in full, but it also covers decent part of outcome, the functional aspect of a product. Altogether, UX covers a significant part of a product value.
PM owns a product
While UX plays a very important role in a product team, a UX designer never owns a product. PM owns a product definition, requirements and a roadmap. Naturally, MVP (Minimum Viable Product) — is typically defined by PM. MVP is a set of product requirements that are minimum in order to launch as a product and still provides value to a customer. It’s a bare minimum.
Because it’s minimum, it typically does not take the experience part of a product much into consideration, and primarily focuses on achieving functional outcome of a product value as shown above.
There’s a similar concept called MLP (Minimum Lovable Product). MLP is a set of product requirements that are minimum to make the product not only functional but also something that a customer would love.
This “love” certainly addresses experience — the emotional aspect of a product to go beyond just the function.
From a pure UX perspective, you want to make the product value, both outcome and experience as good as possible.
Unfortunately in many cases, the experience part is considered outside of MVP by PM, as shown below.
Outcome is always part of MVP, especially for critical features. Without a function, a product is useless. But many of user experience enhancements tend to be labeled as lower priority by PM.
In most cases, available resources are limited, especially engineering resources to build a product. When PM is confronted with a hardship where he needs all the remaining resources to complete critical features so that the MVP can ship on time, UX enhancement features are typically among the ones to be cut. Or an overall user experience of a product gets watered down to the most stripped-off version.
PM owns feature prioritization
Feature prioritization is one of PM’s most important tasks. As a result, what typically happens is the first version of a product launches with MVP, then the next version or the next next version start looking into MLP and beyond.
There’s a well-known theory called Kano Model for product development and customer satisfaction. It was developed in 1980s by a Japanese professor Noriaki Kano, which classifies customer preferences into 5 categories:
As in Kano Model, it’s important to understand how each feature is positioned from customer’s perspective, when prioritizing features for a product.
A UX designer should work together with PM and help them prioritize features so that the experience part is not ignored. This is something that may not be typically considered as a UX designer’s job, but it’s important as the feature prioritization hugely impacts the user experience of a product, and PM may not realize all the UX impacts when prioritizing features.
Understanding a larger business context
A UX designer needs to understand a larger business context in order to function effectively as part of a product team.
I experienced many times where a disconnection between a UX team and a PM resulted in the UX team working hard on features and UX enhancements that never implemented in a real product.
Even if a UX designer collaborates closely with PM, this will probably still happen to certain extent. Over the course of time, priorities might change due to various reasons such as competitive landscape changes and resource fluctuation. Whenever that happens, PM needs to adjust the plan, which may result in pushing some features out of scope.
While it’s easy to blame PM, typically there’s always reasons at a higher level. Understanding those reasons behind business decisions helps UX designers do their work better. As a result, UX designers can make a better contribution to the product by focusing on areas that have higher impacts.
A UX designer should always be in the loop of these constant changes around product development such as priority shifting, so that you are always aware of those changes, and ready to respond accordingly if needed.
Instead of waiting for PM to inform you, a UX designer should proactively engage with PM on a regular basis. PM is always busy with so many things to worry about. Updating a UX designer with changes could easily get lost in their never-ending to-do list.
This is why a collaboration with PM becomes critical for a UX designer. Actually, not only a collaboration but a strong partnership with PM becomes so important in order to stay in the loop of a larger product context and development status.
Collaboration with engineers
A product needs to be built by engineers in order to launch to the world. An ideal UX that cannot be built is meaningless. An ideal UX that costs too much to build is impractical and worthless.
Even if your design provides a better UX than the current version of a product, it does not make sense for engineers to move forward with it if it’s too expensive to build, or if an assigned engineering team does not have a skillset to implement it correctly.
At the end of the day, bunch of wireframes or design prototypes cannot launch a product. It needs to be built by engineers, period.
This is why a collaboration with engineers becomes critical.
Design handoff is not the end
What a UX designer does is basically creating a detailed specification on how a product experience should be. This specification is typically created in form of prototypes, design specifications, wireframes, design guidelines/etc., and then delivered to engineers, which is often referred to as a handoff.
Many people think that once these deliverables are completed and shared with engineers (handoff), this is the end of the UX process, and a UX designer’s job is done.
But in reality, that is not true at all. In fact, another phase starts from here. This is where a collaboration with engineers becomes a central part of a UX designer’s work.
Even though you have included engineers during your UX process, through requirement gathering, journey mapping, concept development, user research, design iteration and so on, engineers will not be able to point out all the problems and challenges in advance.
Because when the UX process is taking place, it’s most likely that engineers are busy with other things.
Engineers are always very busy, and under a constant pressure of tight deadlines. The top priority for them is to work on functional parts of a product, to make things function stably. Engineers also need to fix all the critical bugs. Naturally, the user experience part falls low on their priority, and taken care of in the last minute.
Engineers will only start taking a closer look at the delivered UX design and specifications once they start implementing those in code. I experienced this so many times with disappointments to find out that what I delivered on time was never reviewed by engineers for a month. But this is reality that you don’t have a control over as a UX designer.
And that’s when engineers find out bunch of problems, and come back to a UX designer saying “you cannot do this, because the platform does not support this” or “this data is not available because we don’t have an API for that”. Or a problem might simply be the result of a priority change that pushed back the development of the needed API out of scope.
If a UX designer does not do a follow-through work with engineers after sending deliverables, there’s a possibility that the final product may look like a total crap, completely different from the design delivered by a UX designer in the first place.
And if that’s the case, all of a UX designer’s hard work is wasted.
Good, experienced UX designers know this, so they work hard and spend good amount of time working with engineers to make sure that they implement the design correctly, and make adjustments if needed.
What matters at the end is how the actual final product user experience is going to be, ideally as close as possible to your original design that you worked so hard on and tested with users.
A beautiful prototype created by a UX designer does not provide any value to customers if it’s not implemented at all as a real product.
Therefore, design handoff is not the end, it’s the beginning of the implementation phase, which directly impacts the quality of the final product more than the design phase does.
When engineers find out issues implementing the design, or PM needs to shuffle feature priority that affects UX works, a UX designer needs to have a deeper discussion with PM and engineers to sort out what can be achieved under given timeline and resources. Based on that, the design or the schedule and the focus of UX works may need to be revised.
This is where things need to be balanced from a holistic view in order to make a successful launch of a product under those changes.
At the end of the day, PM is the one who can make a call, as PM owns a product roadmap.
If you don’t change the design, how much more resources are needed to launch the product on time?
If you cannot add more resources, how much delay do you get to launch the product?
If you delay the launch, what is the business impact?
Is the delay worth?
Is keeping the original design critical part of product’s value proposition?
If you change the design to accommodate engineering request, can you still launch the product on time? Or how much delay?
If you change the design, how much impact would that make to the user experience?
Is that a show-stopper, or acceptable?
Is it possible to have a 2-step approach, to launch with the modified design, and improve on it later?
All of these need to be accessed by PM based on inputs from a UX designer and engineers.
In product development, changes happen all the time.
A UX designer should advocate users as much as possible, but in order to do so, a product needs to exist and launch in the first place. A UX designer is responsible for supporting PM and engineers to make that happen. UX is part of business after all.
A final product will be built by engineers based on PM’s decision on which features to build by when.
As a UX designer, I learned that you need to be nimble and flexible to be able to quickly make adjustments to your design when needed. To do so effectively and efficiently, you also need to know higher-level changes early so that you can adjust your plan and take action without wasting time.
Therefore, it is critical for a UX designer to have a strong partnership with PM throughout the product development process, and work very closely with engineers before and after the design handoff, in order to actually realize the design in the final product implementation.
Now that I look back, there are many products/projects that I wish I could have done better by understanding all these earlier.
Still, it was an invaluable lesson for me to realize as a UX designer that UX cannot exist on its own. UX is part of a larger product team, part of business.
UX designers rely on PM and engineers to realize their design in a product.
When I am working on a UX project, things can easily get messy with bunch of sketches, flows, wireframes, user research data, notes, prototypes and so on. While I feel a strong temptation to just focus on the current UX work, I learned overtime that it’s actually really important that I always keep up with my UX process documentation as I go. I’d like to share my learning with you.
Why document your process?
Here are the reasons why I think it’s important to keep up with process documentation based on my experience:
1. It helped me see a bigger picture of a project.
While I am deep in a UX process, I focus on my current task in front of me, and I tend to lose sight of where I am from a larger context. Documenting my process allowed me not to lose a high-level perspective of a project because glancing at the documented version of my work always gave me a slightly more objective view of my project.
2. It helped me keep track of what changes I made based on what reason.
When I made design changes, I experienced many times that I couldn’t remember exactly how that happened. Things got lost in transition, and it was always hard to pinpoint later whether a change was made based on a user research feedback, or a comment from a stakeholder meeting/etc. Keeping up with a process documentation really helped me stay organized, so that I didn’t lose sight of all these cause and effect relationships that occurred over the course of the design process.
A process documentation to me is a critical artifact and a record of a project. This was extremely useful when I wanted to put together an in-depth case study of my project for an in-person job interview type of occasions. Of course I had to create a more simplified version to be used effectively for any particular interviews that I had, but the foundational information was already there in my process documentation, which made it super easy to do so. No need for further digging or trying to remember what happened when I was actually working on that specific project a few years ago.
From my experience, it worked better to put together a process documentation in a presentation format such as Microsoft Powerpoint or Apple Keynote, rather than a document format such as Microsoft Word, or a web-based platform such as Confluence.
Microsoft Word does not work well for an on-screen presentation as presentation screens are typically landscape, and it works better when each slide does not require scrolling.
Some companies use Confluence for project communication and documentation purposes, but the problem with Confluence is that :
Things can easily get out of control
It makes it harder to archive when you leave a company
A presentation format also helped me organize and summarize key points so that it all fits in one screen.
How to organize
When I work on a UX project, I typically follow a UX process.
Naturally, a process documentation that I create roughly follow this process in a chronological order, so that I can easily follow the progression of a project.
Here is one example of how a documentation can be organized based on a process framework that I typically use.
1. Problem statement
I define what problem I tackled clearly at the beginning.
Additionally, I often create different slides for things such as: project background, goal, a team structure including my role and responsibility, timeline, project type (launched product, future concept proposal/etc).
2. Competitive analysis
I typically find it very useful and informative to do a competitive analysis of some sort for any project.
When I do, the learnings could impact my design decision and output. Thus it’s good to document how I researched the competition, or how I learned certain things and took queues from other products relevant to my project.
3. Concept development
This is where IA diagrams, task flows, wireframes and prototypes go in.
If I did brainstorming or workshop type of activities to come up with and expand ideas and concepts, I document those too with images and output summary.
Each findings should have concrete actions to take.
Other things to include are: user research framework (what and how I or my team tested), research overview (when, how many participants, how long, research format), brief summary of each participant’s profile.
It’s always good to include photos of user research sessions to give the audience some visual cue to help their understanding on how research sessions were held.
Insightful user quotes are always great to include and highlight, which could be put as part of summary of findings.
No need to put every single details, but including all above usually gives a very clear overview of the learnings from the user research and how actions were defined based on those.
5. Design iteration
This is where I show how I iterated the design by incorporating learnings from the user research.
It’s important to highlight which part of the design is modified/improved based on which user feedback from which user research round if there are a few rounds.
Depending on a project, I may have a few rounds of user research and design iteration.
6. Next steps
Depending on a project, I may also add “Next steps” to describe what should be done after the step 5.
7. What worked, what did not work
It’s also helpful to spend some time and write down what worked and what didn’t work throughout a project.
Sometimes a project team does postmortem sessions. I’ve experienced several of those, and it was always very helpful. If that’s the case, discussion points from those sessions should be included here.
Acknowledging what did not work is an important part of being a UX designer. In reality, every project has things that did not work well. Understanding this is a great learning opportunity to do something better in the future.
In order to clarify and highlight a success (or a failure) of a project, it’s also effective to include user test participant’s and stakeholder’s quotes.
I also find it important to include key design decisions made throughout the process, so that it becomes clear how I or a team made certain decisions based on what kind of reasonings along the way.
From a practical point of view, it’s also helpful to insert various links from the documentation back to more detailed assets such as prototypes or user research raw data, so that I can easily bring those up when needed.
You might feel that all these are too much extra work on top of what you already have on your to-do list.
But over time, you will feel grateful that you did. At least I did.
Because, I can easily forget many of the details and nuance of a project once it’s completed, and if I leave it for a while, a few months, a few years, then I won’t be able to accurately recollect and capture those details in my documentation. As long as I do this while I’m still working on a project and my full attention is on it, I can document it in the most accurate way possible with enough important details to help telling my story later on.
Process documentation became an invaluable asset and record of my work. That’s what I went through and found out.
Many people are not sure if UX is the right fit for them, especially when they want to switch their career path or a field of study.
Because the field of UX is broad and constantly evolving, everyone sees UX differently.
The only way for you to find out if it’s the right fit for you is to actually experience what its like to be a user experience designer.
So what does that mean?
This means, you have to try working on your own UX project.
Some of you might wonder,
“What? How can I work on a UX project if I haven’t learned anything yet?”
That’s very true to be fair.
But at the same time though, the best way to learn is to actually try it by yourself.
If you are already interested in UX at this point, something in UX must have attracted you in the first place, right?
That means you know something about UX.
You might have already done quite a bit of research, reading books and articles, watching videos and so on.
If that’s the case, it’s all good.
You can start your own UX project.
To do so, you need to go through the followings:
Define a problem
Research similar products that solve similar problem you are trying to solve.
Develop a concept to solve the problem
Test with users
Iterate your design based on what you learned from users
It’s OK that you don’t know.
The important thing is that you look for a UX problem that you came across in a product or a service that you use on a regular basis, and start defining that problem clearly.
Once the problem is clearly defined, go through the 5 step UX process that I described.
For more details on how to work on your own UX project, check out my other article.
There’s another thing that you should look into.
This is more about your mindset and traits, whether it fits for a UX designer or not.
I put together 12 traits that are required for a UX designer as follows:
Great at collaboration
Eager to experiment
Understand how UX impacts business
Good story teller
A UX designer solves a user’s problem. You need to be a problem solver, as well as a problem spotter, and a problem definer.
To do so, you need to talk to various people including users and stakeholders. You need to be a good listener when listening to PM and engineers to understand product requirements. Same thing when you listen to what users have to say during user research. Especially when you listen to users describing their pain points when using a product or a service, you need to be empathetic so that you can put user’s shoes to really understand their frustrations.
During usability test, you need to shut your mouth, and be a curious observer trying to carefully observe how users interact with your prototype.
UX designers often function as a facilitator of various different teams. When working as part of larger team, you need to be great at collaboration, with less ego with a humble mind to be open for other people’s comments and critiques.
And when you take all the stakeholders’ feedback and user research insights, UX designers should have do-er mentality and be eager to experiment with various ideas and concepts hands-on to explore and achieve the best solution for a given problem.
At the same time, UX designers should have a good understanding of how UX impacts the business, so that they don’t propose unrealistic concepts.
When presenting UX concepts or user research findings to a larger product team, UX designers need to become a good story teller without getting egoistic. At the end of the day, UX designers create user experience for users, not for themselves.
As you can see, all these traits are deeply inter-connected with each other.
Many of these can be learned/acquired, especially #11, but some people have some of these more “naturally” than others.
To summarize, you should be able to discover many things around whether UX is the right fit for you by
Working on your own UX project.
Going through 12 traits required for a UX designer to see how many fits you.