Better user testing with a user testing plan

You’ve got your product built and out to market. Or maybe you’ve got a clickable prototype built in Adobe XD or other tool, or even some paper wireframes. Either way, now you’re ready to get it under the noses of real people, test your idea and hopefully improve your business.

Scary times indeed. 

Why do you need a user testing plan?

A testing plan prepares you for user testing. At its simplest it helps you decide the areas that you are going to concentrate on. At its more complex and most useful, it’s a practical guide that ensures your tests are consistent, thorough and that they give your team actionable results.

Crucially, it also helps you focus on watching your users. A testing plan will allow you to uncover more about their problems, their needs and how your product might help them. Which is exactly why you’re doing this to begin with.

What goes in a user testing plan?

  • Scenarios
  • Tasks
  • Aimed for outcomes and a way of scoring
  • Requirements / assets needed to run each task
  • Notes and comments

So how do you start putting these together?

1. Choose what to test

To create your plan, first make a broad list of all the things you want to test.

Good ways of doing this include:

  1. Identify any assumptions you’ve made about your product or users which you want to test are true. Question the most obvious assumptions. It’s strangely hard to do, but invaluable.
    For example, ‘on our website, parents will be able to join parenting groups in their local area’, or ‘users will know they can save their work and edit it later’ etc.
  2. Think about the business objectives which your product is meant to deliver (e.g. increase the number of accounts created by our online shoppers)
  3. (A favourite of mine) think about those aspects of your product which are meant to give value to your users. Be it social, emotional, economic or whatever. Do they really generate value for your users? Do they even know these aspects exist in your product?

Now shortlist.

Whittle them down to a good number to test – and definitely use your business’s objectives to help you prioritise.

10 things are plenty for you to be testing within an hour, per user. Any more risks fatiguing your users, you and any observers.

2. Write your scenarios and tasks:

Test scenarios provide users with a real life context that they may find reasonably expect to find themselves in when using your product. Test scenarios also provide a structure that gives your user a seamless, authentic feeling experience – i.e. it provides them with the best simulation of real life as it is possible to give.

For each scenario you need a general structure something like this:

  • first the framing, or user motivation
  • then an actionable task for the user. These will give you something to measure, or validate its completion as a success.

Define your scenarios in advance!

Defining these scenarios – i.e. writing them down before you get into testing – gives you structure and reliability.

It means you can standardise the tasks, and therefore the test overall, making your results more reliable.

Writing scenarios in advance helps you avoid changing the way you describe them between users, as this would make your tests inconsistent

Finally writing scenarios and tasks helps you avoid poor or leading phrasing when you try to describe them to your user.

Simple things to avoid include:

  • Unintentionally revealing the steps required in order to complete an action;
  • Questions that use the same language as the on screen elements;
  • Turns of phrase that unwittingly reveal the aspects of the product you’re hoping to test;
  • Making the user operate in an unnatural way in order to please you (i.e. they do what they think you are pushing them towards, rather than solve the challenge in their natural way)

And of course, writing test scenarios allows you to identify in advance all the assets you’ll need to run that scenario. For example, if testing paper prototypes, all the paper assets needed to illustrate that user journey and any offshoots the user goes on.

What makes good user testing scenario and tasks?

As already mentioned, each scenario needs:

  • the framing / user motivation
  • then at least one actionable task

For example, “You need to travel to Oslo by Saturday morning. Go to the MyTickets website and book a good ticket.”

Keep tasks ‘human’ to reap insights

The phrasing here of “book a good ticket” allows the user to find and book whatever they think is the best approach to travel.

Had you just said “book a train ticket for Saturday morning” they might have done that, but you would have missed discovering that they’re the kind of person who would love to travel by boat for a change; or always hunts out deals; or that hates overnight travel; etc.

These would be missed business and design opportunities.

Make each task a real mission

Note in this example that the user was asked to find their own way to the MyTickets website. It was not already open and ready for them.

Seeing how users find, navigate to, and react to the product first opening should also be part of the test. It makes the scenario feel real, like a mission, and it may surprise you with the route that they take.

