Web Application Design Built for How Browsers Actually Behave
Interface design for software used inside a browser by staff, dealers, partners or customers — portals, booking systems and self-service tools. GullySystem designs for the browser's own behaviour, not just the screens inside it.
What Web Application Design Covers
A web application lives inside a browser, and a browser comes with habits of its own — a back button, a refresh key, multiple tabs — that a screen design either accounts for or is undone by.
- Covers portals, booking and scheduling systems, dealer and distributor tools, and self-service request screens
- Different from a subscription product's signup, billing and plan screens, and from a purely internal, staff-only admin tool
- Includes the browser-specific behaviour around a screen — its address, its session, its response to being reloaded
- Suited to software used by people outside your own staff, on devices and browsers you don't control
Where Browser-Based Software Breaks
These failures rarely show up in a design review. They show up months later, in a support ticket nobody can quite explain.
The Back Button Discards Work Nobody Meant to Lose
A user fills a long form, presses back out of habit, and the browser throws it away silently, because the application was never designed with that button in mind.
A Refresh Loses the Filter, the Tab, the Half-Finished Entry
A browser reload isn't accounted for anywhere in the design, so everything the user had set up — a filtered list, a partly filled form — disappears and has to be rebuilt from scratch.
A Screen Can't Be Shared Because It Has No Address
A colleague asks to be sent the exact screen someone is looking at, and the address bar only ever says the same generic path, so nothing specific can be linked, bookmarked or handed to support.
Two People Editing the Same Record at Once
A dealer's staff and your own team both open the same order, and whichever one saves last silently overwrites the other, with neither aware anything was lost.
The Application Behaves Differently Wherever It's Actually Opened
Designed and tested in one browser at head office, then opens noticeably differently in whatever older browser a partner's office is still running.
How We Design for the Browser
These are decisions made during design, not left for a developer to improvise mid-build.
Addresses for Every Meaningful Screen
Screens are designed so their address in the browser reflects what's on them, making them shareable, bookmarkable and easy to point support staff to.
Autosave and Recovery
In-progress work is designed to survive a dropped connection, an accidental tab close or a reload, with a clear way back to where the person left off.
Conflict Handling
Where two people might open the same record, the screen is designed to say so, rather than letting the second save quietly erase the first.
Sessions That Don't Discard the Screen
A session timeout is designed to return the user to where they were after logging back in, instead of dumping them at the start of whatever they were doing.
Tested on the Browsers Your Users Actually Run
Layouts are checked against the real browsers and versions in use across your staff, dealers and customers, not only the newest one on a designer's own laptop.
Print Handled Deliberately
Anything a customer or dealer is likely to print or save as a PDF gets its own designed layout, rather than an accidental printout of the on-screen version.
What This Work Includes
The screens most often part of a web application design engagement.
- Customer and dealer portals used outside your own organisation
- Booking, scheduling and appointment flows
- Self-service request and approval screens
- Multi-user, collaborative screens where more than one person may touch the same record
- The browser-specific behaviours around each screen: navigation, refresh, sessions and multiple tabs
What Shapes a Web Application Design Project
The scope depends on who's using the application and how, more than on how many features it has.
- How many distinct user types access the same application — your own staff, external partners, customers
- Whether more than one person can touch the same record at the same time
- How much of the flow needs to hold up for a partner on an older browser or a slow connection
- Whether shareable, bookmarkable URLs matter for support and internal collaboration
- Whether this is a subscription product sold to many customers, or custom software built for your own business
Part of the Same Design Practice
Web application design draws on the same journey, structure and prototyping work as every other product we design.
Frequently asked questions
How is this different from your SaaS product design service?
SaaS product design is specifically about a subscription product sold to many customers — signup, billing, plans and the account-management screens that come with that. Web application design covers browser-based software more broadly, including single-business tools and dealer or partner portals that are never sold as a subscription at all.
Do you design for older browsers still used in smaller partner offices?
We ask what your users actually run before assuming a modern browser. Where an older browser genuinely has to be supported, that's factored into the design and testing from the start rather than discovered as a defect after launch.
What happens to a user's work if their connection drops mid-entry?
That's designed for directly — autosave and a clear recovery path so a dropped connection or an accidental reload doesn't erase what was already entered. We treat this as a screen-design decision, not something left to whatever a developer happens to implement.
What drives the cost of a web application design project?
The number of distinct user types who access the application, whether concurrent editing has to be handled, and how many browser-specific behaviours — sessions, sharable links, offline recovery — are in scope alongside the screens themselves.
Can two people use the same account or record at the same time without conflict?
It depends on whether that's designed for, which is exactly the kind of decision this service covers. Where concurrent access is expected — a dealer's team and yours both touching the same order — we design how the conflict is shown and resolved, rather than leaving it to whichever save happens to land last.
Could this application become a native mobile app later?
It can, though the design work for that is different — see mobile application UI/UX for what changes when software moves from a browser to something installed from an app store, such as offline behaviour and native permissions.
What do you need from us to start a web application design project?
A list of who accesses the application — internal staff, partners, customers — and on what devices, a demo login or walkthrough of what exists today if this is a redesign, and clarity on whether concurrent access by more than one person is something we need to design around.
Tell us what you need.
Send a short brief and one of our engineers will come back to you — usually the same day.
- No obligation
- We reply the same working day
- Your details stay private