WP Engine refers to their management admin screen as ‘the portal’. The portal is a collection of ‘installs’ on an account. An ‘install’ represents an individual WordPress website. Each installs has hosting features, which are configured for that specific install.
Below is an example of the WP Engine Portal as it exists today. All the installs on my account are listed on the left, with the current ‘mysite’ hosting feature navigation open:
I have been using WP Engine to host this portfolio site and with my freelance clients for nearly 2 years now. I’ve seen the platform grow, rebrand, and most recently greatly improve the user experience. WP Engine continues to add amazing features to it’s portal like Automated SSL certificates, Git SSH key management, and most recently the Migration Assistant. As WP Engine continues to add more features, and as I continue adding installs to my account, I’ve found navigation slowly breaks down and I’m left to navigate a sea of installs.
This got me thinking about how WP Engine’s install management could be improved for users with lots of installs on their accounts. Solving this problem is ideal both for power users, as well as WP Engine’s bottom line. The more installs a customer has on their account, the more money WP Engine can charge. This creates an incentive to make it easy for customers to easily add and manage more installs on their accounts.
WP Engine needs a way to scale navigation while also making it easy for customers to manage all of their installs. Currently to get to a specific page from one install while in another, customers have to:
- Find and click the Install they want (this may involve scrolling the page if you have more than ~15 installs)
- Wait for the page to reload on the overview page for that install
- Click the Install Feature they want
There are some great opportunities to improve functionality. Specifically pivoting between installs and providing quick navigation to frequently accessed installs.
Having now identified a design problem and understood the underlying pain points, I would usually take time at this point to dedicate to user research. While I obviously don’t have WP Engine’s customer list, if I did, I would reach out to customers who had large numbers of installs on their account, and recruit them for user research testing. My initial goal would be to find patterns and similarities in pain points for my targeted customer base. I would validate the pain points I’ve listed above, and observe how customers are currently overcoming any issues. In this case it may be a customer using the browsers ‘Search Text’ functionality to find an install, or bookmarking frequently accessed install overview pages. These observations would all help validate and scope out the point points for the existing portal design.
For the scope of this case study, I will use my own experience with the portal. Having been a long time customer of WP Engine I have noticed myself some of the pain points listed above.
Below is a final wireframe that was part of a quick sketching sessions where I quickly iterated through a few ideas at extremely low fidelity. This quick iterative process allowed me to quickly refine my initial ideas addressing the above pain points.