Outcomes and scoring

In order to track how well users are able to complete the tasks, you need a scoring grid. Nothing fancy. Just a simple grid, with the leftmost column containing the tasks and hoped for outcome, one per row, and then a column for each tester.

For each user, if they successfully complete a task or answer a question according to the expected outcomes, they get a tick. If not, an X. If they only partially complete it, you leave it blank.

Success Rates

Another way of scoring to give user-tasks a % success rate. This will allow you to work out some averages of areas of your product that need improving.

A typical scoring system would be:

  • %100 completion rate = user completed the task
  • %50 rate = a partial success in completing the task
  • %0 rate = the user was unable to complete the task at all 

A note on terminology:

Using “success rates” instead of something like “failure rates” has a more positive connotation, and is based on empathy for our users – which is fundamental for good design!  “Failure Rates” has an inherent critical aspect to it, both of the test subjects themselves and the design decisions. Or, putting it another way, the design team!

However product development is about iterating and improving. It’s aspirational. And it’s much more motivating for people making design decisions, prototyping and iterating, to be talking about success rates over failure rates.

Finally, I believe “failure rate” has a focus that is more internal to the organisation and doesn’t celebrate users. There is an undercurrent that suggests that ‘users are failing to understand our designs’ rather than ‘we aren’t meeting users needs’.

Notes and comments

Of course, there’s more to user testing than generating scores and ticking boxes. The greatest amount of learning comes from simply watching your users and understanding what they do and how they feel. For this, someone needs to take notes.

If you’re the person facilitating the test, don’t worry about taking notes yourself. As the facilitator, your role is to concentrate on engaging with the tester, making them feel comfortable, keep them talking and and help them verbalise what they’re doing throughout.

Instead, have an observer do the note taking. For best results, it should be multiple observers. For this, set up a webcam and microphone and send the feed to in another room.

Ideally, see if you can focus a second camera on the product itself as well, as then you can send a feed to the observers as people navigate, click around etc.

The observers should capture:

  1. Noted behaviours (e.g. body language, shaking their head, flipping back and forwards between screens)
  2. Likes
  3. Dislikes
  4. Feelings
  5. Questions
  6. Ideas

Capture them one per Post-It note, making each short and clear. Be sure to also note which category each belongs to (i.e.  add “Likes”, “Behaviour” etc in the corner) and set them aside. 

Post-test results

Once all the tests are complete, it’s time to bring everything together. 

Take all your notes and do a ‘Saturate and Group’ exercise: as a team, grab notes and post them on a wall. Then, collectively look for common themes within the feedback and group them, moving the Post-It notes accordingly. Finally, give each grouping a title.

Taken together with the task scoring grid, you’ll now have at least a good half dozen clear opportunities for improving your product.

 

Desire and UX

In 2013 Lamborghini, the car firm founded by the Italian industrialist Ferruccio Lamborghini, produced 2,121 cars. By hand. And these cars sold for about $200,000 apiece.

Meanwhile in the same year Fiat, the Netherlands-based manufacturer, produced over 2 million cars, with mid-range Fiats costing about $25,000.

As a product they broadly serve the same function. But the question is, which is the more desirable car? Which would you rather own, a Fiat or a Lamborghini?

And how do we choose?

Once asked that question we find ourselves assessing the qualities of the two cars. We rationalise the miles-per-gallon and insurance costs, sure. But with the Lamborghini we find ourselves thinking about the speed, the design, the workmanship, the materials, the aesthetics. We visualise it.

And very quickly we realise that one of the main factors in our decision-making is desire.

Desire in UX

Desirability is established in users – and instilled in a product – through brand, image, identity and aesthetics.

But aren’t brand and identity separate disciplines to UX? Does adding brand, identity and image into the remit of UX design stretch the concept of UX until it becomes too broad and unworkable?

Such questions lead us down the wrong path. And in order to show why, let’s break it down a little…

Aesthetics, brand, image and identity

The aesthetics: Lamborghini cars have a very strong aesthetic – you can always recognise a Lamborghini. A Fiat, probably less so.

