Design for real conditions
Digital products are often conceived and tested in environments with strong connectivity and recent hardware. Users, however, frequently access them on mid-range phones, over variable mobile data, and with limited data allowances. A website that loads slowly or an app that fails when the network drops does not simply frustrate users; it excludes them.
Designing for real conditions is therefore a matter of inclusion as much as of engineering quality.
What real conditions include
- Devices. Mid-range phones with limited storage and memory, sometimes shared among family members.
- Connectivity. Variable mobile networks, interruptions and congestion at busy times.
- Data cost. Users who ration data and avoid large downloads or heavy pages.
- Power. Intermittent electricity and short battery life.
- Language and literacy. Users who read in a second language, or who prefer short, visual instructions.
- Context of use. Outdoors, in noisy places, or while doing another task.
Writing these conditions down at the start of a project, and testing against them, is one of the simplest and most effective quality measures a team can adopt.
Principles for websites and web platforms
- Prioritise mobile first. For many users the phone is the only device; layouts and interactions should be built for it, then extended to larger screens.
- Keep pages light. Compress images, limit scripts and avoid unnecessary media so that pages load quickly on mobile data.
- Make content easy to maintain. A platform that only a developer can update will become outdated; choose structures that non-technical staff can manage.
- Write plainly. Clear language and logical navigation serve every visitor, including those reading in a second language.
Keeping pages light
Heavy pages cost users money and time. The main culprits are large images, many scripts and auto-playing media. Compressing images to appropriate sizes, loading only what is needed on each page and testing on a throttled connection can transform the experience. A useful habit is to set a page-weight budget at the start of a project and to check each new feature against it.
Content that staff can maintain
Many websites decay because updating them requires a developer. Choosing a structure that lets non-technical staff publish news, change contact details and add documents keeps the site current and credible. Handover training should be part of every project.
Plain language and clear navigation
A visitor should know within seconds what the organisation does and how to reach it. Short sentences, familiar words and a simple menu help every reader, and especially those reading in a second language.
Principles for mobile applications
An application should be planned around the job it must do, not around a list of features. Begin by describing the user, the task and the environment in which the task occurs. Then decide what the app must do when the connection is weak or absent.
- Support offline use where the task allows, storing entries locally and synchronising when a connection returns.
- Minimise data consumption and file sizes.
- Keep the interface simple, with large touch targets and few steps to complete a core task.
- Fit the way people already work, so that the app replaces a process rather than adding one.
Offline-first thinking
In an offline-first design, the app treats the local device as the primary place where work happens. Entries are saved immediately on the phone and placed in a queue. When a connection returns, the app synchronises the queue in the background and tells the user what has been sent. The design must also decide what happens if the same record is changed in two places, and must make failures visible so that users never wonder whether their work has been saved.
Accessibility basics
- Use sufficient contrast between text and background, and do not rely on colour alone to convey meaning.
- Provide text that can be enlarged without breaking the layout.
- Label buttons and fields clearly, and keep forms short.
- Offer clear error messages that say how to fix the problem.
- Test with people who have different abilities and levels of experience.
Accessibility is not a separate feature to be added at the end. It improves the experience of all users, including those in bright sunlight, on small screens or in a hurry.
User experience as a discipline, not a finish
User experience design is most effective at the beginning of a project, not as a final polish. Brief conversations with intended users, simple sketches and early prototypes reveal misunderstandings when they are cheap to correct. Observing a person attempt a task without assistance is more informative than any amount of internal discussion.
| Method | When to use it | What it reveals |
|---|---|---|
| Short user interviews | At the start | Who the users are, what they need and what they do today |
| Paper sketches and simple prototypes | Before building | Whether the proposed flow makes sense, at very low cost |
| Observing users attempt a task | At any stage | Where people hesitate, make mistakes or give up |
| Quick feedback sessions on early versions | During the build | Which features matter and which can wait |
| Post-launch feedback and usage review | After launch | How the product performs in daily use and what to improve next |
None of these methods requires a large budget. Five conversations with real users will often reveal problems that no amount of internal discussion would find.
Testing before launch
Software that has not been properly tested tends to fail at the worst moment, in front of the users it was meant to serve. Effective testing covers functionality, performance on low-end devices and slow networks, usability with real users, and security basics such as access control and data handling. Defects found before launch cost a fraction of those found afterwards, and testing protects the credibility of the organisation behind the product.
| Type of testing | What it checks | Example |
|---|---|---|
| Functional | That each feature does what it should | Can a user register, save a record and retrieve it? |
| Performance | Speed and stability on low-end devices and slow networks | How long does the main page take on a throttled connection? |
| Usability | Whether real users can complete tasks unaided | Can a first-time user submit a form without help? |
| Compatibility | Behaviour across devices, screen sizes and browsers | Does the layout work on small and older phones? |
| Security basics | Access control and data handling | Can one user see another user's records? |
| Accessibility | Whether people with different abilities can use the product | Can text be enlarged, and are fields labelled? |
A pre-launch checklist
- Core tasks tested end to end on at least two low-end devices.
- Behaviour checked on a slow connection and with the connection lost mid-task.
- Real users have completed the main tasks without help.
- Access permissions and data handling reviewed.
- A plan exists for fixing problems reported after launch, and a named person owns it.
Common mistakes
- Designing on fast connections and new devices only.
- Adding features before understanding the job to be done.
- Leaving user research until after the build.
- Treating testing as a final step that can be shortened when time is short.
- Launching with no plan to maintain or update the product.
