Let’s admit it. Design of backend systems is neglected. The general view is that it’s functional and going to be used largely by internal teams. So why bother with the design? Let’s ensure all the functional pieces are there. Added to it was the fact that initial backend systems were desktop driven (read Oracle/PowerBuilder forms) and therefore the scope for innovative designs was limited by the form builder functionality.
Which meant designs where action buttons were crammed in every possible space so that the user can do everything from one place. Resulting in a design that looked like a complete mishmash.
The truth is that your internal users have also evolved a lot. With proliferation of social media, quick commerce apps, changes in retail banking and a whole lost of other applications not to mention AI prompting, your internal users demand the same features that they are exposed to faster search results, intuitive and auto completed forms, recommendation & analytics on the screen without having to generate a report, a web and mobile interface, are just some of the examples.
Not just that, even your DB forms are evolving. An Oracle or a PowerBuilder now supports Web UIs. So making it easier to look at powerful Web designs.
The challenges
Traditional design of sites has looked at simple, intuitive flows with rich/minimalistic designs or adapting to the current trends. Designing for backend systems, however, requires multiple considerations:
- The Design Framework: As explained earlier, it’s critical to understand the design framework. Is a form builder being used, or is it a web application? These determine the strategies
- The Data and API Framework: Retail/Consumer sites focus on speed and immediate availability of data, often caching in the front-end. However, when it comes to backend systems, you are looking at security considerations, server loads, internal bandwidth. Which means a pagination could be a server side call instead of a front-end call. And data might require an actual refresh instead of an auto-refresh. If Web sockets/Server side events are not used, then notifications or status updates may not be real-time, and require another button. All of which means that design has to adapt to some or more of these technological challenges
- The user permissions or RBAC: Role-based access control is quite common in almost all backend systems. Which means access to certain modules are often restricted. These lead to additional considerations around—what data can be shown to that particular user? Can a user search for data of another user? All of these play a role in creating an intuitive interface
- Workflow considerations: Many of the backend systems have complex workflows with approval matrix and defined limits. Any user interface being designed, has to keep in consideration, display of such workflows along with TATs, queries, and related actions
- The domain understanding: Critical to many backend systems is a strong understanding of the overall process. This will lead to reduced cycle times explaining complex processes
- The scale factor: When designing a backend platform, you are talking about hundreds or thousands of screens with multiple states. Traditional design systems were done at the end of the project, once the designs were completed, and more as a style guide reference. Here, the process has to be inverted Create a design system with a proper component library and tokenisation so that creating multiple versions becomes much faster
How to go about designing for backend systems
A typical consumer app design approach involves talking to users, creating the IA, wireframing and design. While these processes need to be followed, in addition, it is critical that the following aspects are identified at the start itself:
- The Component Library: Is there going to be a custom component build or will an open source library like Mantine or Shadcn be used
- AI-enablement: What are the principles of AI governance to be followed? Indicator of AI generation, Source citation, check the actual source, compare extracted values with source
- Tech capabilities: What are the specific tech considerations to keep in mind:
- Role-based access: how will the views differ based on customization
- Workflows: Will there be single level or multi-level workflows
- Polling/Web socket functionalities vs API calls (Critical if required to show real-time updates)
- Page load (for infinite scrolling vs pagination)
- Table features (especially when you horizontal scrolling and longer column widths)
- Where will backend validations happen vs front-end validations
- Server side rendering for tables or front-end rendering
This is not an exhaustive list, but once you understand these aspects, your design will be more in line with the tech capabilities, and the back and forth that you will encounter will drastically reduce.