Their brand is clear too: luxury and high end. Lamborghini cars are expensively finished, highly-engineered and probably have way higher quality parts than would typically be required of an everyday driver.

They also come with – and impart to their owners – a strong image: the cars have associations with the world of motor-racing (and shh… a historical connection to the world of tractors, but that’s another story).

Through this they allow their buyers to attain a certain identity: only a few thousand Lamborghini cars are made each year, so owning one means being part of a highly exclusive club.

Finally, all of these aspects of desirability mean Lamborghini cars, as products, instil strong emotional feelings in their users. This is likely to include pride and confidence, but overall it’s satisfaction.

Satisfaction in the UX formula

Satisfaction is the elusive quality that sits alongside utility and usability to create the user experience.

User Experience = utility + usability + satisfaction

Just one of the many UX formulae out there…

So back to the right way of thinking about this issue….

The question we should be asking ourselves as product designers and UX professionals is: what elements of brand, identity and image can we include in our product world that increase the satisfaction of our user?

There’s a lot of opportunity here: from major features that build tribes, that create exclusivity and reward power users; to the aesthetic decisions we can make on interaction animations, transitions, the colour palette, imagery, content tone/language and more.

Window Seater

This is a question I’m thinking about as we grow Window Seater. For a travel app, how can we leverage brand, identity and image in the user experience?

At Window Seater, Pete and I believe that, as travellers, we should build connections to the people, history and cultures through which we pass. And we believe in a new approach to storytelling: handmade, high quality stories that better connect us to the world and its people.

So how can we build desire around this and bake it into Window Seater’s products? How can we make users desire to be a part of our tribe?

Desire in the digital world

An example we can all learn from is Maptia – ‘home to a world of stories’ about the world and its peoples – and see how they’ve employed thinking about brand, identity and image in their UX.

Take a look at Maptia’s journey from 2014 to present day. Notice the enhancements to its design and the creation of a high-end feel via its typography, imagery and palette. Notice too the visual priority given to the Maptia community in the 2018 design.

And of course, the focus and pull of its improved mission statement, from:

At Maptia, we believe that if people from every country, every culture, and every background shared the stories of their lives and of their travels, then the world would be a more understanding and empathetic place. We also believe that this would encourage people to get out there and make the most of their short time on this planet. Our mission is to gather these stories together and create the most inspirational map in the world.

Maptia’s Mission Statement circa 2014

To:

At Maptia, our mission is to foster empathy through storytelling.

We aim to provide a platform for those who document and capture the world around us, bringing them together to create a lasting record of life on Earth; so that people everywhere can experience the cultural and natural wonders of our planet, can feel more connected to the biggest issues facing the world today, and can be empowered to create a better future.

Maptia’s Mission Statement circa 2018

Notice how the vision is now so much grander.

Also the focus has moved from 2014 team’s internal ambition, to 2018’s focus on appealing to and servicing an existing tribe: the photographers, writers, explorers and those passionate about our planet.

For us Maptia’s approach is hugely inspiring and definitely something to learn from.

So what exactly can we learn from all this?

As product managers and UX professionals, when we’re building products we need to factor desire into our product world to increase the satisfaction of our users.

When building our product we need to identify early on, what are the brand values it stands for. We need to consider the image it presents, and the identity that it will impart to its users and which delivers them emotional satisfaction.

Seth Godin, in his writing on marketing and his excellent podcast Akimbo, talks about the refrain that people repeatedly tell themselves. Namely:

People like us do things like this.

Seth Godin

Or, taken another way, “people like us use products like this”.

Seth explains that anyone involved in marketing needs to reach out to these people, to this audience. Because these are the true believers and advocates for your product.

Before we can do that though, we need to know what the “this” is.

We need to think about image – or the reflective qualities of our product (thanks Don Norman!). What are the stories that the product tells about itself, and which the user can then tell about themselves?

Whether it’s a travel app that signals that we, the users, believe in fundamentally connecting to the places and people through which they pass, or a luxury sportscar that signals their owner has status, that they’re powerful and part of an exclusive group.

