WP Engine
Atlas
Project Overview
Companies are moving to headless CMS systems for greater flexibility, allowing content to be delivered seamlessly across multiple platforms via APIs. While this benefits developers, publishers may lose some flexibility with themes, page layouts, and SEO tools. The Atlas platform addresses this by delighting both publishers and developers; it integrates multiple features on a WordPress hosting platform, allowing users to build modern web applications on top of WordPress.
My Role
Senior Designer
[Team of 2 UX Designers]
[Team of 4 UX Reseachers]
Services
[0-1-2]
[User Research]
[Headless Wordpress]
[B2B]
[Interaction Design]
Status
🚢 Shipped
Our Challenge
Most of WP Engine's users host using a classic monolithic CMS. Modular headless CMS solutions are becoming table stakes on the road to the digital future. 64% of enterprises currently use a Headless approach and 90% are looking to do it in the next 12 months. How can we help educate, train, and unify teams as they make the jump to headless Wordpress?
Opportunity
When I started on the project, we were given less than four weeks to deliver an MVP for the technical team to begin building. Our user base was divided into two distinct categories: those who understood headless technology and those who were completely new to the concept. By synthesizing existing user feedback, we identified three key problem areas to address for the initial release.
Development time can be a blocker for some teams.
How can we help users create a headless app in the same amount of time, or even less, than it takes to set up a classic WordPress site?
Developing a headless site is a massive hurdle for the majority of our user base.
How can we reduce the technical burden on our end to help users through the setup process and get them working with the platform quickly?
Upfront costs and perceived value can be a deterrent.
How can we get users onto the platform quickly so they can start achieving their goals?
User Research
Our initial discussions provided a starting point, but many unknowns still remained.
While the steps to set up a headless application were clear, understanding how to set our users up for success was critical. The business was also making assumptions about what experienced users needed. Our research goals focused on understanding the core tasks of creating and maintaining an app, the value of pre-built templates, and workflow differences between beginner and advanced users.
Key Findings
I'm technical, but still need to learn.
The needs of both advanced and non-technical users were more similar than we anticipated. The more users could dig into understanding what WP Engine handled, the more helpful it was.
Am I doing this right?
Users expect us to facilitate a successful workflow and required more feedback on whether they are setting things up using best practices.
I am not use to this naming at all.
Nomenclature was a larger hurdle than anticipated. With most users coming from classic WordPress, which has its own naming conventions, Atlas must work with and not against that mental model.
External resources dictate expectations.
Users often referenced learning resources outside our ecosystem, so recognizing familiar concepts will provide clarity and boost confidence.
Features need to feel natural to the Wordpress ecosystem.
WordPress has a specific way users have been working with it for years. Gaining support from WordPress advocates is critical to success.
Pat
"I remember being confused here last time, this is looking better. I think the experience definitely feels like it's improved, especially the step-by-step stuff. I also appreciate less clicking through pages."
Shel
Denny
"I played around with Faust.js set up and I got a proof of concept working with that. A bit of experience with there. I know how it's all put together and, and I've got it working, but from a team high-level decision, we still decided to stick with Gatsby."
Atlas v2
Research demystified assumptions, helped the business redefine our opportunities, and informed various workstreams.
After our initial release, we were able to synthesize all of our learnings and feedback. I worked closely with the team to create more use-case-driven content and build a headless app experience that better facilitated getting started.
Getting Started with a Blueprint
Blueprints are ready-to-use headless WordPress starter projects that users can clone to start their own projects in a matter of minutes. They demonstrate the power of headless WordPress in real-life scenarios, allowing users to explore and modify the app as needed. These are excellent for sandbox users who are new to headless or just want to quickly build a fully functioning site. Each Blueprint starts with the creation of a new WordPress environment, enabling experimentation in a safe, isolated setting.
Creating an Headless App
Users looking to start with a blueprint can quickly clone one to kickstart their headless WordPress project, benefiting from pre-configured setups that streamline initial development. Alternatively, pulling from a repository involves starting with an existing project, although more manual, which allows for greater customization and integration flexibility.
Managing Headless Apps
With most users coming from traditional WordPress, it is crucial that the experiences feels familiar to ensure a smooth transition. This familiarity helps reduce the learning curve, increase user comfort, and enhance overall satisfaction. By maintaining consistency with traditional WordPress interfaces and workflows, we aimed to make it easier for users to adapt to the new headless environment without feeling overwhelmed.
Additional Features
As headless app creation increased, we prioritized adding requested features like custom domains, environment variables, and webhooks. These additions give users more control and customization options, improving their experience and solidifying our platform as a top choice for headless WordPress development.
Key Results
We observed an increase in active headless apps. Users who have successfully created an app have been proven to lead to better customers to convert.
We prioritized and built a backlog of user-requested features, which resulted in a stronger roadmap and better alignment between all teams.
Reflection
What I learned
Building the perfect alpha does not exist
Creating the perfect alpha for testing is nearly impossible because user needs and behaviors can be unpredictable. Early in the process, even with careful planning, unexpected issues and feedback require constant adjustments and improvements. You have to roll with it.
Recruiting users for testing can be difficult
Recruiting users for testing was challenging due to our specific product's niche in WP Engine's market. We overcame this by extending timelines, using strategic initiatives, and working closely with internal SMEs.
Next Steps