User experience
and interface design
in Baltimore

Small usability tests have a reputation for being fast and cheap. They are. Five people, one task list, a day of sessions and a day of analysis. The method finds a surprising number of problems in a new flow. It also has limits that teams forget once a round goes well.

The logic behind five is simple. Serious usability problems tend to affect many people. When the first participant stumbles on a confusing label, the second and third often stumble too. By the fifth session the same obstacles keep appearing, and new ones become rare. At that point, another session teaches less than fixing what you already saw and testing again.

That logic holds for a single group doing a single set of tasks. If the product has two very different audiences, such as buyers and administrators, five people means five of each. Mixing them produces a muddy picture where nobody sees the full set of problems for either group.

Recruiting decides the value of the whole exercise. Participants should resemble the people who will use the product. Colleagues from another team are not a substitute. They know the jargon, the company and often the product. Find people outside, screen them with a few questions and pay them for their time.

Write tasks as goals, never as instructions. Ask the participant to find out whether an order can still be changed. Do not ask them to click the orders tab. The difference sounds small. It is the difference between testing the interface and testing whether they can follow directions.

During the session, the moderator mostly stays quiet. Ask the person to think aloud. When they get stuck, wait. Offer help only if they are about to give up, and note that you did. Every hint changes what you learn.

Now the limits. Five sessions cannot tell you how many users will fail in real life. They cannot compare two designs with any confidence. They say little about preference, pricing or whether people want the product at all. They reveal problems. They do not measure them.

They also miss rare problems. An issue that affects one person in twenty may never appear. Accessibility barriers are a common example. A screen reader user will find problems a sighted participant never meets. Test with those groups separately and deliberately.

Write findings down the same day. List each problem, how many participants hit it, how severe it was and a short clip or quote. Share the list with the team in a working session rather than a long report. Then fix the worst problems and run another small round. Repeated small tests teach more than one large one.

Remote sessions work well for most software, and they make recruiting across a wider area much easier. Ask participants to share their screen, check the recording works before starting and keep a backup channel such as a phone number in case the connection fails. In-person sessions still help for physical products, kiosks and anything where posture, lighting or the device itself matters to the experience.

Invite the wider team to watch at least one session live, whether that means product managers, developers or the person who writes support articles. Watching a stranger struggle with a screen that seemed obvious in a review changes opinions faster than any written finding, and it makes the later conversation about priorities much shorter.

Settings pages grow quietly. Every time a team cannot agree on how a feature should behave, somebody suggests making it configurable. Each toggle looks harmless. After a year the page holds dozens of options, half of them unused and a few that break other features when combined.

The first defence is a rule about what belongs there. A setting should exist when different users genuinely need different behaviour and can make the choice themselves. Language, time zone, notification frequency, default currency. A setting should not exist to postpone a product decision. If the team cannot decide, test both options and pick one.

Defaults carry most of the weight. The majority of people never open settings at all. Whatever the product does out of the box is, for them, the product. Spend time choosing each default and write down why it was chosen. The note helps the next designer who wonders whether it can change.

Group settings by what the person is trying to do. Account, notifications, privacy, billing, team. Avoid grouping by the internal structure of the code or the teams who built each part. Users do not know which department owns email alerts, and they should not need to.

Write each label as the outcome, then add a short line of explanation below it. Send a summary every Monday tells people what happens. Enable weekly digest does too, but less clearly. For anything with a side effect, spell the effect out. Turning off two-step sign-in makes this account easier to take over.

Separate personal preferences from team or company settings. In a product used by organisations, an administrator often controls options that affect everyone. Show clearly which settings apply only to the current person and which change things for colleagues. Put the second group behind a confirmation.

Some settings are dangerous enough to deserve a separate area at the bottom of the page, set apart visually from everyday options. Deleting an account, transferring ownership or resetting all data belong there, each with a clear description of what cannot be undone and a confirmation step that asks the person to type something rather than click twice.

Save behaviour needs a decision. Some products save every change instantly. Others wait for a save button. Both work. Mixing them on one page does not, because users cannot tell which changes stuck. Pick one pattern and show a small confirmation each time something is saved.

Search helps once the list is long. So does linking to a setting from the place where it matters. If a person is annoyed by an email, a link at the bottom of that email should open the exact setting that stops it.

Review the page every few releases. Check which options are used, which are never touched and which generate support tickets. Remove what nobody needs. A shorter page is easier to understand and cheaper to test.

Developers feel the cost of settings even when users do not. Every option doubles the number of combinations that have to work, and some of those combinations will never be tested by anyone on the team. When a new setting is proposed, ask how it will interact with the existing ones, who will write the tests, and which support article will explain it. That conversation often ends the proposal on its own, which is usually the right outcome for everyone involved.