3 steps to work your way into a UX career

This post originally appeared on UX Planet

User experience designer wanted, no experience necessary!

Have you ever seen this in a job posting? I haven’t. I think it’s because user experience (UX) design is a field where success is determined by the ability to empathise, creatively solve problems, and influence others to think like a “user”, which can be difficult to demonstrate in a portfolio alone. In addition to reading UX books/ blogs and attending UX courses, having the ability to apply UX thinking with “on-the-job” examples is critical.

As a senior UX designer, UX instructor, and mentor, I often get asked “What’s the best way to get a job in UX?” My answer is to get started today by using UX principles and processes in your current job. This allows you to either create a role for yourself in UX with your current employer or have a wealth of examples to talk about in interviews with prospective new employers.

In this post, I’ll cover three ways you can work your way into UX, by:

  • Asking the right questions
  • Understanding your user
  • Speaking the UX language

What does a UX designer really do anyway?

As a UX designer, I dive into projects by understanding and defining the problem, researching the needs of the users, and developing features, functionality, messaging, and interactions to help solve the problem, while meeting the needs of the user.

What does this mean? I solve problems. If you like finding interesting solutions to problems, you’ll be a good UX designer. Sound like you? Ok, then let’s keep going.

Ask the right questions

No matter what you do in your role now, you probably solve problems every day. But how often do you take time to step back and define the problem? A lot of times as designers, developers, account managers, or producers, work is given to you as a task. Rather than accepting this as the right task, work backwards to the problem you are solving. Even if you only do this for yourself, this is a key step in starting to think like a UX designer.


You’re given a task to develop a website for a financial planning company. Before you start designing pages based on content the company gives you or researching their competitors, define the problem that the company wants to solve.

Some business problem options:

A. The financial planners business is slowing down, so they need to attract new clients

B. The financial planners are spending a lot of time answering the same questions for first-time client, so they want to educate prospective clients on the range of services

C. The operations team want current clients to be able to self-service some of the admin of their accounts.

Each of these problems would lead to drastically different designs in terms of content and layout, and it’s important to dig into them before starting.

But it’s also important to take this a step further and define what problem the user of the site is trying to solve. Why would someone land on this site in the first place?

Possibly someone has just got their first job and googled “financial planners near me” or maybe they got the name of the company from a friend and are looking to assess whether the services are for someone like them. See how this could affect the design of the experience?

Say the business problem is B: educate prospective clients on the range of services. If this is all the information you had to based your designs, you might categorise the services by financial products like “superannuation” and “investing”, whereas if you were considering what the user is looking for, you might categorise them by stage of life, like “first job” and “buying a house”. This could help users better assess if the company has services to meet their needs.

Asking questions about problems that the business and the user is trying to solve leads to a better solution and shows your employer and clients, and potential future employers, that you have a UX mindset.

Unsure about how to reframe a task into a business or user problem? Comment below and I’ll give you a few ideas or probing questions.

Understand your user

So how do you know what problems the user is trying to solve and why? Assumptions about your customers and users are just assumptions; the only way to know what they want it to talk to them!

Budget and time is often the cited as barriers to conducting customer researching customers. Hiring research agencies and labs can be extremely useful but expensive, but there are cost-effective ways to get to know your customers’ needs.

Here are some easy research methodologies to implement with your current team or client:

  • Define your questions;
  • Establish your target audience;
  • Get out and Interview or conduct surveys

Qualitative research focuses on the “how” and “why” of user behaviour. I worked as a research consultant running qualitative studies for years, and found that with the right questions, you can identify trends and make better informed decisions with as little as 5 participants. The best way to get qualitative feedback is interviews, but surveys with the right questions (and open-ended options) can get you there too.

If you have a physical location (or if your target customer is broad enough, any location), ask people coming in or out for a few minutes of feedback in exchange for a coffee or ice cream.

Find it terrifying to approach strangers? Make a sign to get them to come to you.

Find it difficult to get out of the office? Create a free survey on SurveyMonkey or Google forms and send to a random sample of customers (at least 10 responses is best), or ask people who visit your site or Facebook page for their help in making their experience better. Send it to friends and family if they meet the target market.

