The Importance of a Support User Interface | Support Driven Development
Discover the essentials of crafting a superior support UI to empower your team, enhance customer service, and streamline operations for software products.
Any company that sells a software product with direct end users and wishes to scale to any significant size will eventually need a dedicated support team. If this support team is going to successfully support the people using the software, they’ll need some form of a support user interface (UI).
Their ability to support the software efficiently to a high standard will often depend on the quality of the support UI that is provided to them. In this post I’ll be giving a guide as to how these interfaces should work, the functionality that should be included as well as the improvements that can be made as the product and user base grows.
“56% of people around the world have stopped doing business with a company because of a poor customer service experience.”
What should be in my Support UI?
“We just hit our 100th user and our developers are getting tired of running scripts to unlock user accounts. We’re going to stop feature development for a week and build some sort of a support UI to help us support the platform. Where do we start?”
You won’t immediately know what common problems your customers are going to have or the actions your support team has to do, but having some sort of customer/user list with actions and logs related to those users is a good start. In my opinion, any action that a user can do in the administration of their account should be actionable by the support team as well.
The following is a list of all of the main functionality you should consider building. Even if you don’t build it immediately, you should plan the development of your product so that it can be added to the UI at a later date when your team grows and you get more capacity/funding:
Administration actions — Give your support team an action for everything that a customer can change on their account settings. Password resets, privacy settings, notification settings, changing contact and payment info would be some of the key examples.
Role/Action Restrictions — Build restrictions or security around each of these support actions. Building the ability to tie actions to different support user roles/levels will save a lot of pain down the line when the support team grows. Having the ability to spin up new support users with various permissions will reduce the chance someone without knowledge will change something they are not supposed to.
Admin and Read Only Access — This should be done from the beginning. Even if you want all of your support to have all of the access at the beginning, you should also be able to give some access to the developers if they ever want to log in and help debug some customer issues. You will also want to be able to tie functionality or the actions mentioned above to some user levels at the start.
Support User Management — This is purely to manage the users who have access to this support UI. Typically admins should be the only one who can create support users. This is where the user restrictions can be applied as well.
Customer Audit Logging — I’ll talk about this properly in a future blog post, but this is a place you can log all of the relevant customer logs and make it easily accessible to the support team. This should have simple to read logs around the specific customer or user in question. This can reduce the need for the support team to connect to log servers or query the DB. This removes the barrier to employing support staff who don’t know SQL or how to read complicated log lines on a server.
Reporting — At some stage, someone will have to report to somebody with the platform’s usage figures and customer base. Building some reporting functionality that tells you information about your product’s users will free up a lot of your developer’s time that they would spend re-running the same database extracts over and over. If possible, these reports should be built initially on some sort of a cron job (schedule) in the background so that it doesn’t tax your systems if your reports start getting large or you get more users requesting reports.
Well what should it look like?
Here is a website that one of my coworkers recently sent to me and it gives good inspiration to what kind of screen you might build. This is a very useful site for helping to visualize what you are looking for while also giving your front end developers something to use as a base design. I’ve used this a few times now for some ideas around features I’ve been helping to design and to get an idea of what I want in my head.
What may just end up happening is that the design of your support UI is copied from whatever UI your customers use. This is also perfectly acceptable and can be the most frictionless option. Re-using some of the same pages (login screen, list views, dashboards etc.) can save your development team time and reduce the cost for changes down the line.
Continuous UI Improvements
OK, that’s built. I can forget about it now, right?
In an ideal world, no. Saying that, If you are reading this and have ever worked on any support team with some sort of a custom UI, it is highly likely that many changes that have been suggested from you or your team have never been implemented for one reason or another.
Many companies will create a basic support UI when the product scales enough to need one. They might have a “one and done” ideology around support UIs and any further improvements are consistently deprioritised against feature development or customer enhancements.
Depending on the way you prioritise, plan and execute work on your team (Agile, Kanban etc.), you should easily be able to set aside a certain amount of feature dev per quarter/sprint/PI and attempt to spend that capacity on features requested by the support team.
The trick is to set aside the capacity before planning anything else, so if it is not used then nobody misses it. You won’t have changes for the support team all the time, so often this capacity will fall back to regular feature development.
Changes to the support UI coming from feature developments — something found through an impact analysis for example (https://youngleaders.tech/impact-analysis/) — shouldn’t be taken from this capacity for the support team. This should be reserved for the support team themselves.
If you have tickets being raised to development from the support team, a simple question at the end of the ticket that would fuel the capacity could be something like the following
“Can something be added/changed in the support UI to support this issue in the future?”
The answers to this question can then be added to the backlog of work for the support UI to be picked up with the capacity set aside.
Doing all of this will allow a number of improvements in the support process. It will improve the level of support being provided to the customer and it will also reduce time spent by anyone other than support on a customer ticket. Finally and perhaps most importantly, it will also help the support team feel included in the whole team as their voice is being heard for improvements on the platform. This should help to retain staff and keep the entire team happy.
Join the page
I’d love you to be a part of a community of people who share the interests of the page. Participate in the comments of the posts, the chat section, or support this work by subscribing!
Share it with a friend!
If you think anyone you know might like this content, please feel free to also share the page
Continue the conversation elsewhere
You may also reach out directly on any of the below if you would like to get in touch.
My own Linkedin | Linkedin for the page | Twitter/X.com | Instagram