Account Management Revamp
management UX design html SASS/SCSS Vanilla JS Single-Page Application perl mysql
Problem
The account management section of DreamHost's control panel application had become one of those places that managed to amass piles and piles of spaghetti code for over two decades. This was especially problematic since it was one of the most high-traffic sections and contained a number of essential product and account management functions, many of which flat out didn't work, thus creating a mountain of support issues and making future enhancements to product management difficult.
Project Goals
- Rebuild outdated interface for managing a user account by bringing it in line with standards for modern account management UI, thereby improving user experience and reducing support
- Completely refactor over twenty years worth of legacy code to make an application that is both scalable and easy-to-use for future development
Key Highlights
Before
After
I. Complete UI Overhaul
Teamed with one other designer, she was tasked with handling the interface redesign while I offered consult on UX decisions and would later be the lead developer. The design process was fairly simple and straightforward seeing as how pretty much every single application requiring account creation could be used as reference or source of inspiration.
II. Perl-Clutching
Simply put, the existing code was twenty years worth of outdated packages, tacked-on spaghetti, database architecture based around products that no longer even existed, and liberal use of jQuery 1.x and deprecated libraries to patch things up on the front-end.
Honestly, this had "ground-up rewrite" written all over it, but due to resource and ecosystem limitations, not only was I asked to build the UI in Vanilla JS without a modern framework or build system, but the back-end would have to remain in Perl. I had previously learned Perl explicitly to do my job better for DreamHost and had pushed some smaller-scope changes in the past, but this was a project of a larger scale, and re-architecting it not just to build out the back-end, but make it user-friendly for seasons Perl devs was obviously a massive challenge and effort.
III. Scope?
I'll be honest here. I'm sure in tech dreamland many companies have an abundance of resources and talented people who work on tightly defined and scoped problems in immaculately crisp and punctual sprints.
Well, mine is not one of those companies, unfortunately, and with no playbook for how a company with limited resources should operate when things need doing, then scope suddenly becomes a very blurry concept.
That said, the following video provides a short demo of the end result, or else below is a lengthier and more detailed list of some of the issues encountered and fixed during development:
Issue
Fix
Dependency on jQuery 1.7, which was deprecated and a security risk due to XSS vulnerability
Replaced with fully Vanilla JS front-end, structured to accommodate modern JS framework in a future update
Account rename functionality poor user experience using outdated jQuery plugin
Converted to simpler UX so user stays on the page, full Vanilla JS with an ajax call
Too many links in the navigation menu under the 'Billing and Account' section. Creating cognitive overload, and most links receive little to no visitors.
Number of links in main navigation reduced from nine to five, and excess links given more subtle placements on the main 'Manage Account' page.
Overall design aesthetic was outdated, unsightly, and lacking in consistency with more modern interfaces throughout the control panel application
Design updated based on the latest design and branding guidelines
Poor mobile user experience, with most functionality merely hidden or disallowed on mobile devices
Fully reworked UI to be mobile responsive and to retain all functionality
Service plans section confusingly and suboptimally built using a combination of a server-side templating via a custom Perl engine, and ajax-calls to patch up one-off data changes
Service plans section data converted entirely to a single ajax call, with template-based rendering removed, thereby allowing for simpler code and also better scalability for adding new plan types
Lack of clear and simple options for changing and/or canceling paid subscriptions due to outdated billing practices
Billing practices updated to more closely follow the modern subscription service model, and all products given clear and consistent flows for changing and/or canceling their subscriptions easily
Lack of simple and obvious method for changing, canceling, or otherwise managing custom options for service plans. Management options built using outdated jQuery plugin.
Dedicated plan management section created, allowing for future developers to provide change/cancel options for each service plan, as well as any other customization options needed for a particular plan
Users allowed to change the names of their service plans, which created support due to customers renaming a plan then later forgetting what it is
Ability to rename service plans removed outright, as it was a feature that only created support while providing minimal benefit to users
Service plan name change functions were adding leading and trailing whitespace, resulting in lengthy and confusing database values
Ability to rename service plans removed outright, as it was a feature that only created support while providing minimal benefit to users
Service plan names lacked naming conventions that clearly stated the product and its features in a consistent manner for every product.
Naming convention created for every single product in the lineup and implemented.
Service plan names stored across three different database values, each one an attempt by different developers to create their own convention on how each service plan name should be displayed
Naming convention created and an explicit value strictly for the plan name added to initial service plan API call, providing a dedicated value explicitly for display on the front-end and avoiding having to tamper with the database
Service plan types lacking clear visual indicators to specify each product and apply branding
Custom icons created and added to each service plan based on type, with a default in the event that the service plan is newly added or a legacy product
Too many tables showing configurations settings and options for all products currently in-use
Tables not frequently used hidden behind toggle-able UI selections
Some lists of products, such as domains or email addresses, causing excessive load times due to thousands of entries existing
List cap set when rendering from the back-end, with an option provided to view full list
Project Summary
Project was completed and launched within a three month development window, which I consider to be one of my proudest accomplishments. Account management-related support tickets also seemed to vanish overnight, and to this day developers are able to freely and easily iterate on top of the architecture with new products.
As the lead developer, I also demoed the new application for the entire company and provided extensive documentation and training to our support teams. (I have a full video of that demo, but it's like an hour long and I'm not a huge fan of putting myself on the Internet, so here's a screenshot instead.)
