Findings & recommendations (Site building study #5)

These are the results of a user research study investigating mental models related to building and customising a website. Results are split across five posts:

Background | Segments: Bloggers · Small Businesses · Site Builders | Conclusions

Key findings

  1. Big changes in software present cognitive challenges, particularly to long-term users of a product.
  2. People don’t care about the process of building a site—they just want to build something that works as quickly as possible, so they can focus on their core interests.
  3. People struggle to build a site that looks and works the way they want. Themes are a source of friction because they don’t match the way people think about building a site.
  4. Many people who build sites don’t have a pre-defined vision in their head of what it should look like. They tend to play around until they find something they like.

Recurring themes

Personal circumstances

A website is an opportunity to pursue a passion. That passion often begins as a side project, but the hope is that it will expand further. People often don’t have huge lofty goals for their sites or their businesses: they just want to pay the bills.

I’d like to be working for myself, but I’m not super good at hustle.

Sometimes a traumatic life event (accident, medical, personal) triggers a change in circumstances and brings people to a more entrepreneurial place, at which point a website becomes an essential tool.

WordPress allowed me to overcome difficulties in my life I couldn’t overcome without it.

Site building

A website is a tool for achieving a goal, not an end in and of itself. Building a site is often a necessary distraction from that goal. People aren’t really interested in the process of building a site, they just want to get a site out there.

WordPress uses too much jargon.

I wish there was a site builder that was for [non-technical] people like me.

Extensibility is the #1 thing people like about WordPress.

People have defined structures for how they build WordPress sites—they learn one approach, and then they repeat that for other sites. Often this means investing in learning one complex “do everything” theme and using that across all their sites.

Now I know these settings like the back of my hand because I’ve been using them for 10 years.

Generally speaking, people prefer when there’s a direct connection between element controls and the element itself. This aligns with Gutenberg’s approach, even though many people we talked to either didn’t like or hadn’t tried Gutenberg yet.

It’s so much easier and visual to float the blocks around.

Themes

People find making child themes to be an arduous process. They’ll often end up using a plugin to make the child theme, or editing the theme’s CSS directly via Appearance > Editor.

The term “theme” doesn’t really mean anything to people. A lot of people use the term “template” when they mean “theme.”

A lot of people spend a great deal of time choosing a theme, and they’re often unhappy with what they land on. often unhappy with what they land on.

A lot of times I will be unhappy with the layout. Often, everything else about the website is good, but the homepage isn’t right. I want the interior pages to look different than the home page – often not just look, but structure and mechanics.

Learning & delegating

Casual bloggers and people who may not consider themselves technical experts search Google to find answers to their questions. They assume documentation will solve their issues and are willing to learn more so they can make their website better. 

People will delegate as much work as they can afford to, so they can focus on the core of their work. Often a website is one of the first things they’ll delegate.

Change

Technology moves too quickly for people to keep up with unless they’re directly involved in the tech industry.

If it wasn’t broke, why are we fixing it?

People need to be sold the value of learning something new, because they see it as an investment that needs to be worth their (often limited) time.

Referrals

People rely heavily on referrals and reviews for advice when choosing software to use, whether that’s in person or via Facebook groups.

Security

People are concerned about their personal online security. They are also concerned about their site getting hacked and about data loss.

Recommendations

  1. Consider splitting themes into “styles” (colour, typography, spacing, pattern, and visual styling) and “templates” (structure and placement). Users often struggled to find a theme they liked and to make their site match the representation promised by the theme.
  2. Consider providing different paths or options for power users and for beginners. More technical users have very entrenched ways of doing things and just want to get on with it, but beginners prefer more hand-holding.
  3. Be very intentional with how changes are rolled out. Learning something new presents a huge cognitive load and users are resistant to investing the time to learn a new approach. Provide more gradual transition paths, make it easier to roll back to prior versions or “undo” an upgrade, and only ask users to learn something new when it’s totally ready and finalised. Consider implementing the minimum viable product when introducing new patterns and then adding features and functionality incrementally, so that users don’t feel overwhelmed. (Slack’s “What’s new” could be a great model.)
  4. When introducing new concepts or patterns, it’s important to clearly communicate the value offered by the change. There were a number of occasions where someone who was resistent toward trying or learning Gutenberg would likely have benefitted from it, but they didn’t recognise the value of investing their time to learn the new model. 
  5. Make room for people to build by experimentation and play. The majority of people aren’t likely to have a defined idea of what they want until they see it. 
  6. Documentation and help should be baked into the product, especially when introducing changes. 
  7. Adopt a more data-informed approach to the introduction of new features. Always start by asking “what problem are we trying to solve?” Test new features with end users prior to development, especially when they’re critical to the user experience. Ensure testing is done with a wide range of users who represent the breadth of people who use WordPress. Consider the merits of opt-in data collection to improve the product experience and remove features that aren’t being used. 
  8. Avoid adding clutter to core if it isn’t integral to the core experience. One of WordPress’ key strengths and sources of appeal to users is its flexibility and the additional functionality offered by plugins, but the plugin marketplace can be difficult for users to parse. Consider providing plugin recommendations or bundled packages for different use cases, and only include in core those functionalities that are universally relevant.
  9. Clearly communicate project vision and roadmap in order to ensure that everyone is working from a shared understanding. Decisions and the arbiter of those decisions should be clearly communicated so that the process doesn’t seem opaque. Establish clear metrics for success and ways of measuring this success. hello