UX & them

UX & them

What is a UX designer?

UX just stands for 'user experience'. Still confused? To put it simply, UX designers are web designers, but we just wanted a new flashy name for what we do, because in the tech industry we like buzzwords and feeling important.

Web design has moved on a lot in the past few years. The focus has shifted even more from aesthetics to insights. Being a good UX designer means not focusing too much on branding, colours, pretty flourishes and content, but instead listening to users needs, and finding the easiest and most enjoyable way for them to fulfill them. Most of my job is actually about problem solving, and organising stuff into systems.

In my career I've worked on many different kinds of UX challenges. How can I design an online store so that users can easily browse and filter through products, finding what they need with a minimal amount of clicks? How can I work with surgeons in a hospital to design an iPad app that syncs with X-ray equipment and helps them calculate where to make an incision? How could I design an app which tracks a cycling race in real time and updates the user with who is at the front of the peloton? How can I design a banking app which is individual to the user, so that it's faster to get to the functionality they most commonly use? These are a couple of the most interesting projects I have been part of. But how do you even begin with a UX project?

Tiny woman, big questions

Most of my projects start with me reading the brief, and making a big list of questions, usually on post it notes (UX designers love post it notes) and then grouping the questions together and writing them up, marking the most important ones. I can usually answer some of these questions with my own research, but I take all of them with me to my initial meeting with with the client, so I can validate my findings. In this meeting, the client will excitedly tell me what they want to do with the project, and give a little history about their company. I then go in with the questions I have marked as most important, and save the rest of them for an email afterwards.


From that meeting and the subsequent emails, the client and I should be able to agree on what the brief is, how much time and resources they want to spend on it, and we will also know which questions we have unanswered. These unanswered questions will be the starting point for further research and insights. If you are working freelance, then you need to sort out the money stuff at this point too. Don't work for free for anyone, you are an important UX designer, remember?

The quest for truth

Now it's time for gathering research and insights, and for me this is the most fun part of the whole process. If you are new to UX, this stuff can feel like a goddamn chore, as you may be itching to just get on with designing the thing. You probably have some ideas already of how it should look and work. But sit down buddy and prepare to have your preconceptions and ideas blown to pieces and splattered against the wall. You gon' learn!

There are many ways of gathering insights such as interviewing people, field work, making customer journeys, quantitative testing, qualitative testing, guerilla testing, card sorting and solution analysis. Not all of them are appropriate for every project. I guess the best way to make a plan for it is to base your method around the questions you need answered, the time you have and how far you client will let you go.

Last summer I did a bunch of insights work for the TV company I work for. We wanted to answer the question: 'How do our users want to find content?' It was really valuable to go to a bunch of peoples houses and observe how they watched TV. We asked them what they liked and disliked, and what they wished for. We organised workshops in which we asked people to design their perfect TV experience by prioritising a bunch of card with stuff like 'home', 'genres', 'my channels', etc on them. We looked at Google Analytics to see how people were using our current products and we analysed our competitors products and their patterns.

When you are done with your research, you will have to present your key findings to the client and give a recommendation of how you want to take this project further. Maybe your research has shown that your clients initial idea wouldn't actually work, or maybe it has revealed a gap in the market and changed the direction of the project. Maybe you need to do even more research? Sometimes your work with the client will end here, which isn't a bad thing because you all learned something.

Even more post it notes

Now it's time for wireframing. I always work on paper, starting off by writing some of the key findings from the insights work in my sketchbook and scribbling ideas down. This is when people will find me with a far away look in my eye, and hear me mumbling stuff to myself like 'ok and then they would click there but then why would they go up there' and 'hmm let me just try somethi... no no no!' It's important at this stage to just produce as many ideas as you can, even if some of them feel stupid or weird. I like to do rough sketches on post it notes and then lay them all out on a whiteboard so I can imagine how clicking a button may lead the user onto another screen. 


Once I have a few ideas of what may become the proof on concept I like to work with user stories to test out how these ideas would work in practise. An example of a user story is like 'As an admin to a facebook group I want to easily be able to block people from the group who are causing trouble' and then the people who are designing Facebooks UX would get their post it notes and put them in a flow which proves to themselves that their design would work for that context. Or it could be: 'As a foreigner living in Norway, I want to be able to quickly translate Norwegian into English' and the designers of the Google Translate app would work on a flow for that.

Can I design now?

I then at long last open Sketch and begin making some prototypes based on my post it note scribbles. These prototypes need to be plain as fuck. Remember at this point we need to focus on how it works rather than how pretty it is. I usually use Keynote, or Invision to make them clickable and animate, and then I test these out on actual people to see if they make sense. Once I am happy with with the design I take it back to the client to present a proof on concept and get some feedback. Sometimes they are expecting finished designs with real content and will be like 'ummmm, why is it all black and white?' and 'This product is not called Lorem Ipsum!' which is really annoying, but you just have to move on and complain about it to your designer colleagues later on in the day.


By this point you will have some other people waiting in the wings, getting ready to sink their teeth into this project. Developers, project managers, marketing bods, and graphic designers who will be working on the branding and content. You need to stay organised, so make sure you all agree on a way to do that. I commonly work with tools like Trello, Jira, Slack and Zeplin which help teams to prioritise tasks and work together faster. I love these tools as it's a really easy way to see the scope of a project, and what everyone else is working on.


Together with your team you can plan what tasks you need to prioritize to make a MVP (minimum viable product). What's the least you can do to make something that people can actually use? It's important to not be a perfectionist, and just get something out there that you can test, use, and build upon. After your first release you will dip back into parts of the design process, going back to wireframes, and insights to help you decide what to do next and how to improve upon what you have made. Oh, and you will also make it look nice too.

So that's what UX design is; a hell of a lot of questions and a bunch of post it notes.



Four to the floor

Four to the floor