Try a piece of the work · 6 min read

Is UX design right for me? Test the work, not just the tools

Try a small UX project with a complete brief, a participant task and a worked example. Find out whether observing, explaining and revising interest you.

Written by Nivaan, founder of OffLadder · Last reviewed 10 October 2026 · Sources listed at the foot of this page

Start with use, not a beautiful screen

Redesigning a familiar app can feel productive. It also lets you avoid the difficult parts: what someone is trying to do, why the present experience causes trouble and whether your alternative helps.

The UK Government Service Manual describes moderated usability testing as observing participants attempt tasks with a service. Its guidance emphasises planning the research and paying attention to what people do. That is the professional context for this small exercise, not a claim that one informal session constitutes a complete research study.

Use paper, slides or a document. Allow an hour for a first version, then a little time with a consenting adult volunteer. They do not need design experience.

The brief: book a meeting room without guessing

A fictional community centre lets residents book a room. These are the confirmed rules: the room holds six people; bookings last thirty or sixty minutes; weekday opening hours are 10 am to 7 pm; the centre provides step-free access; bookings need staff confirmation; no payment is required.

Here is the current page:

COMMUNITY SPACE. Reserve your session. Select a block. Standard use applies. Submit details and we will be in touch. Fields: name, contact, preferred block, notes. Button: Proceed.

The page does not state the rules above. For practice, ask the participant to work out how they would request the room for four people next Wednesday from 6 to 7 pm, including someone who needs step-free access.

Use invented contact details. Do not submit a real form or ask the volunteer to reveal personal information. Tell them this is a fictional prototype and you are testing the design, not testing them.

Watch before you fix

Read the task, then let the participant proceed. A useful opening is: “Please say what you are looking for and what you think will happen. You can stop at any time. I did not design this well enough yet, so anything confusing is helpful to notice.”

Do not ask, “Would a clearer button help?” That suggests your preferred answer. Ask, “What do you expect after pressing this?” or “What information are you looking for?”

Record observations separately from interpretations. “Asked whether the room was available in the evening” is an observation. “Does not trust community websites” is an interpretation you have not established.

If you cannot recruit a volunteer, do a structured review yourself and label it as such. Do not invent a participant, quotation or research finding to make the exercise look complete.

Turn one barrier into a design decision

Suppose the participant cannot tell what a block means and assumes submitting the form guarantees the room. Those observations suggest two different needs: making duration explicit and explaining confirmation.

A revised text prototype could read:

REQUEST THE MEETING ROOM. For up to six people. Weekdays, 10 am to 7 pm. Step-free access available. Choose a date, start time and duration: thirty or sixty minutes. Add your name and email. Optional: tell us about access requirements. Button: Send booking request. Your room is not booked until staff confirm availability by email.

This is a possible response, not the correct design in all circumstances. You might decide the page should show available times before asking for details. That would introduce a system requirement, so state the assumption rather than pretending a text change creates live availability.

Keep the first attempt and explain why you changed it. The reasoning is part of the work.

Test the revision without coaching the answer

Ask the participant to attempt a similar task using the revised version. When possible, involve a second adult who has not seen the original, because familiarity can affect how easily the first participant completes it.

Check whether the person can identify the relevant hours, choose a duration and explain what happens after submission. Do not declare the redesign successful merely because they say it looks better.

If they still hesitate, ask what they were expecting. The next improvement may concern order, terminology or missing information rather than visual styling. Resist adding every possible explanation. A page can become harder to use because it tries to answer too many questions at once.

Include accessibility without pretending to certify it

Think about readable labels, meaningful order, clear instructions and whether essential information relies on colour alone. For a real digital prototype, W3C's Easy Checks provides a starting point for examining accessibility. W3C explicitly presents these as preliminary checks, not a complete accessibility evaluation.

A successful test with one person does not establish accessibility for everyone. Do not claim the service is accessible because your volunteer completed the task, or ask someone to represent an entire disability group.

The practical lesson is to notice whose experience your evidence does and does not cover. That habit matters more than attaching a reassuring badge to the prototype.

What a useful case study would contain

Keep it short: the task, confirmed constraints, participant consent and method, observations, proposed change, second test and unresolved questions. Label the project as a fictional practice exercise.

A credible conclusion might say: “The revised wording made the request-versus-confirmation distinction clearer in this small test. I have not tested the full booking journey, live availability or the experience of people using assistive technology.” Use that outcome only if your test actually supports it.

Do not invent percentages from a tiny exercise. Do not claim a conversion improvement when nobody was making a real booking. You can show careful work without pretending it was a commercial project.

Did you enjoy the part that changed your mind? Reflect on the sequence. Was observing another person interesting? Did you want to understand why they hesitated? Did you enjoy simplifying the explanation? Were you willing to remove a design choice you liked because it did not help?

You might discover a stronger interest in research, content or visual design than in the whole UX label. That is useful. Investigate the relevant work instead of deciding that one broad title must fit all your preferences.

Do I need to learn design software first? Not for this experiment. Tools become useful when they help you test or deliver something. A polished screen without a clear problem is not a better test of fit.

Does this mean I am ready for a UX job? No. Professional work adds larger studies, technical constraints, collaboration, ethics and delivery. Use the exercise to decide whether to learn more, then check actual entry requirements and obtain informed feedback.

Bring the observation into your next step

OffLadder helps you find directions worth testing and retain what the tests reveal. Tell Laddie which part of this exercise interested you: watching, interpreting, writing, prototyping or revising. Save the prototype and the limitations in You, and use Explore to investigate a related direction rather than immediately buying a full programme. Find something else to try. The useful question is not whether you like the idea of being a designer, but whether you want another encounter with this kind of work.