When we do this, we’re on the right path to deliver satisfaction and increase the chances of a successful product. So yes. Yes desirability is 100% part of UX.

 

A guide to roadmap planning with empathy

Recently I’ve been running roadmapping sessions and MVP planning sessions with Outlandish, the worker-owned tech agency.

Combining elements of design thinking practice as championed by IDEO and Stanford’s d.school, and mixing it together with great advice from Jon Kolko on how to think about emotions and roadmaps, they’ve gone pretty well.

Here’s a process for running something similar with your own teams:

When to use this:

  • Planning the future for an existing product, particularly one which might be underperforming.
  • Or planning a new product’s MVP (Minimum Viable Product).

If you’re working on a new product, you could run these activities as part of a Design Sprint. Some good places to do it are after the creative activities (sketching out initial ideas), or after the user testing of the prototype at the end of the Sprint.

Time required:

~ 0.5 day with your team

Step 1: Identify the users

Ask the team to identify who they think are the important users of the product. What do I mean by users? Not demographics, but rather people in situations.

No: An English woman in her mid 20s.

Yes: A press officer in a mid-sized NGO.

Yes: A press and PR team manager in a mid-sized manager.

Get everyone to write as many as they can, one per sticky note. They can hang on to their sticky notes for now, no need to gather them up.

Include the internal users

Whatever you’re building you’re likely going to have a few extra, critical users to think about. There’s the end user/customer, that’s for sure, but maybe you’ve got some wider stakeholders who connect with your product in some way to address; for example, other teams, external services, funders, CEOs and more.

Who do you have to convince your project is worth partnering with, building upon or funding?

Make sure that these people are captured as users too, because even though they might not be using the product directly, they still have an experience that relates to it.

Make sure you have a diverse range of users

In this situation, and if you’re running this process with a team, different team members will likely choose the most important users from their point of view.

On the off chance that everyone picks the same user, or if you’re running this with just one person, then encourage the identification of a few more users.

Step 2: Pick the most important user

Ask everyone to individually choose what they think is the most important problem and user. It’s good to say “important” rather than “biggest” or “urgent” or such here, as it leaves this open to interpretation. The criteria of “important” is up to each team member.

Everyone should make a note of their problem on another sticky note. Again, they can hang on to these.

Step 3: Turn the problem into a Point of View Problem statement

Championed by the Stanford Design School, a point-of-view (POV) “is your reframing of a design challenge into an actionable problem statement that will launch you into generative ideation”.

That sounds like fluff, but the key here is “actionable statement”. Rephrasing the problem into such a statement really does help stimulate creative activities. So here’s how we do it:

Everyone thinks about the user and problem they just captured. Take the problem sticky note and use it write a statement about your user, in this format:

[USER] needs to [USER’S NEED] because [SURPRISING INSIGHT]

One of the best examples I’ve seen of this, also from Stanford’s Design School, runs:

The project: Redesign the ground experience at the local international airport

The user POV: A harried mother of three, rushing through the airport only to wait hours at the gate, needs to entertain her playful children because “annoying little brats” only irritate already frustrated fellow passengers.

Note the surprising insight part. It’s not something broad and basic such as “because children annoy other people”, but something that believably conjures a real scene and is empathetic to the user (we’d all hate our own kids to be thought of as brats).

Ask your team to create their own POV Problem Statement for their chosen user on a third post it. Once this is done they can trash the problem sticky – they don’t need it anymore.

Ask everyone to read out who their main user is and their POV Problem Statement.

Step 4: Identify the value

We’re going to put the work done so far aside for a moment (we’ll come back to it shortly), and now think about value.

Jon Kolko, in his book Well-Designed: How to Use Empathy to Create Products People Love, has a great explanation about value and it’s worth getting his book to understand the importance of ‘value’ on a deeper level.

In short, there are many types of value: economic, social, personal, spiritual, emotional. Value is whatever the user feels it to be.

We’re going to ask our team to take a moment to think about the value that their user gets from using the product. For example, is it monetary savings (economic)? Increased influence in their network (social)? And so on..

