Engineering
Designing agency software for the counter and the phone at the same time
Staff at a counter and residents on a phone need different things from the same system. Both can be served well.
A permit system has two very different users: a clerk processing forty applications a day at a counter and a homeowner applying once, on a phone, at night. Software built for one usually fails the other. Here is how we design for both.
The clerk's needs
Density and speed. Keyboard navigation. Multiple records visible at once. Shortcuts for the common cases. Tolerance for incomplete information that will be fixed later. Powerful search.
The resident's needs
One task at a time. Plain language. Large touch targets. Progress saving, because they will be interrupted. Clear status and what happens next. Accessibility with a screen reader or magnification. Working on a slow connection.
The design approach
Separate the interfaces, share the system. The staff interface and the public interface are different applications on the same data and the same rules. Attempts to make one interface do both usually produce something cramped for residents and slow for staff.
Define the business rules once, in the service layer, so that a fee is calculated identically whether it was entered by a clerk or a resident.
Test with real users of each kind. Watch a clerk work for an hour. Ask a neighbor to apply for a permit on their phone while you watch. Both sessions will change the design.
Accessibility applies to both
Staff with disabilities use the counter system too. Both interfaces are held to WCAG 2.1 AA, and the staff interface must be fully keyboard-operable for everyone's sake.
What this costs
Two interfaces cost more than one to build, but less than one interface that both groups work around. The savings show up in staff time and in residents who finish the task instead of calling.