UX design is not a final coat of visual polish. It is the work of understanding what people need to accomplish, shaping the whole journey around that task and testing whether the result makes sense before expensive development decisions become difficult to change.
01
A tidy screen can still create a difficult day
Imagine an operations team reviewing customer applications. Their new portal looks modern. The colours are consistent, the buttons are rounded and the dashboard has several handsome charts. Yet staff still keep a spreadsheet beside it because the portal hides the information needed to make a decision.
Every application requires opening several tabs. A status called pending could mean waiting for the customer, waiting for a colleague or waiting for a payment. Staff copy the same reference into email because the system does not preserve the conversation. The interface looks better than the old one, but the work has not become easier.
That gap is where user experience design matters. UX design looks beyond the appearance of an individual screen. It asks who is using the product, what they are trying to achieve, what information they need, which interruptions and exceptions are normal, and how the product should help them reach a clear outcome.
Good UX is not decoration added after the important software has been built. It helps decide what the software needs to do in the first place.
02
UX, UI and service design are related but different
User experience, usually shortened to UX, covers the complete experience somebody has while trying to achieve something through a product or service. That includes the steps they take, the language they read, the information available, the feedback they receive and what happens when the ordinary route goes wrong.
| Discipline | Main question | Example output |
|---|---|---|
| UX design | Can the user understand and complete the task? | Journey, information structure, prototype and usability findings |
| UI design | Is the interface clear, consistent and usable? | Layouts, components, typography and interaction states |
| Service design | Can the whole organisation deliver the outcome? | Service map, responsibilities, channels and operational hand-offs |
User interface design, or UI, is the visual and interactive layer. It covers layout, typography, colour, components, spacing and the behaviour of controls. A clear UI supports a good experience, but it cannot rescue a journey built around the wrong process.
Service design looks wider again. It connects the visible experience with the people, policies, systems and offline work behind it. A customer may submit a request through a simple form, but the overall service still fails if the information enters the wrong queue and nobody takes responsibility for the next step.
03
Start with the task, not the feature list
A feature list often describes the software from the organisation's point of view. It might ask for a dashboard, document upload, notes, statuses and reporting. Those features sound sensible, but they do not explain how somebody should use them to finish a piece of work.
UX work starts with the task. For the application portal, a reviewer may need to decide whether the submitted evidence meets a particular rule. To do that safely, they need the customer details, relevant product, documents, previous queries and decision history together. The useful design question is not where should the notes button go? It is what does the reviewer need to know and do before they can make this decision?
This change in perspective can reduce scope. A large dashboard may be less valuable than a focused work queue showing the next case, why it needs attention and how long it has been waiting. A separate reporting module may not be needed if managers can answer their main questions from a well-designed list and a small set of trusted totals.
The feature list becomes stronger after the journey is understood because every feature has a job. Anything without a clear user or outcome deserves another question before it enters the build.
04
Research what people really do
People are not unreliable because they describe a process differently from the procedure document. Work changes around deadlines, missing information, customer behaviour and the limitations of existing systems. The unofficial steps are often what keep the operation moving.
Useful research may include watching staff perform a task, interviewing customers, reviewing support queries, studying analytics or examining the spreadsheets and email templates sitting beside the official software. GOV.UK guidance recommends learning who users are, what they are trying to do, how they do it now and where they experience frustration.
For the portal, observation may reveal that experienced reviewers open applications in a different order because one document usually exposes problems early. New staff may rely heavily on a checklist that the current system does not show. Customers may call support because an instruction written in internal language does not tell them which evidence is acceptable.
Research does not mean collecting every request and building it. A user may ask for another export because the existing software cannot answer a simple question. The need is trustworthy visibility, not necessarily a new spreadsheet button. Good UX separates the underlying need from the workaround somebody has learned to request.
05
Map the whole journey, including the awkward bits
A polished happy path is easy to design. The customer enters perfect information, every connection responds immediately and the application reaches approval without a query. Real business software spends much of its life dealing with everything that did not happen perfectly.
Map the journey from the event that starts the task to the outcome that finishes it. Include the moments where responsibility changes, information is missing, a third-party service fails or somebody needs help. Show both the customer and staff experience where their actions affect one another.
In the application portal, a customer might upload the wrong document. The reviewer needs to explain what is missing without starting the case again. The customer needs a clear notification, access to the same case and confidence that the replacement was received. The reviewer then needs the case returned to the right queue with the history intact.
Designing that loop early affects more than the screens. It can change statuses, permissions, notifications, the database and the reporting model. UX design therefore belongs alongside technical and operational decisions, not in a separate room after them.
06
Use wireframes and prototypes to make assumptions visible
A wireframe gives the proposed structure enough shape for the team to discuss it. A clickable prototype lets somebody attempt the journey before the production system exists. Both are cheaper places to discover that two directors imagined different products or that staff cannot find the information required for a decision.
Start with the lowest level of detail that can answer the question. Rough wireframes are useful when the order, terminology or responsibilities are still changing. A more realistic prototype helps when users need to judge a detailed interaction, conditional form or multi-role workflow.
Test a complete task rather than presenting a gallery of attractive screens. Give a reviewer a realistic case with one missing document and watch what they do. Avoid coaching them through each control. Hesitation, wrong turns and repeated questions are evidence that the design needs work.
A prototype can demonstrate a journey, but it does not prove production security, performance, accessibility or integration reliability. Record what was real, what was simulated and what still needs technical investigation. Confidence should not grow further than the evidence.
07
Accessibility is part of the experience
An interface is not easy to use if some people cannot use it at all. Accessibility considers whether people with visual, auditory, physical, speech, cognitive or neurological disabilities can perceive, understand, navigate and interact with the product.
This affects design choices from the beginning. Colour cannot be the only way a status is communicated. Controls need useful labels and keyboard access. Focus order should make sense. Errors must explain how to recover. Text needs enough contrast and layouts must cope with zoom, different screen sizes and assistive technology.
These choices often improve the experience for everybody. Clear labels help somebody learning the process. Larger controls help on a phone. Captions help in a noisy office. A simple error message helps a person who is tired, rushed or using the system in a second language.
Accessibility cannot be guaranteed by running one automated checker at the end. Automated tools find some problems, while manual review and testing with people expose others. It should remain part of design, development and ongoing improvement.
08
Measure the work, not whether people like the colours
Feedback such as looks good or feels modern is pleasant but weak. A business system exists to help somebody complete work safely and efficiently. The strongest measures connect the experience to that task.
For the portal, useful signals might include how many customers submit the right evidence first time, how long a reviewer needs to reach a decision, where applications become stuck, how often staff leave the system to find information and which questions generate support calls.
Combine numbers with observation. Analytics can show that people abandon a step, but a usability session may reveal that the question uses language they do not recognise. Support conversations can expose exceptions the original design never considered. Regular review turns UX from a one-off design phase into a way of improving the product as the operation changes.
Do not optimise one number without understanding its consequence. Removing a confirmation step may make a journey faster while increasing expensive mistakes. Sometimes good UX deliberately slows somebody down before an irreversible decision.
09
Good UX makes the system easier to own
A well-designed experience reduces more than user frustration. It can lower training, rework and support effort. It can make statuses trustworthy, hand-offs visible and unusual cases easier to recover. It also gives developers clearer requirements because the intended task and behaviour have been tested rather than guessed.
That does not mean every project needs months of formal research or a large design team. A focused internal tool may need a few staff interviews, one mapped journey, rough wireframes and two rounds of prototype testing. A public service used by many different people may need much broader research and accessibility work.
The amount of UX work should match the risk and uncertainty. The principle stays the same: understand the task, include the people who do it, test the journey and keep learning after launch.
For the application portal, success is not a prettier dashboard. It is a customer who understands what to provide, a reviewer who can make the right decision with the information in front of them and a manager who can see where the work is stuck. That is the difference between designing screens and designing useful software.
If you are planning a portal, internal system or new software idea, I can help understand the users and workflow, shape a focused prototype and turn the findings into a clearer first build.
Useful questions
Before approving the UX of business software, ask:
- Which real task is this screen helping somebody complete?
- Have we watched the people who currently do that work?
- Does the journey include missing information, failed connections and hand-offs?
- Can users recover from a mistake without starting again?
- Have accessibility needs been designed and tested from the beginning?
- What evidence will show that the experience has improved?
- Are we solving the user need or reproducing an old workaround?