Give it a few minute or so….

Turn value into an emotional statement about value

Now it’s not actually the value that someone receives from a product which is important, but rather their perception of and emotional reaction to this value which is most crucial. This is crucial to the idea of satisfaction, which, along with utility and usability, is a key component of UX.

So everyone needs to take the value they’ve identified and turn these into an emotional statement, from the point of view of the user.

In other words, everyone writes how the user feels after using their app.

It doesn’t matter that we don’t know what the solution is or what we’re building yet. But we can still imagine a future where our product exists and users are engaging with it.

And if we can imagine this, we can imagine how they feel after using it.

For example:

“After using our financial advice tool, the user feels comfortable and secure that they are making the best investment decisions with their savings.”

Everyone write a Value Statement on a sticky note.

Create swimlanes on the board

That’s already a lot of work and a lot of sticky notes! Now is the time when we come together and start to work more collectively.

Each member of the team takes their sticky notes for User, POV Problem and Value Statement, reads them out and puts them up on the board.

As facilitator, make sure they go up on the far-left of the board, with plenty of space to the right (you’ll need a lot of space in later steps). Also, make sure they are arranged in swimlanes, so it looks like this.

User | POV Problem | Value statement

User | POV Problem | Value statement

User | POV Problem | Value statement

The ordering and tidiness are important here, because things will get messy later!

If there are any duplicate users that’s fine, they can be merged. Talk about it with the team.

If there are duplicate users and duplicate POV statements, you might want to combine these into the same swimlane.

Step 5: Generate feature ideas

Now this is actually one of the hardest parts of the process, so stick with it and you’ll see some real gems come out at the end.

In short, you need the team to generate ideas for what their solution to this problem may involve.

If you’re doing this after already working up some solution ideas….

E.g. you’re running this as part of a traditional, Google Ventures style Design Sprint – then you’ll probably have some ideas and sketches already created to draw upon.  Maybe you’ve already tested a prototype and have some feedback too.

… else if not, and this is an existing product:

It might be worth pausing to:

  • show the existing product, just to refresh everyone’s minds about what it looks like and can do
  • review any user testing research already undertaken
  • pull out that ever-increasing list of ideas, suggestions and anything from the old backlog

Tip: to help facilitate this and ensure that momentum is maintained, avoid crowding around a screen. Instead, prep the room in advance:

  • post screenshots of the product up all over the place
  • put up quotes from users and test subjects
  • generally, provide a lot of eye candy around the room

… or if this is for a completely new product

If you’ve launched straight in to this and haven’t done any idea/solution generation yet, such as you might do in a traditional Design Sprint, that’s fine. However you’ll need to pause at this point to run some activities to generate some of these creative solutions.

I recommend taking a flip through the Design Sprint book and running the activities for Crazy 8s and Solution Sketches here.

  1. Crazy 8s: a brain-dump sketching exercise, each person making rough sketches showing a possible solution, 1 per minute), leading to…
  2. Solution Sketches: taking one of these ideas and, over a good hour or so, each person sketching out some key screens to show what the user sees.
  3. Then a presentation of each person’s work and the team decide which idea (or aspects of the various ideas) to take forward.

These will help decide the overall concept to be used in the next steo=p.

Capture the ‘epic’ feature ideas

Using everything that’s been researched and discussed so far, and the ideas proposed and decided upon, everyone jots down the large-scale features (here it is the user-facing functionality) that need to be built.

Write one feature per sticky note.

For example, for a financial advice app, large scale features might include:

  • Show customer finances
  • Share data with accountant
  • Email updates
  • Show market data
  • Live chat with financial advisor
  • Printable reports
  • … etc

Get the team up, read them out one by one and slap them on the board to the far right of your post notes.

Any duplicates or overlaps can be grouped together.

Tip for facilitators: People often forget to allow for building the common product features, so it’s worth prepping a few extra sticky notes in advance. Some typical examples include:

  • Update account information
  • 2 step verification / account security
  • Alerts
  • Social sharing
  • Charts, visualisations
  • … etc

