Make business processes accessible through a web application designed for your users.
Discuss your projectA web application lets people complete a task in their browser, such as recording an issue, updating information or viewing a report. The design covers the whole user journey: understanding what is needed, entering data, correcting errors and establishing what has been saved. OXIAE works through these steps with you before building the screens. The broader choice between existing products and custom software remains the starting point.
This fits when people in different locations need to complete a specific task in the same application and existing screens do not support it well enough. Start with one complete task and the people who do it in their work. If the tasks specifically concern external customers, their records and information released to them, consider a customer portal.
An informational website or existing form may be enough when someone only needs to read information or leave a simple message. If it is still uncertain whether the intended users need the proposed task, an MVP can investigate that product assumption first. A complete application is not automatically the right first step.
A web application needs more than completed screens. I design the full user action: gaining access, entering information, saving and resuming later. We establish what happens when a session expires, a value is invalid or the connection drops while saving. [1]
The server checks data and permissions even when someone bypasses the browser interface. Forms and navigation include accessibility requirements. Acceptance therefore covers keyboard use, error recovery and different user roles opening the same shared link, alongside the successful path. [2]
This is a fictional design example, not a client case or tested application. An employee reports a faulty light through their browser. The first version covers location, description, an explicitly saved draft and a confirmed report; photos, offline use and automatic draft saving are outside this example.
The employee selects “Report a fault”. The form explains the required location and description. On the agreed phone layout, these fields appear one below the other. Keyboard focus moves through fields and actions in a logical order; each field has a recognisable label.
If the room is missing, the form identifies which field needs completion and how. The entered description stays in place during this correction. The employee can reach the field through the error message; colour alone does not convey the error.
This trial uses an explicit “Save draft” button. The draft is stored on the server and receives confirmation only after successful storage. Access and retention are defined beforehand; this example does not persist the content in the browser. A draft confirmation does not mean the report has been submitted.
The session expires during a pause. The employee signs in again and opens the confirmed draft from step 3. Changes not yet saved are not presented as recovered. The employee checks the content; signing in again sends nothing.
No response arrives after “Submit report”. The screen says the outcome is still unknown. The application uses the fixed submission reference to check whether the report was recorded. Resubmitting the same submission must not create a second report; the outcome remains uncertain while the check is inconclusive.
Only when the server confirms the stored report does “Report recorded” appear, with its reference and content. The employee can reopen the result. This confirms registration, not a scheduled repair. The feedback and next action are also tested on the agreed phone screen and with keyboard controls.
The design distinguishes input in the form, a stored draft, an uncertain submission and a recorded report. Each state gives the employee a concrete next step. The agreed acceptance tests establish whether this works correctly in the eventual application.
Choose based on the task, the people involved and what you can maintain.
| Approach | Useful when | What to consider |
|---|---|---|
| Existing form or application | The task, checks and feedback fit the current capabilities. | Check the complete journey, including corrections, confirmation and interruptions. Providing similar fields is not enough. |
| Custom web application | The input, interaction and displayed outcome require a dedicated user journey. | Storage, sessions, error handling and operation belong in the agreed scope alongside the screens. |
| Clickable prototype before development | The main uncertainty is whether users understand the proposed screens and steps. | A prototype can explore the interaction; it does not yet demonstrate working storage, recovery or processing with real data. |
A useful estimate starts with the scope. I distinguish development work from recurring usage and operating costs. These are the main drivers:
Teams or customers need to work with shared information from multiple locations.
A web application is accessed through a browser, but its users and permissions depend on the application. A customer portal serves external users. If the product idea is still uncertain, an MVP can test one important user step before a broader application is developed.
Which user groups exist, and which actions must they be able to perform?
Use the prerequisites, acceptance checks and cost factors above to define your assignment. Agree who can approve the outcome and who will maintain the solution. The project approach explains discovery, delivery and handover.
Read the project approachAn estimate starts with a complete user task and the situations that must work. Field count says little without checks, screen states, storage, integrations and recovery. I make the first scope and acceptance concrete, with development and recurring costs set out separately.
We first define the required browsers, screen sizes and ways of operating the interface. Then we test the complete task: input, correction, submission and opening the result. A screen that scales down does not by itself establish that the journey is usable.
That depends on the agreed draft route. Explicit saving, automatic saving and entering data again involve different access and retention choices. I do not promise preservation without designed and tested recovery. After signing in again, users must be able to tell which content was confirmed saved and which changes need to be entered again.
Confirmation belongs to a result the server confirms is stored and that the user can reopen. A timeout does not prove failure. The application must first check the outcome and prevent a repeated submission from recording the same entry twice. Confirmed registration establishes only the agreed storage, not subsequent handling.
These primary sources explain the technical principles behind this guide. The project recommendations are OXIAE’s interpretation; they do not imply endorsement by the publishers. Product documentation applies to the named platform.
Testable criteria for forms, navigation and error messages.
Link and relevance checked:Authorization checks on each relevant server request.
Link and relevance checked:Exploring Web application development? Use the project checklist to describe your task, systems and intended outcome. Collect open questions and download a brief for your conversation.
Create your project brief