A few questions to get contextual behavioural information about your customers:

1. Have you used this [site/app/product] before? Why do you use it? How often?

2. Can you tell me about the last time you used [this product]? [Physical location, device, time of day, etc.]

3. Did you [buy/sign up/read something/other success outcome]? Why or why not?

4. They are thinking about adding [feature/product]? What do you think? Would you use it? Why or why not?

I’ve purposely left #4 to the end. This way, you give the participant a chance to bring it up on their own to validate the problem or idea. But don’t be afraid to be direct and ask if they would use what you are building.

Besides talking about high level features or products, I generally try to ask questions that give insights into past behaviour, which is a good predictor of future behaviour, rather than asking someone if they hypothetically would do something. This is because people have a social desirability bias, or tendency to want to say things they think that will be viewed favourably by others.

For example, a leading question might be:

Interviewer: Would you use this new app we are developing that will track buses and bus timetables?

Participant: “Maybe, I’m always late to work, it could help me be on time more.”

Past behaviour/less leading question:

Interviewer: Have you used an app for bus tracking and timetables before? In the past month?

Participant: “No, I don’t really trust those apps to show the right schedule. I just show up to the stop and hope I don’t have to wait too long.

This example shows how phrasing a question differently can lead to different conclusions. In the first case, you could have 8 out of 10 participants say they would use it, so you conclude to move ahead with the idea. In the second case, you could conclude that it will only be successful if ‘trust’ is integrated into the app by building live bus GPS tracking, for example, which might completely change what your spend your time developing.

Most importantly, listen and engage with your participant — the best responses are usually from probing follow up questions!

Can’t get access to your users with any of these methods? My suggestion is to find the next best thing, e.g. talk to a customer service person or someone else who deals directly with users/customers on a daily basis.

By getting experience talking to users will give you empathy and ideas to contribute to the solution, even if you’re not a UX designer yet.

User-centre your language

It’s also important you present work with your user in mind. Being able to influence your team or client to think about the user first will help create a UX culture internally and externally.

If you wanted to be a software developer (or maybe you already are), you’d have to learn the technical language of the code you want to write, e.g. HTML, CSS, etc. The technical language of UX designers is less about terminology, and more about communicating ideas and perspectives away from yourself to that of your user. This is what people find most difficult when transitioning into UX. Here are some quick tips to get you into the ‘user mindset’:

If you’re a designer/software developer:

Don’t say: “Here’s my idea for this home page.”

Don’t say: “I’ve done what you ask me to do on this home page.”

Say: “Users said they looking for X when they come to our home page, so I’ve put that at the top.”

If you didn’t talk to users, this would be harder, but you might say “you told us you think users are looking for X…” or “based on our assumption, users are looking for X, which we can test later by…”

Of course, sometime users don’t know what they want, or it’s something that would be hard to test with your users. It’s common (and ok) to steal ideas from other experiences, and is actually usability best practice to use consistency with the users’ expectations (i.e. other apps and platforms). Here’s how you might frame that when presenting a design, or working with a designer.

If you’re on a product/project/marketing team influencing requirements:

Don’t say: “Here’s a cool new slider that Apple did, so let’s us those in this app.”

Don’t say: “I think sliders are better for filtering search results, so we should use those.”

Don’t say: “I don’t like dropdowns, don’t put those on the search page”

Say: “UX best practice is to use sliders for numerical filter options, and here is an option based on an interaction that our users may be used to.”

In general, try to replace your own opinions with insights from user research, or assumptions that can be tested with users.

This tactic, of course, requires research into what other apps do. If you can find usability research that has been conducted on a similar interaction, you’ll be better qualified to make statements like this, and you’ll contribute to a better experience.

Frame your language and decision making to be more user-centred, and you’ll think and sound more like a UX designer, which will help you move in the right career direction.

For a great list of UX terminology, check out 52 Research Terms you need to know as a UX Designer.


Ask the right questions to get to the real problem before you start solving. Be the expert in the room on your users by talking to them. And in every decision, communication, and interaction, explain why you are making the experience better for your user.

These might be a shift for you, but it’s a habit that once you get into, you are a UX designer.