If they’ve not already been added, make sure these go up on the board too.

Step 6: Get ready to roadmap

Identify the MVP or first phase features

Now, really channeling Jon Kolko’s great roadmapping exercise, each team member takes a note and asks their colleagues: can we achieve value for our chosen key users (and solve their problems) without this feature?

If yes, leave it where it is on the board. If no, move it to the left side and place it in the appropriate swimlane next to your User. POV and Value statement.

It’s a bit of an about-face and abstract way of looking at features, and you might have to explain it a few times to the team.

After all the team have reviewed these, you’re going to end up with a stack of sticky notes and features on the left hand side swimlanes, near the appropriate User, POV problem and Value Statements.

Well done! You’re halfway to having a list of features for your MVP or first phase of work. Draw a line to make sure these are all in a nice, tidy column. Then draw an axis along the bottom of the board to show time.

Break it down

However, in reality I’ve found that there are often still too many features for an MVP / Phase 1 of work, and many of these features aren’t minimal enough to be truly considered MVP features.

So what works now is to separate them out further and put them into a series of phases.

Draw some more columns on the board after the MVP / Phase 1 column. Each of these columns represents phases in your project’s lifecycle (not Sprints, Agile fans, we’re not at that level yet).

Now brief your team to think more about the features that are in the MVP column. Ask them to think carefully about each of these and spread them out more. Ask them to consider:

  • The extent to which this feature delivers the value – compared with other features, does it deliver a huge amount of the value, or only a small amount
  • The market size –  what % of your users are going to benefit from this feature
  • The return (or if you’re looking at income, the margin) on delivering that feature
  • Feasibility of delivering it (how challenging does it feel in terms of tech, resources, organisation buy-in etc…)
  • Can any of these epic features be broken into parts, (e.g. ‘send text message alerts’, then later ‘users can edit alert settings’)

And remember, the team need to keep asking: how critical is this? Is this feature really something that must be delivered in order for the first phase to work/deliver value/succeed?

It’s likely that once you get everyone thinking along these lines, they’ll start to realise that the features already placed in the MVP / Phase 1 column aren’t all critical, and many can be moved along to later phases.

You’re aiming to end up with a spread of features across the many phases of your project. This will take some time and needs good, relaxed discussion. So make sure it stays on the feet and at the board.

Hopefully at this point you’ll see a good list of feature ideas broken out along the board. There’s probably still going to be quite a few, so now is the time to channel your inner Design Sprint facilitator: break out the voting dots!

Choosing what to do:

Give people 3 or so dots, and ask each person to vote on which ones they think are the priorities. That should help agree priorities for work and effort.

And that’s it! At this point you’ll have a roadmap! You’ve identified your core users and who your roadmap serves; you’ve captured their challenges and value they’ll get from your product, when it is launched; and you have a roadmap of phased work and features to launch.

All that is left to do now is take it to your teams and stakeholders, and begin

And, of course, update it. Regularly.

Good luck with your products!

 

Building careers in UX

A few months back, I co-hosted a UX careers meetup with UX designers, as part of the Interaction Design Foundation – London branch.

Taking place at London’s Space4, it was a chance to discuss how we can grow in UX, how to find UX jobs, how to build careers, what makes a good UX portfolio and more.

In the spirit of sharing things of value, here are the notes from the day:

UX Interviews

Lauren, a starting-out designer, observed that in a recent UX interview, as her potential employers looked over her portfolio she noticed that they were more interested in the processes she went through in her work than the final design. They were interested in the research and the iteration, rather than the final output.

In a similar vein, Kayleigh from the tech agency Outlandish agreed that being able to show good process was an important skill and appreciated by prospective employers.

For example, when taking a test as part of the interview, if you do something so simple such as save out the work properly in a format that the wider team can use, this demonstrates that you know the correct processes.

Tools and the UX job search

This carried over into your choice of UX tools.

In short, amongst those who’d been to interviews recently, it was felt that interviewing companies didn’t seem that bothered about which tool you were most familiar with. It didn’t matter if you were a Sketch person, or XD person, or whatever; it was more important to demonstrate that you’re good with the process of design.

