Application design is something I really enjoy. A website might help someone understand a business or make an enquiry. A business application has to support the work itself, often for people who will use it throughout the day. The arrangement of a page, the name of a button or the way a record is organised can make a repeated task straightforward or frustrating.
I’m particularly interested in web-based applications for larger businesses, where the information is moderately complex. There might be clients, projects, departments, tasks and documents, with different people responsible for each. Designing that well starts with understanding those relationships and the work they support. The screens come from that understanding.
Finding the actual problem
The first conversation usually comes with requests. Someone wants a dashboard, another person wants a report, and someone else needs a new field. I want to know what has led to those requests. Where does the current process slow down? What gets entered twice? Which decisions are difficult because the information is missing or hard to find?
Asking someone to walk through a recent piece of work is useful. It gives us a concrete process to discuss, including the spreadsheet, email or handwritten note that fills a gap in the existing system. Those workarounds can tell us more than a list of features.
I like using Post-it notes for this stage. A note can represent a task, a problem, a piece of information or a question we have not answered. Moving them around helps us spot repeated requests and separate the things needed for everyday work from ideas that might be useful later.
What people ask for and what they need to achieve are not always the same. A request for another dashboard might really be a need to identify projects waiting for approval. That could be addressed by a clear status and a useful filtered list. I would rather agree on that goal before spending time designing an elaborate overview.
I put the agreed requirements into a short brief, including what success should look like and the questions still open. It gives everyone something concrete to discuss and stops every new suggestion becoming an unquestioned addition to the first version.
Working out the information structure
Before drawing detailed screens, I map the main things the application needs to hold and how they relate. In a project management system, a client might have several projects. Each project might have tasks, documents and people assigned to it. A department could be responsible for work across several clients.
This is the beginning of the data architecture, but it does not need to be a technical exercise. Boxes, connecting lines and plain descriptions are enough to ask the important questions. Does a document belong to a client or to one project? Can a task have more than one person responsible for it? Does a completed project remain available for reporting?
Those decisions affect where items should exist in the interface. A project document should be easy to find from its project. Someone may also need a wider document search, but it should lead to the same item with its context intact. Giving the same information several unrelated homes makes it difficult to know which version is correct.
I also think about the life of each item. A project can be a draft, active, awaiting approval or complete. We need to know what those states mean, who can change them and what information is required at each point. Otherwise a simple-looking screen can hide a process nobody has properly agreed on.
Keeping the audience close to the decisions
A manager reviewing a department and an employee updating today’s work may use the same application for very different reasons. I want a clear understanding of their responsibilities, how often they use the system and what they need to get done. Talking to people doing those jobs matters more than inventing detailed profiles for them.
A short user story can help keep a requirement grounded: as a project manager, I need to see which tasks are waiting for approval so I can deal with them before they delay the project. It identifies a person, an action and a reason. We can then ask whether the design actually supports that outcome.
I don’t want the audience work to become a project of its own. A few relevant roles and clear stories are enough to guide the next decisions. I return to them when choosing what goes on a screen, what needs priority and who should take part in testing.
Wireframing and trying different arrangements
Once the basic structure makes sense, I sketch the main screens and the routes between them. At this stage I keep the drawings rough. I want to compare arrangements without getting attached to a particular colour, typeface or polished layout.
For a project view, I might try a summary above a task list, then an alternative with the summary alongside it. I would look at which arrangement helps the intended user answer the most important question. Can they see what needs attention? Can they find the project details without leaving the work they are doing?
I use realistic sample information, including longer names and less tidy cases. A wireframe with three short project names does not tell us much about a screen holding dozens of similar projects. We need to consider filtering, sorting and how someone returns to the place they were before opening a record.
This is also a good time to remove things. Every extra panel or action competes with the task in front of the user. If something belongs in a separate view, I would rather give it a clear home than squeeze it into the first screen because there happens to be space.
Using familiar patterns for everyday actions
Most business applications share a lot of ordinary behaviour. People find a record, open it, make a change and return to their work. A recognisable list, labelled search field and clear Save and Cancel actions can be more useful than a new interaction someone has to learn.
CRUD is a useful way to check the coverage: create, read, update and delete. For each type of item, I work through how someone adds it, finds and views it, changes it and removes it. The interface can use normal language such as Add project, Edit details and Archive. There is no reason to make people learn the terminology behind the design.
Removing an item needs particular thought. Deleting a project might affect its documents, tasks or historical reports. Archiving could be more appropriate. The design needs to explain what will happen and offer a way out before someone commits to a change they did not intend.
Consistency helps these patterns become familiar within the application too. The same action should use the same label and appear in a predictable place. I want people to spend their attention on the work, with fewer small decisions about how the interface behaves.
Designing permissions alongside the screens
Permissions are part of the design from the beginning. For each role, I make a simple grid showing which records someone can view, create, edit or remove. There may also be separate actions, such as approving a request or assigning work to another person.
Access is often about scope as well as actions. An employee might edit their own tasks, a department manager might review their team’s work, and a senior manager might see a wider summary. Those differences change what belongs in the navigation and which information should be visible on each screen.
I want to distinguish an action someone cannot perform from one that is temporarily unavailable. An approval button might be disabled because required information is missing, in which case the reason should be clear. A person who has no approval responsibility may not need that control at all. These choices need to be agreed with the people responsible for the process, and matched by the system’s access rules.
Building the visual design
The visual design gives the structure a consistent form. I establish a small set of choices for type, spacing, headings, forms, tables and buttons, then apply them across the screens. It is much easier to assess a design when every page follows the same basic rules.
Illustrator is useful for drawing and refining visual elements. Sketch is another useful tool for laying out screens, with reusable symbols and shared styles helping repeated elements stay consistent. The tool should make revisions easier; it cannot make the decisions about what a user needs.
My preference is for a restrained interface. In a business application, that still needs to leave room for useful information. A table can be the right choice when someone needs to compare records. Clear alignment, sensible columns and readable labels can make it easier to use without hiding the detail behind several extra clicks.
I design the less attractive states as well. What does an empty list say? What happens while something is loading? How do we show an error or confirm a successful change? The same care goes into field labels, contrast, keyboard focus and messages that make sense without relying on colour alone.
Prototyping a complete task
A wireframe shows an arrangement. A prototype lets us walk through what happens. It can be as simple as paper screens that we swap as someone makes a choice. The point is to test a sequence, including the moments between the screens.
I would take a task such as creating a project, assigning a person and submitting it for approval. We can follow it from the starting list through the form and back to the updated record. Does the person know what has been saved? Is the next step obvious? Can they return to the list without losing the filter they were using?
I keep the prototype limited to the questions we need to answer. Some parts can be detailed while others remain rough. There is little value in making every screen convincing if the uncertainty is whether the approval process makes sense.
Testing and making changes
I ask people from the intended audience to try realistic tasks and explain what they are thinking. I try not to tell them which control to use. If I have to explain the route before they can begin, I have missed the chance to see how well the design communicates it.
I pay attention to hesitation, unexpected choices and the words people use. Someone repeatedly looking under Clients for a document we placed under Reports tells us something about the structure. A label that everyone interprets differently needs another look, even if it sounds perfectly clear in a design meeting.
The notes from testing need to lead to decisions. I separate problems that block a task from smaller irritations and preferences, make changes and try the affected journey again. Sometimes the right fix is a better label. Sometimes it means going back to the information structure or questioning the original requirement.
Presenting the design and explaining the decisions
When presenting the work, I prefer to walk through a task rather than show a collection of disconnected screens. I start with the person using it and the goal we agreed on, then show how the design helps them reach it. That gives the discussion a useful frame.
I explain the choices that need agreement: why an item belongs in one section, what a particular role can do, how a status changes and what happens when information is missing. I also make clear which parts are proposals and which questions still need an answer.
A polished screen can make a design look settled before it is. Showing a rough alternative alongside it can help people discuss the arrangement without getting distracted by the finish. I want feedback about whether the process works for the audience, as well as how the interface looks.
For a larger business, the people approving the design may not be the people using it every day. Both perspectives matter. The presentation needs to connect the business goals to the actual tasks, and the people doing those tasks need an opportunity to challenge our assumptions.
The part I enjoy most is seeing those decisions come together. The information has a sensible home, the actions feel familiar and someone can complete their work without needing the designer beside them. It takes research, rough experiments and plenty of revision to get there. That is what makes application design interesting to me.