It has been 2 years and 1 month since I started my first job, as an User Experience Designer in a consulting firm. The company has been evolving and changing very fast in the last 2 years. What I do and how I do things have been changed along the way as well. Looking back, I have made a lot of mistakes, done some bad works, but I have definitely grown up and now I have more knowledge and also have formed my own way of thinking. I have always wanted to write some journal kind of thing to keep a log of my work, but I have been too lazy to start for very long. Since I started this blog, I think this is a good opportunity to think about the 2 years, and reflect on it, and write.
I think I can summarize my lessons learnt in these 4 main points:
- Always rationalize any design decisions made
- Design with empathy
- Design a journey rather than screens
- Find out what the problem is, before jumping into solution.
1. Always rationalize any design decisions made
The first lesson I learnt in my job is that I need to have reasons for anything I do in my designs. I have to explain why I have the recent news on the home page but not popular articles, why I design the search bar to be big and prominent but the sign up button small, why I choose to use infinite scrolling for a page rather than pagination, etc. I found it very hard initially and I really struggled a lot. I could barely finish presenting a page before I got shot down by a series of “Why” questions. I didn’t know where to find the data/principles/common practices to back up my design decisions. I had no framework to explain certain things. The most compelling reason I could gave might be “I studied 5 of similar websites, and all of them do it in this way.” I improved this by doing 3 things:
1) I learnt a thinking framework from my supervisor and seniors:
- What’s the objective of this page?
- What’s your user’s goal?
- Where does the user come from and where does he go after this?
This helped me to explain why I prioritize the content on a page in a certain way and how I design the call-to-actions.
2) I learnt some marketing frameworks
AIDA = Awareness + Interest + Desire + Action This helped me to present a whole page with an overall structure and a logic that makes sense.
3) I read some books about design principles
I read mainly 2 books:
- Universal Principles of Design – this is a very heavy book on general principles about any design
- Designing Web Interactions – this books covers a lot of interaction patterns and how to use them in detail, but it may be a bit outdated for now
Reading these books helped me to have some principles to back me up, especially for details in the interaction designs. Rationalizing my own design was not easy.
It took me more than half an year to be more comfortable and confident at presenting my wireframes with enough rationale. I can still remember that at the end of 2012, when I had a catch up session with my supervisor, he pointed out that the most important things I had to improve on was rationalization of designs and more empathy for the users. And yes, empathy is what I’m going to talk about next.
2. Design with Empathy
Even before I started working, I have learnt from school and also my research online that empathy is one of the most important characteristics of a good UX designer. I didn’t think it was a big deal. How hard would it be to imagine you are someone else? However, it was easier said than done, at least for me. The first mistake I make was that I did it the other way around. I often said “If I was the user, I wouldn’t want to click on that because …” However, what I was actually thinking was “If it’s me, I wouldn’t want to …” Instead of putting myself in the user’s shoes, I was putting the users in my shoes. And after my first couple of projects, I suddenly realized that I was not making use the personas at all. I started questioning why it happened. Are personas not useful? Or I haven’t found a proper way to make use of it?
I started to pay attention to my colleague on how she presented content strategy using the personas she developed. She always started from “Let’s meet our user xxx”, followed by “So when user xxx comes to our site. This is her journey. And along the journey, we show these messages and content to her.”
After that, I was suddenly enlightened and I felt that I finally understood what empathy really meant. So I always started designing with the persona in mind and think about who this person is, what he wants to achieve, how he would make decisions, etc.
3. Design a journey rather than screens
With the persona in mind, I could empathise the users more and one more thing I have learnt and started doing was to design with a journey as the main storyline rather than design discrete pages.
In my first projects, I was always asked to deign the home page first. With a few rounds of revision, then I was approved to design other pages. I didn’t see a problem in it until we started incorporating Customer Journey Mapping in our process in early 2013. CJM helped me a lot in seeing the whole journey of a user and linking the journey with user’s goals, motivations and emotions. When I came out from a CJM session, I felt that I had a lot of images in my mind mapped to all the steps across the whole journey. I sat down and sketched many rough screens that could be mapped to the whole journey. At that moment, I wasn’t focusing on the page objective, page layout, or interactions design, but the steps that an user would go through to accomplish a task. Only with the whole journey mapped, then I started to work on the details on the screens, what content to show, how the interaction works, etc.
I also tried new way of presenting UX designs. In Sep 2013, I worked on a enterprise system project. In the CJM workshop with the users in that organisation, I found out that to accomplish their tasks, they would not only use the system, but also Phone Calls, Emails, SMSs very often and all these interactions are inserted in their journey everywhere. When I tried to sketch the system screens of of the journey, I found my self sketching emails and phone calls as well. Instead of just presenting the wireframes, as I had always done, I decided to use a powerpoint slides to tell the story of a user journey. I got the names of some people from the company in different roles who would be the users of the system. I put avatars and their names at the beginning of the slides. Then I walked them through the journey with how each of these people will be using the system as well as how they will interact with each other using other tools(phones, emails, etc). That presentation session went pretty well. I could see that the audience really paid attention to what I was talking about when they saw their names there. I think the reason was that instead of showing them a system, I was telling a story that will happen with themselves. Therefore they were more involved and willing to listen and give feedback like “no, no, no, that’s not how it will be, because I would have to get approval from my boss first to send that out…”
After all, I’m designing an experience, not a system, so I should design a journey rather than screens. Therefore, when I present it, I should tell a story rather than just showing interfaces.
4. Find out what the problem is, before jumping into solution
I still remember that after I finished my first project, which was a responsive website for mums to find baby-friendly facilities nearby in Hong Kong, I couldn’t answer my colleague’s question of “So why did the client want to build this website?”. I had done all my work, delivered all my wireframes, but I could not answer the question: “Why do it?” I knew that the website is for helping mums, because it’s sometimes not easy for mums to find a feeding room when they are outside in Hong Kong. However, why does the client want to build this? What does it do with them? What’s their goals? What do they want to achieve? I didn’t know and I didn’t even try to find out.
Even in one of the project I just worked on recently, I still made the same mistake. A client came to us and asked us to build something like another product. We went to start designing and building the product straight away without trying to find out why they came to us, what’s the problem they were trying to solve and why they asked for the same solution. It was too late when we realized that we might be solving the wrong problem. But we had to continue doing what we had promised. The only thing we could do was to try as much as possible to find out what they want to achieve and also understand the end user needs so that this product can be adopted.
I’m reading book about Product Managers recently called “人人都是产品经理(Every one is a product manager)”, written by Su Jie, a Product Manager from Alibaba. I think a story I read in this book elaborates this point very well:
Xiaoming said, ”I want to buy a driller.”
Damao asked, “Why?”
“I want to drill a hole on the wall.”
“I want to hang a piece of painting on the wall.”
“This wall is too empty, it makes me uncomfortable.”
“When it’s too empty, it’s not cozy enough to be like a home.”
With all the “Why” questions, Damao managed to find out the real problem Xiaoming is facing, “It’s not cozy enough.” Once we know the real problem, there are many ways to solve it. It doesn’t have to be buying a driller. Maybe the solution can be changing the light to be softer, or rearranging the furniture, or decorating the room with some plants.