The tool isn’t you. You can learn the tool.

Wireframing skills and the UX job search

Kayleigh from Outlandish wasn’t interested in recruits showing finesse or fidelity of a wireframe, but more that they were able to demonstrate clarity of a concept.

“We value the skill of being able to sit, sketch on paper with a client and be able to show the user journey and layout. Our test of a good wireframe isn’t the finesse or straight lines. It’s whether someone can walk over and understand exactly what it is.”

Kayleigh Walsh, Outlandish

How to find UX jobs

“Call the company and tell them that you emailed. They like it and it’s a nice touch.”

Lauren

Lauren again observed that, one time, she missed the deadline to submit an application but submitted anyway. She called the company, told them that she’d missed the deadline but had submitted. And then she was added to the final round of candidates.

Kayleigh at Outlandish told us that Outlandish only work with people we meet. So we should all go to events! Go to meetups! Go to parties! Relax and chat to people there bout what interests you.

That’s how the Outlandish team discover interesting people and learn about the things that motivate them and they enjoy working on. From there, the Outlandish team might want to start collaborating with them and they’ll reach out to them to ask them to come to an interview.

Culture Fit

Does culture fit matter when you’re looking for work?

We all felt: yes. Because you’re going to be at the company every day, it’s important to research and find a fit that feels good for you

Tip: Research the companies you’re applying to. Look at their finished projects or portfolio. Depending on who they work with, you’ll get a feel whether this is a nice place to work in.

Ask yourself: Do this company work with nice people? Do they seem flexible? Are they ethical?

Again, Kayleigh from Outlandish, added:

“When we’re talking to potential designers, we want to hear that they believe in similar things that we do (fairer society, positive social impact, ethical behaviour etc). It’s important for us to work with people who aren’t just in it for the money.”

Kayleigh Walsh, Outlandish

UX Mentors

Get one. Mentors are really useful, either in a formal or informal capacity. And it’s easier to get one than you think.

All you need do is just ask a designer you know or are friends with for some occasional support or the chance to have a regular conversation… and hey presto, now you have yourself a mentor.

If you are looking for more formal mentoring opportunities, you can start your search at:

  • UXPA’s mentoring programme
  • Hexagon UX‘s mentoring programme, designed to support women and non-binary people working in UX.

“Hexagon UX’s mentoring programme is like speed dating for mentors!”

Tell employers what you’re learning

Is it worthwhile telling interviewers what you’re studying? Is it a good idea to tell prospective employers that you’re taking courses at the Interaction Design Foundation or elsewhere?

Yes. Tell people you’re doing courses. It shows you’re interested and always developing yourself.

UX hackathons

Rosie, a junior UX designer, advised that we should all do them. You learn so much, they’re very galvanising and the work you do there tends to go straight into your portfolio.

What happens at a hack?

You get mixed up into groups and work with people to make something. It’s intense. You also learn about the business case around the products you’re designing, which is something you might not experience in a learning environment.

It’s worth pointing out that anyone can join a hackathon, and you don’t need tech skills. Hackathons often have lots of developers and are actually short of designers. So if you go, you’ll be in demand!

There are hackathons everywhere. Small to big ones. And if you’re interested in political or ethical based hackathons, you can take a look at NewSpeak House, which often hosts politics-based hacks.

UX careers resources

  • Behance Live – they do a tutorial every day

This being an Interaction Design Foundation meetup, we also shared the courses we’re all doing and can recommend:

Coworking spaces – good to find work opportunities

We discussed how if you’re actually in a space you end up talking to people and collaborations and opportunities just tend to start happening.

So consider joining a coworking space that has a very open, collaborative atmosphere.

Space4 is just one such coworking space. Based in London’s Finsbury Park, it’s home to a lot of smaller non-profits and developer teams who would probably love to meet UX designers and collaborate.

A stay at Space4 might lead to a good conversation and a great portfolio project… or even might help a startup get funding and further paid work.

And that’s it! Those are all the notes. Hope that’s all been of interest.