fidzu : WordPress

[00:00:00] Nathan Wrigley: Welcome to the Jukebox Podcast from WP Tavern. My name is Nathan Wrigley.

Jukebox is a podcast which is dedicated to all things WordPress. The people, the events, the plugins, the blocks, the themes, and in this case what the WordPress Playground is, and how it's transforming the scope of WordPress.

If you'd like to subscribe to the podcast, you can do that by searching for WP Tavern in your podcast player of choice, or by going to wptavern.com/feed/podcast, and you can copy that URL into most podcast players.

If you have a topic that you'd like us to feature on the podcast, I'm keen to hear from you and hopefully get you or your idea featured on the show. Head to wptavern.com/contact/jukebox, and use the form there.

So on the podcast today, we have Birgit Pauli-Haack. Birgit is a longtime WordPress user, an influential voice in the WordPress community. She's known for her role as the curator at the Gutenberg Times, and host of the Gutenberg Changelog podcast, and she brings her wealth of experience as a Core contributor to WordPress as well.

She joins me today for an in-person conversation recorded at WordCamp Asia in the Philippines, and we are discussing Playground, a remarkable development that's set to redefine the WordPress development landscape.

Playground allows users to launch a fully functional WordPress instance directly in their browser, without the necessity of a server, database, or PHP, playground breaks down barriers, offering developers, product owners, educators, and everyone in between a new way to interact with WordPress.

We explore how this technology not only simplifies the testing and development process, but also sets the stage for more interactive and immediate web experiences.

We explore the concept of Blueprints within Playground, tailored configurations that enables a bespoke user experience by preloading plugins, themes, and content. This feature helps developers to present their work in a controlled environment, offering users an insightful hands-on approach that can significantly enhance understanding and engagement, and it's all available with just one click. It really does eliminate the traditional hurdles associated with installing WordPress.

If you're curious about how the WordPress Playground is set to usher in a new era of friction free web development, this episode is for you.

If you're interested in finding out more, you can find all of the links in the show notes by heading to wptavern.com/podcast, where you'll find all the other episodes as well.

And so without further delay, I bring you Birgit Pauli-Haack.

I am joined on the podcast by Birgit Pauli-Haack. Hello Birgit.

[00:03:28] Birgit Pauli-Haack: Oh, hey Nathan.

[00:03:29] Nathan Wrigley: We're actually looking at each other, not through a screen.

[00:03:32] Birgit Pauli-Haack: Yes. It's a total different feeling.

[00:03:34] Nathan Wrigley: Yeah. Birgit And I chat a lot on various other channels, and it's a pleasure having you right in front of me. That's lovely.

[00:03:39] Birgit Pauli-Haack: Yeah, same here. I'm always glad we meet at a WordCamp.

[00:03:42] Nathan Wrigley: Yeah, thank you. So that's the introduction then because here we are, we're at WordCamp Asia, in the Philippines. It's the first day of the conference in general. We had the Contributor Day yesterday, and we've got another day tomorrow.

And we're going to have a chat with Birgit who is going to be talking to us today about Playground, because you've got a slot at the event all about creating a demo in Playground. And we'll get onto that in a minute. But first of all, for those people who don't know who you are, just a few moments for your potted bio. Tell us about yourself.

[00:04:09] Birgit Pauli-Haack: So I'm the curator at the Gutenberg Times and I'm the host on the Gutenberg Changelog podcast. And I also am a Core contributor to WordPress, and I work for Automattic. I live in Munich and I'm married, 37 years.

[00:04:22] Nathan Wrigley: There we go. That is a very potted bio. Thank you, I appreciate that.

So here we are, we're going to talk about Playground. And I figured the best place to start is answering the question, what is Playground? And just before we hit record, it was pretty obvious that both you and I are very excited about this. And so I want to encourage people to really pay attention because this genuinely, for me is one of the most exciting developments, not just now, but ever, in WordPress. It truly is a transformational technology. But for those who don't know what it is, just tell us what Playground is.

[00:04:54] Birgit Pauli-Haack: I'm totally with you there on the magic, yeah. And it's not just for WordPress, it's for web development. So WordPress Playground is a WordPress instance in your browser. Yeah, you go there, put in playground.wordpress.net. You get a full WordPress instance in your browser, and you can add plugins, you can themes, you can content. Test it out. Whatever you do with that and want to learn with Playgrounds, you don't need a server, you don't need a database, you don't need PHP installed or something like that. So it's just there.

And for someone who has been in the web development for many, many years, it's like magic. Because before you're always kind of, oh, where do I host things? What's with the database? What's with the server? And it's all gone. Yeah, so it's really cool.

[00:05:43] Nathan Wrigley: I think probably it's best on this particular podcast to avoid the technicalities, but I would point the listener to a podcast that I did on the WP Tavern with Adam Zielinski several months ago now, where Adam came on and tried, in an audio form, it's very hard to do, but explained in an audio form exactly what the underpinnings are.

And the only words I can use to describe it are, it's voodoo. It is literal magic. Just two or three years ago, if you'd have said that Playground was possible, I honestly would've thought that you were talking nonsense. It could not happen. That will never happen.

[00:06:18] Birgit Pauli-Haack: Snake oil.

[00:06:18] Nathan Wrigley: Yeah, exactly. And yet Adam managed to pull it off. And so just to re-explain what Birgit just said, it's all in the browser. When you go to playground.wordpress.net, there is no server. Just say it again, there's no server. There's no PHP that you need to install on your local machine. It all happens inside the browser. Close the browser down, it goes away. We'll come to that. Maybe that's changed.

But the idea is it's happening in the browser, and so you can have any combination of website that you like immediately inside of Playground, and it really is remarkable.

I liken to the moment that the iPhone got the App Store. The iPhone was a very useful thing to have. You know, it did phone calls and it looked beautiful, and you could upload music to the phone with a cable. And then along came the App Store, and suddenly a thousand, a million, different developers could get their hands on it and tell you, here's a different way you can use the iPhone. And here's another way, and here's another thing that you can do. And it feels a bit like Playground is WordPress' moment like that. You know, it just suddenly prizes the lid open, and makes developers able to show you what they've got in a heartbeat.

[00:07:25] Birgit Pauli-Haack: Yeah. And that's pretty much, that's a very good analogy because we also have a Blueprints gallery that could be something like an app store where you can learn how you can assemble it. So the core technologies is not not, I don't know any of the technology that's underlying. It's based on Web Assembly. And that has been around for about 10 years, trying to get a lot of different programming languages talk to each other in the browser.

And then it's based, not on MySQL, but on SQLite database. And then Service Workers and worker Threads API, that are browser APIs. For storage, for instance, yeah, or for sending commands to other different applications. But that's all I know, yeah. I have never worked with Web Assembly, yeah. And MySQL, I know that, just really amazing.

So you can use that. Many people use it to spin up a fully functional WordPress and demo that. So you can use it in educational settings. You don't have to download a whole lot of stuff. You don't have to, as a teacher, you don't have to set up, talk to your IT department to set up a server for all the students. You can just point them to the Playground and then give them instructions on how to work with that.

It's a sandbox environment. It could be, yeah, if you want to. You can upload your content and then see what else can you change with it without messing with your live site. You can integrate it with your development. There is a WP now, VS Code extension where you can, so when you're working on your plugin and you click on the button, it loads up a local Playground for you with the plugin that you're working on already installed, and that's really cool.

Same with the theme. The training team has been working on interactive demos in terms of having code examples on one side, and then you make changes to the code and you see it in the right hand side. How it changes the website. So that's really cool.

[00:09:20] Nathan Wrigley: I think one of the things that you said there, you've got an understanding of some of the underlying technologies, but you were stressing that, basically you don't need to understand them. Having a knowledge of them is fun, you know, it's interesting. But a bit like I don't have the faintest idea how to build an iPhone app, but I can still use an iPhone. And I can still benefit from this application, the maps, navigation app. I don't need to understand how that's built, but I can use it, it works.

And really that's, I think the purpose. The developers over there, thank you so much, but most people are never probably going to want to get into the weeds of that. They just want to click the button and see what happens.

And just to be clear on this, if you've never done that, I, at my home, have a fairly good internet connection, so I don't know if I'm in a sort of slightly privileged position, but when I click the button at playground.wordpress.net, I'm imagining it's somewhere in the order of three to four seconds before that website is ready to go. Basically it's the length of time it takes me to blink and grab the mouse again. It's in a heartbeat. So there's literally no friction.

But if you go to playground.wordpress.net and click the button, what you're going to get there is a vanilla version of WordPress, which is fine. Then you can do whatever you like with that, put plugins in, what have you. But wouldn't it be interesting, wouldn't it be great if somebody came up with, oh, I don't know, let's call them Blueprints or something like that, where you could pre-build something that then somebody else could use.

So this is the App Store, isn't it? You know, somebody's built the maps navigation app. Somebody's built the note taking app. Somebody's built the whatever. This feels like what the Blueprints are. But I want to make sure that you are describing it and not me because I am not sure that I've encapsulated it perfectly.

[00:11:00] Birgit Pauli-Haack: No, you did. But in opposite to the App Store, you actually can look at other people's Blueprints and steal them. Blueprints are written in JSON has nothing to do with Jason. It's JSON. It's a data format for JavaScript. And there is a schema for it, so when you put it into your code editor, it gives you signals, yeah, that you formatted right.

And then you have two different ways of configuring your Playground instance. One is to do settings. So you could do which PHP you want to use? Which WordPress version do you want to use? Also, do you want to have network enabled? And most of the time you want it enabled because you want to import and install themes or something like that. Those are the settings.

And then you have steps. And those steps are also just formulated in JSON format. For instance, you can log in. Automatically log in the person in the Playground. Or you can say, I have a landing page that should land, so when somebody uses that blueprint, when Playground is ready to completely load it, you should land in the block editor, for instance. And you should have that particular block plugin already active on that post, so you can really play with blocks. Nick Diego with his plugin Block Visibility has done a great way for a live preview of his block from the repository.

Another way is to, so install a plugin, add content to it. Use WP-CLI to instantly load up new versions, add new pictures, or use an export from another website, an XML file from another website and load it into the Playground instance.

But sometimes you have, you said you get the vanilla if you just do that, if you just do playground.wordpress.net, you get the vanilla WordPress. But it's one post, Hello World, and it's one sample page. But you don't see how content kind of interacts with whatever feature you want to demo. So you need some content there, yeah. And the Blueprints Gallery has actually some nice examples on how to configure that.

[00:13:08] Nathan Wrigley: Let's come back to the gallery in a minute. Just to recap what you just said. So there's a bunch of settings, probably more for developers. You know, you might want to test something in a particular PHP environment or what have you, so you can select those. And then you can do these steps where you can essentially design, if somebody was to use that Playground and somebody was to click on your link, they would wait the 2, 3, 4 seconds, whatever, and then, depending on the steps that you'd set up, they would arrive where you chose them to be.

So for example, you might pre-install the latest, greatest plugin that you want to share with the world. And you want people in a post for that. And you want them inside the block editor. And you can make it so that upon clicking the button, the first thing they get is, we're inside your plugin, we're about to use it. So the profundity of that is pretty amazing. You can really tailor the experience.

So rather than going from being like Playground, which sounds like children, you're messing about, larking about a little bit. It also becomes like serious ground a little bit, you know? Serious developers can use this to circumvent, I don't know, support tickets, the capacity to demonstrate to users who've never seen your product before, your plugin, your theme, or whatever it may be.

You can point them to a link. They can click the link. You as the developer configure everything within an inch of its life, so they get exactly where you want them to be. And in that way you can use it as a sales mechanism, as a support mechanism.

[00:14:29] Birgit Pauli-Haack: And sometimes it's really hard to tell people what your plugin does unless you show it them in the video. But then they still don't get their hands on it. And with that feature, with the Playground combined with the Blueprints, you can actually make them feel the thing. How it works with them, and what ideas they get when they play around with it, and have better questions, educated questions for you, for the product, yeah.

[00:14:51] Nathan Wrigley: So a Blueprint then is a version of Playground in which somebody has pre-configured things. Is that basically what it is? You know, let's say that I have got this fabulous new plugin and I want you to experience it. I don't necessarily want you to land on a particular page, but I just want the plugin to be available to you and you can do things.

If I install my plugin, use Playground to do that, I can then share a link. And because I've tinkered with it, it becomes a Blueprint because it's not the playground.wordpress.net version, it's my doctored version, adapted version.

[00:15:26] Birgit Pauli-Haack: Well, it also goes to playground.wordpress.net, but it has a query parameter, to be a little technical term, that says, use the blueprint at this URL. So a plugin developer for the repository, at the repository there are live preview buttons now. And the plugin developer can put in a separate directory Blueprints on the WordPress site, put all the assets, all the image that they want to load, and the configuration file, which is written in this JSON file, and put it there, and then make that live. And every time someone clicks on the preview button, they go to playground.wordpress.net with the Blueprint kind of loaded, the configuration files.

[00:16:09] Nathan Wrigley: So it's all happening through playground.wordpress.net. But then there's JSON configuration file, which gets sort of sideloaded, if you like, through the URL. That tells it, okay, add this and then end up here and what have you. The important part is that JSON, that's what makes it the Blueprint. It's going to playground.wordpress.net, but the JSON file means that it does something else.

And you said the word gallery, which tells me that there's a whole host of these things. Pre-configured, pre-built, put into a box if you like. And we can go to that gallery and explore. What kind of stuff is in there?

[00:16:38] Birgit Pauli-Haack: So, what kind of stuff is there? So there's one, how do I put an admin notice on top of the dashboard? How do I add a dashboard widget and load it up with my Playground? So most of the time, when you want to log into a WordPress site, you get the dashboard. And if there's a widget, you can actually guide people to go some other places. You can say, okay, I have a plugin that needs 50 posts, for whatever reason. So there is a Blueprint there and how to use WP-CLI to create 12 or 50 posts automatically, that are then loaded into the post content.

So there's also a Blueprint for a specific WooCommerce extension. So it loads WooCommerce, it loads the extension, it loads some products, and then you land for a shipping page where you can say, okay, this shipping plugin, what does it do for me? And you see it working with products on a Playground site. So that is really remarkable. It takes a little longer when you have content to load.

[00:17:38] Nathan Wrigley: Goes up to like 10 seconds.

[00:17:40] Birgit Pauli-Haack: So you go and get your coffee and come back.

[00:17:42] Nathan Wrigley: But it's still profound.

[00:17:43] Birgit Pauli-Haack: Yeah, remarkable. Yeah, you don't have to do anything, kind of just wait a bit.

What else is in there? Oh, there is a demo of 2025. So when you load 2025 theme automatically and go to your website and see it, you get the post, the blog site, where all the posts are in one one big site with the full content. And not a whole lot of people have that kind of blog. And in the demo, you actually go to the magazine front page, and then see all the patterns that are in there. You can see all the templates in that Playground demo.

That's interesting for plugin developers that have experimental themes or experimental settings on the settings page that you can actually preload them as well. There's an example in there for the Gutenberg experiments. They're on the check marks on a setting site. And you can take that and replicate that for your own plugins site, how to do that, with the areas.

Because you can do site options. So the site options is not only site title and tag descriptions, also, oh, make my block editor have the top toolbar instead of all the other things or the distraction free model, yeah. So these kind of features, you can also preload there and have examples from the Blueprints Gallery.

[00:18:57] Nathan Wrigley: I think we're just at the beginning really, aren't we? Of of this journey. And basically, the underlying technology is now provisioned. It's there. And we're at point where, okay, people, developers, explore. And we're really just at the beginning of that. And the gallery is probably a good place to go.

But if you wanted to put one of these JSON files together, do you know, is there some credible documentation out there that would help people to get started, learn the ropes?

[00:19:25] Birgit Pauli-Haack: Yeah, there's definitely, there's documentation of all the steps that are there, yeah, like how to run PHP, how to have additional PHP extensions installed and all that. So when you open the Playground, there are three, and you're not going to the full page, so you have three panes. On the left hand side you have some menus, and one of them is the documentation link. So that's good.

And another link is there, it's the Blueprint Gallery. So in the middle of the section of your Playground, you see all the list of all the gallery content. And then when you click on the preview or the view site, the Playground loads that for you, and then there's another menu item where is says, view Blueprint. And that gives you a Blueprint editor.

So you see the Blueprint loaded in, but then when you want to edit from the documentation, okay, what happens when I put that in? And you click the run button, and it reloads that Playground with your changes. So it's really, very hands on, and you still don't have to create a server or a local environment or something like that.

[00:20:31] Nathan Wrigley: Yeah, there's this really virtuous cycle of, okay, so you've used something from the gallery, but you're curious about how it works. Look, here's how it works. Here's the buttons to click to go and explore. Oh, and whilst you're at it, if you want to edit anything, here's the option to edit it. And when you click save, it'll restart that whole thing and you'll get the new version.

So all of the sort of helpful tooling is now built into it. Because when I talked to Adam, none of that existed. I mean, the version selection for PHP didn't exist. The ability to land people on particular destinations when they first load up the playground, none of that existed. It was literally the technology of getting it working.

So now built into it is this knowledge base, if you like. Not really a knowledge base, but more, you want to know how this one works? We'll show you. And it's that beautiful, well, the purpose of WordPress, democratising publishing. In this case, it's democratising the nuts and the bolts, and the bits and pieces of publishing.

Yeah, so that's really nice. And that's all built inside. So just follow the prompts in the UI, and you can adapt what you want, and what have you. But also there are some 101 articles out there, perhaps on Learn or something like that where can see in text format how do all.

[00:21:40] Birgit Pauli-Haack: Yeah, the developer blog has, on developer.wordpress.org/news has three articles about Playground. One is about the underlying technology from the Web Assembly people. That was really good for those who want to explore that even further.

And then there is one on what use cases you can do with a little bit of an example. And then also, so we are right now always talking about playground.wordpress.net. But you mentioned something that someone could put this on their website, and you can.

Playground can be self-hosted. It does not have to go through the wordpress.net site. But how to do this is in the documentation. It has a seperate section there. So if you say, okay, I don't have my plugin in the repo, but I want to use it through my own website, then you can actually put it there, and it'll have your own branding around it. So it's even get further than just the WordPress part.

[00:22:35] Nathan Wrigley: So that's a really important distinction to make. So in the cases that we've been talking about so far, if you want to go to playground.wordpress.net and you use your own JSON file, it will be able to suck in anything from the WordPress repo. And that's the sort of, the WordPress way, if you like. I'm doing air quotes.

[00:22:51] Birgit Pauli-Haack: Also from GitHub.

[00:22:52] Nathan Wrigley: Oh, thank you. Yeah, that's an important distinction. I'd forgotten that. Also from GitHub, but you know, it's everything that's open source out there, free to download already.

But a big part of the WordPress community, one of the things that makes it popular, is the ability to sell commercial plugins. And so that was another question that I had. Is possible to do it?

And so, yes, but you need to take the technology that builds WordPress at playground.wordpress.net, you put that onto your own server, and you can do whatever you like with that. So you can put your premium products in there on a, I don't know, two day free trial sort of basis, and show people how that all works.

So Playground suddenly becomes more interesting outside of the free to play area as well. And you can imagine that being a really, really useful tool. Because we've always been able to play fairly straightforwardly with free things on the repo, but suddenly the moment where you've got to pay $100 for a thing, the capacity to see that really is the bit which opens the wallet.

Okay, it's $100, maybe I'll buy it, maybe I won't. It'd be nice to see it. Okay, they've got a 14 day trial, but I've still got to pay for it. This opens up the capacity to, look, there it really is. Play with it for two days or whatever it may be. That's fascinating.

[00:24:05] Birgit Pauli-Haack: Absolutely, yeah. And if you want to test that plugin, yeah, you still would need a local server or a hosting server to load it on. And you have that 14 day trial. And now you can really test it right now.

[00:24:16] Nathan Wrigley: Right. And that's the other big thing. Because if you buy a commercial plugin, you then have to spin up a site somehow. You have to download the plugin, upload the plugin, get the plugin configured. This gets rid of all of that, because you don't need to download and upload anything, and it can be pre-configured.

So the author of the plugin can say, okay, if you want to use my LMS plugin for this kind of thing, here's playground version with everything just right. And if you want to do it for this kind of thing, I don't know, you're an elementary school teacher who might use my LMS plugin in this way, or you're a university lecturer, who might use it in this way. Let's build it a perfect version for you.

And you can imagine that a million times over for all the commercial plugins out there. You know, form plugins. Okay, this is the contact form that we've pre-built. This is the, I don't know, the form which integrates with WooCommerce or whatever. So the developers can do all of this. And that really makes it super useful to them.

[00:25:11] Birgit Pauli-Haack: Yes, absolutely, yeah. What's coming down the pipeline for Playground. One is that you can also use it with private GitHub repos. Which right now is not possible, but it's in the works. And there was a problem with the proxy, that you get some cross site downloading errors because some servers are not set up to have images downloaded from a machine. They have created a proxy server now, where that is kind of circumvented that you can also from non WordPress sites download stuff, like images and content, or PHP plugins.

What also comes is, so SQL, MySQL, for some plugins Playground does not work yet, because they use very specific MySQL query, the union query, for instance. Select union and other commands like that. The SQLite doesn't have those yet. And they are however working on it to replicate these kind of behavior of a database also with Playground. So to make it even more compatible with all the plugins that are out there.

I think they did a test of 10,000 plugins that are in the repo, and test every month kind of how many plugins don't work with it yet. And they got it down from, I think 7% to 5%. So it's always kind of progressing very well towards zero.

[00:26:33] Nathan Wrigley: Yeah, there's a lot of things going on in the background that the likes of you and I probably, you know, because we're curious about it, we'll probably know about, but maybe the average listener who's not wedded to this subject maybe doesn't. But that's really interesting.

So the intention is to get it so that more or less anything works in more or less any scenario. And really nicely putting it out there so that you can do things which aren't bound to GPL, WordPressy kind of things, if you know what I mean. So, you know, you can use your commercial product over here, and you can use your GitHub repo over here. That's really nice.

My understanding is that when Adam began it, he was immediately repurposed. So Adam Zielinski, he was an, was, still is, I think, an Automattician. And I think that it was immediately understood, this is profound. Let's get Adam on this full time. You know, it's no longer a hobby project. But I also think that he's got other people from Automattic involved. There's like a little team around it now, pushing the development of that. Is that still the case? Is this a team which is growing, or stagnating at, well not stagnating, maintaining at a certain number?

[00:27:33] Birgit Pauli-Haack: Well, it's growing in scope. So they're also working, and that was a focus starting in last fall, that they're working on using Playground for the Data Liberation Project. And that's what Adam was doing also full-time now in the last few months. That he looks, okay, what kind of parser do we need to do really good data liberation from other systems, or from WordPress?

Yeah, because the import and export in WordPress only gets you so far, yeah. And there are some quirks in there, and they want to really have a perfect data liberation through Playground. They have a browser extension. It's all beta right now. It's not functioning yet. But it's really coming along quite nicely.

[00:28:20] Nathan Wrigley: So Data Liberation then is this very laudable project of being able to bring into WordPress, I guess data liberation on some levels is the whole point of open source really, isn't it? Is that you can grab your data and just pick it up and take it somewhere else.

[00:28:34] Birgit Pauli-Haack: Open content.

[00:28:35] Nathan Wrigley: Right, yeah. It's your content. This platform is no longer being used, or you've fallen out with it. You know, you no longer love it in the way that you did. You want to now move it here. And you'll be able to, let's say, go Joomla into WordPress, Drupal into WordPress, or as you said, WordPress into WordPress.

Which suddenly kind of opens up the whole idea of migrating websites, which a real mess frankly. It's a really difficult thing to do. And I often think that people are bound to products and services that they're purchasing on a monthly basis because the migration process is so difficult. And they don't want to be caught up in all of that because things can go wrong. You know, it might not work perfectly and there's all the just carrying it out.

But if you can essentially do migrations, and Playground is the sort of go between. It's the bit which talks from, I don't know, one hosting company to another. So it goes from hosting company A to Playground. Playground then serves it up to hosting company B, which is where you want to end up. And all of that happens through Playground. That's remarkable. And you can do the inspecting in the middle bit, the middleware, Playground if you like. Check it's all working before you deploy it. That's amazingly powerful.

[00:29:41] Birgit Pauli-Haack: Yeah. And that's actually the vision of Playground's part of Data Liberation. They also have a browser extension to kind of identify a non WordPress site, the various pieces like the pages, the posts, the news, the events, kind of the custom post types. And then kind of teach Playground what it all is. But that's kind of, it's very technical on one side, but it's also, you need to have a total different concept about content management systems to actually make that. So that's not really for a normal consumer.

[00:30:13] Nathan Wrigley: Yeah, because if you're coming from Drupal and you've got like 1,000 different modules in there, you know, think plugins in the WordPress space. Then it's going to be difficult to one-to-one map that over to WordPress. But the endeavor is to do a half decent job and in the middle you can step in and say, okay, this might need modifying, that might need modifying. And then you can go back to your Drupal install, change things a little bit, try again because it takes no time to do it. That is really a key, interesting part. You do kind of wonder actually if hosting companies in the future will just offer Playground in as part of their bundle, you know, their onboarding migrating bundle.

[00:30:47] Birgit Pauli-Haack: Yeah. A lot of hosting companies have their own plugins for that. So I know that Pressable and SpinupWP, they all have their, or wordpress.com has their own plugin that they then connect with. I think it's BlogVault most of the time. Pantheon, same, yeah. Where you can migrate in. But that part in the middle, that kind of always takes a long time.

And you are bound to the hosting company to actually offer that, yeah. And that's not a cheap plugin. But if you go from one small hosting to one, another small hosting, you don't have that luxury.

[00:31:20] Nathan Wrigley: Yeah, and if you're crossing platforms as well, say Joomla into WordPress and what have you. That's also really different.

[00:31:25] Birgit Pauli-Haack: Yeah. There are a few agencies who have built for their customer things, but it's not open source and it's, well, it's open source, but it's not meant for a huge amount of public to kind of use it.

[00:31:36] Nathan Wrigley: Yeah, I'd imagine that it's fairly proprietary technology, isn't it? It's probably locked down because it's the secret source of getting the Drupal installs into WordPress on their platform.

One of the things which Adam spoke about when we talked, I don't know where we're at with this, but I raised the question of the destructibility of it. So essentially when I spoke to Adam, when you launched Playground, you fiddle with it, played with it, the moment you click close on the browser tab everything went away. That's how it was designed. But he said that at some point in the near future, and maybe that moment has already been passed.

[00:32:09] Birgit Pauli-Haack: It's here.

[00:32:09] Nathan Wrigley: Yeah, so now we've got a more permanent version. Tell us about that. Are there any constraints on that? Like, can I close the browser tab? Can I shut my computer down, for example? I mean, will it last forever? Could I even use it as a, I don't know, as a temporary website in, let's say I work in a school and I want an intranet for my staff or something, could for those kind of things?

[00:32:29] Birgit Pauli-Haack: Well, it cannot be, it doesn't have a domain or something like that. So that wouldn't work. But yes, you can save. You have two options to save the site that you're working on, so you can come back tomorrow. One is in the browser. So it uses the local storage of the browser and really downloads the whole WordPress stuff there. And then you open up the browser again, you get the site again. You cannot load it from another computer because it's a different browser.

And the second option is to load it in your local file system. So you can, it downloads the whole thing, gives you a directory and that's your website, and you can load it then back into Playground a day later, or a week later, or two months later, because it's still on your computer.

You can also have multiple sites now in one Playground instance. So you can say, okay, save this site, and then now I use another blueprint, load it again and it's another temporary site. And you load it, you save it again, then you have a second website there.

[00:33:29] Nathan Wrigley: A curious version of version control or something like that. You've added this plugin in, I'm going to save a new version marking that this plugin got added. Let's see how that works. And then if it doesn't work, we can roll back to the, just delete that one and go back to the previous one. Oh gosh. So essentially permanent. Locally permanent maybe is the better way to describe it.

[00:33:50] Birgit Pauli-Haack: And you need to think about the saving part. If you do a second site and you close it, a browser without the saving part, it's going to go away. Yeah, it's still ephemeral there. Which is also a good thing sometimes.

[00:34:02] Nathan Wrigley: But obviously as you said, you know, the point of hosting in the end is that, you know, it connects to a domain name, it goes through the DNS process and you you can see it online. No.

[00:34:10] Birgit Pauli-Haack: No, not yet.

[00:34:11] Nathan Wrigley: This is not. Oh, not yet. I wonder.

[00:34:12] Birgit Pauli-Haack: No, no, I don't think that's ever going to be. But what can be, soon hopefully is kind of pushing it to a hosting company. And that, I think it needs to be just finalised which hosting is going to be there. And the Playground team learns a lot from wordpress.com, because the new development, local development system that wordpress.com has, Studio, is based on Playground. They develop some of the features also for, that wordpress.com can use them in their Studio. And what was the bug fixes? Come to Playground.

[00:34:46] Nathan Wrigley: That makes real sense though, for hosting companies to be clamoring all over this, to build a Playground import functionality. Because then developers all over the world, you know, maybe if in teams it might be a little bit more difficult, but you know, a solo developer, certainly at the moment, you've been working on something. You've got this perfect version of the site, you've got all the plugins that you want, you've set it up, it's working on my machine. Now I go over to my hosting company of choice, click the import Playground button and there it is. Why wouldn't the hosting companies offer that frankly, it just seems too straightforward.

[00:35:17] Birgit Pauli-Haack: Syncing up with the live site or there's also a GitHub deployment there. It opens so many ideas, yeah. And when you ask Adam, well, if I think about this, and can you do that? He said, sure.

[00:35:28] Nathan Wrigley: Give a few weeks. I'll add it to list of 1,000 things that people have already suggested.

[00:35:32] Birgit Pauli-Haack: Yeah, we need to develop that. Yeah, the ideas are there, the prototypes are there, the proof of concept is already done. Just a matter of resources now, yeah. I can for instance see one thing is, if you have a documentation and you need people to contribute to documentation, you load the documentation in Playground, you make the changes, and then you push it to GitHub as a pull request. And then somebody can review it, load it in their own Playground and approve it so the documentation could be updated.

Something like that is already in use. That scenario, that's in prototype. It's not there yet, but we know that it can work, because some theme developers have that process. They're not developers per se, that they go into the files. They load the theme into Playground, use the Create Block Theme plugin. Make the changes to the theme. Save it and create the block theme, so it's in files. Then push it to GitHub as a pull request for this theme, and then have all the changes there. So that's how a lot of designers work with their developers on the themes. They don't have to touch any code, but it's still all saved in code.

[00:36:48] Nathan Wrigley: It's just such an interesting beginning of everything. It does feel like we are at a moment where there's just so many different roads that could be taken, and lots of people coming up with lots of different ideas.

Just quickly circling back to the Studio thing that you mentioned. So Studio is a local development environment. You're going to be downloading this as a software bundle for your Mac or your Windows machine or what have you. You're saying that's a wrapper for Playground, is it?

[00:37:13] Birgit Pauli-Haack: Exactly.

[00:37:13] Nathan Wrigley: But that's immutably stored. That's not dependent on.

[00:37:17] Birgit Pauli-Haack: No, it's on your machine, yeah.

[00:37:19] Nathan Wrigley: Right. So it's going for the files on the machine approach as opposed to being stored in the browser. So if you download and make use of Studio, you can close that machine down, come back to it whenever you like, it's there until you decide to delete it.

[00:37:32] Birgit Pauli-Haack: Like any other local environment that you can, yeah.

[00:37:35] Nathan Wrigley: Yeah, okay. And that's available free you to download for anybody.

[00:37:38] Birgit Pauli-Haack: Free, open source.

[00:37:39] Nathan Wrigley: Okay. Is there anything else you wanted to cover off, apart from the fact that we've both got ridiculously excited about this. Was there anything curious, interesting, quirky, novel that you've seen out there that we haven't yet touched?

[00:37:50] Birgit Pauli-Haack: No, not yet. But I'm starting now to kind of dream about it. And sooner or later I come up with something, yeah.

What I would want and what I want to pursue is that I can have a Playground instance for writers. And I know writers who are not very keen on using the Block Editor, because it gets in the way. But the Block Editor has these settings where you can do distraction free, where you can do, put the toolbar on top, yeah, and hide it as long as I write, and just let me have when I'm not writing kind of thing, and log in and not have to go to the menu.

Right now, if I'm a blogger, I have to log into WordPress, and then I need to look at post, new post. This would give you, start writing, and don't have to worry about the rest of it. And then click a button and then your WordPress site is updated with it. That's kind of what I'm working on. I don't know if really helpful, but.

[00:38:44] Nathan Wrigley: No, that's really great. I mean, one of the things that I always thought was curious about it would be the idea in education, for educators literally standing in front of pupils, children who, you know, depending on what the kind of curriculum they've got. It might be we're doing about poetry. We want everybody to upload and modify a poem, or comment on a poem or something like that.

And here's the link. You know, we're in an environment where everybody's, we're in the computer lab, everybody's got a computer. Just click on this link, scan the QR code, whatever it may be. Give us your modifications, what have you. And I know that's a sort strange example, but it's the fact that instantly, very, very inexperienced users are in the same exact interface as all the other experienced users. And the level of difficulty was clicking a link. You just needed to click a link.

And the educator didn't need a great deal of technology to set it up. The pupils needed zero technology to access it. And so it's that one to many thing, where lots and lots of people can access the same thing in a heartbeat. And I'm imagining that the tooling to create the Playground installs, and to create the Blueprints is going to make it more and more easy in the future. So possibly not the perfect example, but I do like the example of one to many.

[00:39:56] Birgit Pauli-Haack: Yeah. What I like about it is that it's not about WordPress. It's about poetry. It's about writing. It's about, well, even image uploading and editing, yeah. You could certainly do that. Technology gets out of the way. And for the last 25 years, that's always been in the way, yeah, and now it's out of the way.

[00:40:14] Nathan Wrigley: Well, because the internet is basically a reading experience. I mean, I know we've got forms, but really all you're doing is submitting a form so that somebody can read that. But you go to any website and largely websites, you know, if you're going to some sort of SaaS app, that's a different thing, it's configured probably to be more interactive. But broadly speaking, you're going to consume information.

But in this, you click a link and you're reading information, but then you can do things with it. Oh, I think it would be better if there was an image there in that poem. Or, I don't know, it's an explanation of some principle of physics or something, and a diagram would be really useful at this point, and I don't like the way they describe that, that could go in bold. And you are interacting with the internet. And it's totally free, and it will be easy to deploy, and it'll take seconds to load. And all of a sudden the internet became more interactive. And it's just the beginning. It's very exciting.

[00:41:05] Birgit Pauli-Haack: Yeah, it is.

[00:41:06] Nathan Wrigley: Birgit Pauli-Haack, thank you very much for talking to me today.

[00:41:09] Birgit Pauli-Haack: Thank you for leading me down the road of all the ideas here.

[00:41:13] Nathan Wrigley: Thank you for explaining it.

[00:00:00] Nathan Wrigley: Welcome to the Jukebox Podcast from WP Tavern. My name is Nathan Wrigley.

Jukebox is a podcast which is dedicated to all things WordPress, the people, the events, the plugins, the blocks, the themes, and in this case, the efficacy of website usability testing for WordPress projects.

If you'd like to subscribe to the podcast, you can do that by searching for WP Tavern in your podcast player of choice. Or by going to wptavern.com/feed/podcast, and you can copy that URL into most podcast players.

If you have a topic that you'd like us to feature on the podcast, I'm keen to hear from you and hopefully get you, or your idea, featured on the show. Head to wptavern.com/contact/jukebox, and use the form there.

Today I bring you the first in a mini series of podcasts I recorded in person at WordCamp Asia in Manila. This flagship WordPress event brought together hundreds of WordPress professionals, enthusiasts, and all manner of interested parties under one roof for a three day event. One contributor day, and two days of presentations.

I tracked down several of the speakers and workshop organizers and recorded them speaking about the subject they were presenting upon. I hope that you enjoy what they had to say.

So on the podcast today, we have the first of those conversations, and it's with Jo Minney.

Jo based in Perth, Australia, is passionate about user experience, data-driven decision making, cats, pockets, and travel. She's a small business founder, and works with organizations creating digital platforms with WordPress. She also freelances as a UX consultant. She volunteers with Mission Digital to address social issues using technology, and is an ambassador for She Codes Australia, promoting tech accessibility for women. Recognized as a 2023 Shining Star by Women in Technology, Western Australia, Jo is an international speaker on topics like user experience, accessibility, and gender equality. She's committed to ensuring a seamless user experience, and today shares her insights from practical, everyday usability testing.

Joe's presentation entitled, Budget Friendly Usability Testing for WordPress, helped attendees understand what usability testing is, and clarified why it differs from other testing methods. She shares examples from her work showing how small changes can significantly impact user experience, which is better for you, the website builder, and your client, the website owner.

We also discuss how usability testing can transform a website's effectiveness by improving conversions. Joe explains the importance of recruiting novice users for testing, and highlights how usability testing pushes for real, user-centered, improvements.

Towards the end, Jo share's practical advice on when and how to integrate usability testing into your process. Advocating for early and iterative testing to preemptively address potential issues.

If you're looking to gain a deeper understanding of usability testing and its benefits, this episode is for you.

If you're interested in finding out more, you can find all of the links in the show notes by heading to wptavern.com/podcast where you'll find all the other episodes as well.

And so without further delay, I bring you Jo Minney.

I am joined on the podcast by Jo Minney. Hello, Jo.

[00:04:06] Jo Minney: Hi. It's good to be back again Nathan.

[00:04:08] Nathan Wrigley: Yeah, you've been on the podcast before. But this time it's different because this time we're actually facing each other. Last time we were doing it on, you know, something like Zoom or something like that, but here we are staring at each other because we're at WordCamp Asia. We're in the Philippines, Manila. It is the second day of the event, kind of. We had Contributor Day yesterday. Today is presentation day. It's the first day of the presentations, and you are doing one.

[00:04:29] Jo Minney: I've done one actually. I did it at 11 o'clock this morning.

[00:04:33] Nathan Wrigley: How did it go?

[00:04:34] Jo Minney: It went really well, I think. I had very good feedback from it. Half of the things on my slides didn't work. I think that's normal for a conference though, and I'm pretty experienced now at just winging it, and rolling with it anyway, so. It was really exciting because it's a topic that I'm super passionate about and I haven't had a chance to speak about it at a conference before. So, yeah, it was really nice to be able to share something that I do on a day-to-day basis and can stand up there and really confidently talk about.

[00:04:58] Nathan Wrigley: I don't think I've ever spoken about this subject before in any of the podcasts that I've done. That is quite nice, and it's novel. I'll just introduce the topic. The presentation that you gave was called Budget-Friendly Usability Testing for WordPress. And obviously that sort of sums it up. We're going to talk about usability testing.

But before we do that, Jo, just to nail your colours to the mast a bit, tell us about you. Where you're from. What you do for a job, and anything that you think is relevant to this podcast.

[00:05:22] Jo Minney: Okay, I really like cats and pockets.

[00:05:25] Nathan Wrigley: I saw that in your show notes. Why pockets?

[00:05:27] Jo Minney: Okay. So I think pockets are a great example of something that can be both a fantastic and a terrible user experience. You are like, oh yeah, maybe I know what you're talking about. But, let me ask, do you live with a woman?

[00:05:39] Nathan Wrigley: I do.

[00:05:39] Jo Minney: I know that's a very personal question, sorry Nathan. But, how many times on average a month does she complain about not having pockets in her clothing?

[00:05:48] Nathan Wrigley: Never, she carries a bag.

[00:05:50] Jo Minney: Yeah, but why do we have to carry a bag, right? She has to carry a bag because her clothing doesn't have pockets. So I spoke at a conference late last year, and I asked this question. This has been a life goal of mine, was to speak about pockets at a conference. And I managed to do it. I asked all of the women in the audience, hands up if you've ever thrown out clothes or gotten rid of them because they didn't have pockets in? And every single woman stood up and was like, yes, I've gotten rid of clothes because they didn't have pockets in.

Most of the people that were there were men. And I said, stand up if you don't have pockets in your clothes right now. And 400 men stayed seated. But this is an example of something where, yes, there's a subsection of the population that's experiencing this problem, but it's a big problem for us. It's very frustrating. You're at a conference, you don't want to have to carry around a handbag. So, pockets. They're a great example of user experience.

[00:06:45] Nathan Wrigley: Okay, I get it. I understand now. Tell us a little bit about your sort of day-to-day work, though. You work with WordPress, I guess.

[00:06:51] Jo Minney: I do. So I run a small agency. We're what I usually call a micro agency, and we have only three of us that are working on the WordPress team. We do website development, but specifically for charities, nonprofits, cause-based organisations, so a lot of social enterprises and that sort of thing.

On top of that, I also do consulting for user experience research. I'm not a designer. UX and UI often get lumped together. They're very different. UI is about the interface and what people see, and UX is about user experience and how people use things. And they can't be completely separated, but they're also very different.

So I am lucky because I work in the niche that I work in, that I'm able to do a lot of usability testing and it's something that a lot of people don't get the experience to do. And so I thought I would share what I've been able to learn over having this sort of unique opportunity to do so much usability testing, and share with people how they can do it more cost effectively, but also the benefit that it can have for a project.

[00:07:54] Nathan Wrigley: Let's dig into it and I'm going to actually crib the questions which you posed to the audience today. You put four questions surrounding your subject. And the first one is this. And I'm sure that the listeners to this podcast, if they're anything like me, they'll probably have some impression that usability testing is a thing that you could do. And I think the word there is could, as opposed to do, do.

I imagine most people have an impression of what it is, but whether or not they do it is another thing altogether. But that would then lead to this. What even is it? So what is usability testing, and what are you actually testing for? So that was a question you posed to the audience and now I'm throwing it right back at you.

[00:08:34] Jo Minney: Yeah, it's a good question. It's probably the sensible place to start. So usability testing is not the same as user testing, or user acceptance testing. And it's focusing on, how do we identify what the problems are with something that we have created?

So a lot of UX research is focused on what we call quantitative testing. So, meaning we're looking for quantities of something. It could be the amount of time it takes someone to do an action. It could be using heat maps. So we have a thousand users, let's see where their cursors most often are going. Let's see how often they scroll down the page. And quantitative testing is really good at showing you comparisons of whether one thing or another thing works better, but it's not actually good at identifying what the problem is, only that there is a problem.

So you can do a lot of testing and still not know what the problem is. Usability testing is different because it's what we call qualitative testing. So it means that we're not looking for big numbers, we're not looking for lots of data. We are looking for really deep user experience examples. And in a nutshell, the way that that works is you recruit some participants, usually five people per round is ideal. And often I get asked, well, how can you have statistically significant data with only five people? That's not the point of qualitative testing. The point of qualitative testing is not to have statistically relevant data, it's to have the actual user experiences.

So you recruit your people, you come up with your research questions and that's the problem that you're trying to solve or the question you're trying to get an answer to. So, an example might be, are users going to recognise this label that I've used in my navigation? Is this button going to get clicked if I put it in this location? It's often a thing that, if you're working with a customer to develop a website for them, what we find is that often the things that we are testing for in usability testing are things that the customer and I disagree on, or things where they weren't sure when they made the decision in the first place. And they're a great example of things that you want to test for.

But the research questions are only the first part because if I say, the example I used in my talk today is that we had a support service directory. And this was for people who are experiencing family domestic violence. And they didn't want to use the term directory because it's a very harsh term. So they had called it support services, which sounds, on the surface like a good idea, but a lot of the people that are using their platform are not English first language. And they also tend to be in a really stressed out state as you can imagine.

And so what we actually found is that when we said to them, can you imagine you're helping someone, can you help them find a legal service that will enable them to get a restraining order or something like this? What we found is that repeatedly they didn't go to support services to start with. The minute we changed that to service directory, they started to find the thing that we wanted them to click on.

It's such a small change, but it made a huge impact, the usability. Now, we found that out after the second test, which meant that we were able to change it after the second test, and then we had three more tests where we could show that every time they were able to find the thing that we wanted them to be looking for.

So this is an example where the research question and the research task or the activity that we're giving to the user, they're not the same thing. If we said to them, find support services, find the service directory, if we use that language, obviously they're going to look for that label. But instead we asked them to do an activity that would hopefully take them to the place we wanted them to go to.

And then finally the last step is to iterate that and to actually take that data and make decisions, and make improvements to the project iteratively to try and make it better. That's the goal, right? Is to find what the problems are and fix them. So we still have to work out how to fix them, but at least we know what the problems are and not just that people were not clicking on the button and we don't know why.

[00:12:27] Nathan Wrigley: I have a couple of follow up questions. First thing isn't the question, it's an observation. So that's really cleared up in my head what it is, so that's amazing. But one of the things that I want to know from that is, do you filter out people who, let's say for example, you've got a website, the kind that you just described. Do you filter out people who are not the target audience? So in other words, I don't know, maybe that's not a perfect example. But let's say, on some websites, would it be better to have really inexperienced users of the internet as your five candidates?

[00:12:59] Jo Minney: That is exactly the ideal person.

[00:13:02] Nathan Wrigley: So people who are just, I've never come across this before. You want people who are potentially bound to be confused. If somebody's going to be confused, it's you five.

[00:13:10] Jo Minney: That is the ideal participant for a usability study. And often people say, I want to start learning how to do usability testing. Where should I start? And my advice to them is always the same, with your mum.

Recruit a person that's a generation older than you, because I can guarantee that in most cases, sorry to generalise, but they tend to be less efficient and less used to technology because they haven't grown up with it. So for millennials and younger, we have had technology for all of our adult lives and most of our childhood.

For my parents' generation, they have had to learn that technology as an adult, and so their brains have a different mental model, and they don't take for granted things that we take for granted. Like, when I click the logo, it will take me back to the homepage. I know that, you know that, your mum might not know that.

And I think that is something that is really valuable is to understand the benefit of testing with people who aren't as experienced with technology. Who don't speak English as a first language. Who are experiencing some kind of accessibility challenge. Whether that's using assistive technology, being colorblind. Things like that are really good things to try and get some cross-sectional representation in your testing participant pool.

[00:14:25] Nathan Wrigley: So the idea then is that you've got these novice users who hopefully will immediately illustrate the point. And it's driven by questions. So it's not just, we are just going to stand over your shoulder and watch you browse the internet, and when you do something and describe, you're looking for something and you can't find it, that's not how it's done.

It's more, okay, here's a defined task, do this thing and we're going to ask you to do five things today, we want you to achieve them all and describe what you're doing, but it's more of that process.

And then the idea is that you go from an imperfect website, slowly over time, iterating one problem after another towards a better website. The goal is never reached. It's just an iterative process.

[00:15:01] Jo Minney: That's it. Perfection does not exist.

[00:15:03] Nathan Wrigley: Okay, so that's interesting. So we start with the novice. We've got a small cohort of people. We ask them specific questions, and we get feedback about those specific questions.

So the other thing that I wanted to ask then is, when do you do it? Because it feels like you need to build the website first, then show it to people. So there's got to be something. This isn't process of discovery prior to the website. You need pixels on pages. Buttons that are potentially mislabeled or what have you. Is that the case? Build first, then usability test afterwards. There's no usability testing prior to the initial build.

[00:15:37] Jo Minney: It's kind of a trick question because you can usability test at most stages. Probably the only stage you can't usability test at is when you don't yet have a site map. Having said that, my recommendation is, assuming you had unlimited budget and unlimited time, I would do at minimum two rounds of usability testing, and I would do one before you have any design, and I would do it just using wire frames.

So we build interactive wire frames using WordPress. So for the demo that I did today, I spun one up. I used InstaWP. You can get like a seven day website or something through there. It took me 42 minutes to build out the website in just the block editor, with no design or anything, just the layout of it. And I was eating a loaded potato at the time. So if I can do that in 42 minutes, eating a loaded potato, and that's not my job, I think it's a pretty efficient and cost effective way of being able to do early usability testing.

And often the thing that we're testing for there is like, have I got the right navigation structure and hierarchy? Are the labels that I'm using sensible for people? Do they fit with the mental models of what our users are actually expecting? And the benefit of doing it that early is that when you don't have a design applied, it's a lot easier to identify problems.

Because there is a thing that happens in human psychology, and there's a lot of psychology in user experience. And there's a thing that happens where if something's pretty, we will say that it is easier to use. Our experience is that it's easier to use because it's nice to look at. And that's great. That means that UI is really important, but it also means that, if you have a really nice UI, it can mask problems that you have in the background. It is great that things can be easier if they're pretty, but imagine how much easier they would be if they worked well and were pretty, that's what we should be aiming for.

So typically we would do one round of usability testing when we just have a framework and just have the navigation. When someone lands on a page, sometimes we'll just write a message on there and say, congratulations, you found the service directory where you can find this thing, this thing, this thing, this thing, and then we put a little button there. When they click it, it releases confetti on the page. So they get a dopamine hit and it's like, yay, I completed the activity. You don't have to have all of your content in place to be able to do testing, and identify early that you've got problems that you need to fix.

[00:18:02] Nathan Wrigley: It sounds almost like an overly complicated design is the enemy of usability. We are drawn towards beautiful, but sometimes maybe beautiful just is overwhelming. You know, there's lots of colors on the page, the buttons get hidden, there's just too much text on there. Looks great, but it might be sort of masking the thing that you're really trying to show. And it feels like there's this tight rope act of trying to balance one thing against the other. Yeah, that's really interesting.

So, with the wire frame thing, in that case, you are really just testing, can the person find the thing? But I'm guessing once you've move beyond the wire frame stage and you've got a website, it's literally out on the internet, it's functional. It's exactly what we hope would be the perfect version, then you're drilling into more detail. You know, can a person find this resource? Do they know that this button is what we are intending them to click? Those kind of things.

[00:18:49] Jo Minney: Yeah. So I think things like searchability and discoverability are much easier to test for in the early stages when you're just doing, say, using like a wire frame or a prototype. And things like usability, you really do need to have the complete designed product to be able to test for them well. And I say that, there's actually kind of four categories of the different types of tasks that we can do. I'll give you the link to the blog post that I wrote that has all of this in detail because we do not have time to go deep into that today.

But things like, does my search form work the way that I want it to? They're the sorts of things that you do have to do some development to be able to get them working. So it's not always practical to do that at the very early stages when you do want to start testing your navigation and stuff like that.

Something that you can do is if you've only got enough budget, or enough time, to be able to do, say, five usability tests total, you could do two of them early, and then you could do three of them towards the end, after you have the majority of the design and the development work in place. Users are pretty forgiving when they're doing a usability test. If you say, this is still a work in progress, there might be a couple of pages that look odd and aren't quite ready to go live yet. If you get somewhere and you're not sure, you can just go back, it's okay.

It's not meant to be a perfect experience. The point is that you are getting their real time thoughts and feedback as they're doing it. So it's really important that you try and encourage them to follow the think aloud protocol, which is really outlining every single thing that goes through they're head, just brain dump on me please. Like, I just want to hear all of your thoughts and thought processes.

And the only thing as the facilitator that I will say during a usability test is, tell me what you're thinking. And other than that, I am completely silent. So even when it comes to giving them the activity, so if I'm asking you to do an activity like help somebody find a legal service that they can use in this particular state. I would actually send that task to you via the chat or something like that.

I would send the task to you via the chat, and then I would get you to read that task back to me, because I don't want you to be thinking about how I'm saying it. I want you to be able to go back to that task and look at it, and think about it, and process everything inside your own head. But I want you to be telling me all of that.

So often we'll find people ask questions during that, like, what should I do next? And the answer to that is really hard to train yourself out of replying to them with anything other than, what would you do if I wasn't here? And I think that's the hardest thing about learning to facilitate a usability test.

[00:21:24] Nathan Wrigley: Yeah, and in a sort of an ideal scenario, you wouldn't even be in the room. But in some strange way, you'd be able to just get into their head and say, okay, now I want you to do this, but every time you've got problem, just figure figure it out, and we'll watch. But you have to be there because you have to be able to listen to what they're saying and what have you. Yeah, that's curious.

[00:21:40] Jo Minney: Yeah, and we do, at the end of each activity, we'll then ask them for feedback on how they found it. If they had any suggestions or things that they didn't say out loud while they were doing it that they wanted to share with us. How confident were they with the activity, and did they think that they were successful in it, which is a really good way of telling, I wasn't really sure what the activity was meant to do. Or I wasn't really sure if what I found really met the needs that I was looking for.

Then we ask them, how certain are you with the answer that you just gave? And if they're like, three out of five, you're like, alright, this person didn't understand what it was that I was asking them to do in the first place. Maybe the problem is actually with my question and not with the website.

[00:22:18] Nathan Wrigley: Okay, so the whole process is, you're not just asking for feedback about the website, there's a whole process of asking for feedback about the process as well which is, that's kind of curious. Meta, meta processing.

[00:22:27] Jo Minney: Very meta, for sure.

[00:22:29] Nathan Wrigley: We're in an industry where at the moment everything is trying to be automated.

[00:22:32] Jo Minney: Is this the AI question?

[00:22:34] Nathan Wrigley: Well, no, this feels like it's a very human thing. You need actual bodies on the ground. So it's really a question of economics. Because I'm wondering if this often turns out to be a fairly expensive process. And because of that, I wonder if people push against it, because the budgets may not be there. If this is something that clients typically would say, well, okay, tell me how much that's going to cost. It's a nice idea but, okay, it's going to cost us X thousand dollars because we've got to put five people in a room and we've got to pay for your time to moderate the event, and come up with the questions and so on.

How do we manage that in an era of automation where everything is, the dollar cost of everything has got to be driven down. This feels like the dollar cost is going up because there's humans involved.

[00:23:14] Jo Minney: Yeah, it's a great question. Have you ever run a Google ad before?

[00:23:17] Nathan Wrigley: It's expensive.

[00:23:18] Jo Minney: It's very expensive. It's very expensive to get a new lead. It's a lot more cost effective to convert a lead than it is to get a new one. And the point of usability testing is to improve conversion of people being able to do the thing that you want them to do on the website.

So my first answer to that would be, look at the cost benefit analysis. It's worth it in most cases to do usability testing. Something that we've found with positioning of usability testing is that if we offer it as an add-on, then people don't want to do it because they don't want to pay for it. They see the value in it necessarily. However, we don't offer it as an add-on.

We actually have it just as part of our proposal right from the start where we're like, this is part of the point of difference between what you get when you build with us versus when you build with someone else. They'll tell you what they think is the best way to do something. If we are unsure about the best way to do something or we disagree on it, it's not going to ultimately be me making a decision or you making a decision. We're going to test and we're going to get real evidence from customers.

And they're the ones that are going to be developing it so you know that the final result that you get is going to be the best possible version of the website. And often we might be more expensive than our competitors, but people will go with us because we are not competing on price. We're competing on offering a service that nobody else is offering. I asked today in the presentation who has done usability testing before and not a single person put their hand up.

[00:24:42] Nathan Wrigley: That would've been my assumption actually.

[00:24:44] Jo Minney: Yeah. And honestly, I don't think any of the people that we're competing against in the industry that I'm in are doing the same thing as what we're doing. And so it is very much a point of difference. I think it's not a well understood technique, but it's so valuable that it is a really easy way to position yourself as being different, and really actually do a better job for your customers, for the people that you're building websites for. Because ultimately you are going to have a better result at the end of it.

[00:25:12] Nathan Wrigley: The interesting thing there is, when I say usability testing, somehow in my head there is a connection between that and accessibility. And that's not where I'm going with this question, but there's just something about it being unnecessary. And I'm not binding that to the word accessibility. What I'm saying is clients often think, I don't need to do that. Obviously, we're moving into an era where legislation says otherwise. But I can just leave it over there. I don't need to worry about that, usability testing, not for me.

However, the lever that you've just pulled, it completely changes the dynamic because you've pulled an economic lever, which is that if we can get everybody to follow this action, I don't know, fill up the cart with widgets and then press the buy now button, and go through the checkout process. If that's the thing that you're usability testing, you've made direct line. You've joined up the dots of, okay, user, money.

So it's not just about it being a better website so that people can browse around it all day. It's also about connecting the economics of it. So the usability is about people buying, converting, getting the resource. And so there might not be an economic transfer there, but it will be some benefit to your business. There might be downloading that valuable PDF that you want everybody to see or whatever.

So that's kind of interesting. That's changed my thoughts about it a little bit. And it is more about that. It's getting an understanding of what you want out the website, getting an understanding of what you think should be happening is actually possible and happening. Have I sort of summed that up about right?

[00:26:40] Jo Minney: Yeah, I think that's a really good summary it. I think the only thing I would add there is that a lot of the times the conversation around accessibility and the conversation around usability do have a lot of crossover. They are fundamentally different, but one of my favorite examples is actually something that I think applies to both.

So two of the common problems that we find very early on in design is often to do with colour. And so one of them is colour contrast and the other one is colourblind accessibility. And I think it's a great way to get people to change their thinking, and their perception of the way we have these conversations is, if you have an e-commerce website, Nathan, what would you say if I said to you, I can instantly get you 8% more customers?

[00:27:23] Nathan Wrigley: Yeah, I'd say that's great.

[00:27:24] Jo Minney: And I'd be like, cool, change your buttons so that colourblind people can read them, because 8% of men are colourblind. So actually it's only 4% of people because assuming half of them are men, then you've actually only got 4%. But still 8% of men are colourblind, that's a big percentage of the population. So if your button is red and green, then you're going to have a problem. People are not going to be able to find the thing that you want them to click to give you their money.

Likewise, if you want people to be able to use your website when they're outside and using their phone in sunlight, then you need to have good colour contrast on your website. So often this conversation is around, well, I don't have people who are disabled, I'm not trying to cater to people that are using screen readers. It doesn't matter because not very many people that are using my website are blind. And I'm like, well, I'm not blind but I still struggle when I'm looking at something where the text is too faint, and I'm looking at it on my phone, and I'm standing outside in the sun because we naturally don't visualise as much contrast there.

So I think being able to position it in a way where people can see the value to themselves. I want to use a website that has better contrast, and so it makes that conversation easier with a customer.

[00:28:32] Nathan Wrigley: I hadn't really drawn the line between accessibility and usability, but it seems like they're partner topics, basically. There's like a Venn diagram, accessibility over here, usability over here, with a massive overlap somewhere in the middle.

[00:28:43] Jo Minney: A hundred percent. That's why we always encourage having that sort of intersection between accessibility and usability in our testing pool. So we always try and have one person who experiences some kind of accessibility challenge, whether that's being colourblind, hearing impaired, if we've got a lot of video on the site, for example. And I think that it can be a really valuable way of collecting multiple data points at one time.

[00:29:04] Nathan Wrigley: When you have a client that comes to you and they've obviously, by the time that they've signed the contract with you, usability is already part of the deal it sounds like. How do you decide, what's the thing in round one that we're going to pick up on? Is there sort of like a copy book that you go through? Is it like, I don't know, buttons or the checkout or colour or? Where do you go first? And sort of attached to that question a little bit, this process never ends, right? In theory, you could do usability testing each month. But I was wondering if you did it like on an annual cycle or something, yeah.

[00:29:34] Jo Minney: If you're not changing stuff super often, I would say, there's probably more cost effective ways that you can collect information about it. Typically we encourage, long-term, have things like heat maps and stuff like that. They will help you identify if there is a problem. If you know that there is a problem, let's say you've got a heat map and you're like, why is nobody clicking on our buy now link? That is a good instance of where you would do some usability testing to figure out what the problem is.

But if everything's working and you're getting conversions, then probably doing usability testing isn't the most valuable thing that you can do. If you're looking at making significant changes to the way that your website works, that's another good time to introduce a round of usability testing. So we don't do it just for the sake of doing it. We do it because we need to do it, and because there's value in it for our customers.

[00:30:18] Nathan Wrigley: Do you keep an eye on your customer's websites so that you can sort of get ahead of that, if you know what I mean? So let's say that you put heat maps in, very often that would then get handed over to the client and it's somebody in the client's company's job is to check the heat maps. Or do you keep an eye on that and, oh look, curiously, we've seen over the last 12 months, yeah, look at that. There's not much going on over at that very important button over there. Let's go back to the client and discuss that. That could be another round of usability testing.

[00:30:44] Jo Minney: Yeah, so I think we're not uncommonly, a lot of agencies now do have some kind of retainer program where they will maintain communication and assistance for their clients. So we call them care plans. I know everyone has a different name for it. I think it's pretty standard now in the WordPress ecosystem. It's a very common thing to do.

As part of our care plans we have scheduled meeting with our clients once every three months or six months or 12 months, depending on how big the site is. And one of the things that we'll do at that time is review their analytics, review the heat maps, that sort of thing.

Ask them, have they experienced any problems? Have they noticed a downturn in the people signing up for the memberships? Or have they noticed, have they had any complaints from people about something? Is there anything that they're not sure about? Are they going to be changing the way that they operate soon, and introducing something new into their navigation that we need to consider where does that fit in the grand scheme of things?

I find if we're having those conversations early and we are the ones starting those conversations, then often we are coming to them with solutions instead of them coming to us with problems.

[00:31:46] Nathan Wrigley: I think that's the key bit, isn't it? If you can prove to be the partner that comes with, we've got this intuition that there's something that we can explore here. You are proactive, you're going to them not, okay, anything you want? Is there anything we can help you with, you know? And the answer to that is always, not really.

Whereas if you go and say, look, we've got this idea, based upon some data that we've seen, we've got heat maps and what have you, shall we explore that further? That seems much more credible. You are far likely, I think to have an economic wheel which keeps spinning if you adopt that approach, as opposed to the is there anything you want doing, kind of approach?

[00:32:18] Jo Minney: Absolutely. I think every developer's worst nightmare is having a customer come back to them and say, I've just noticed that I haven't had anyone send through anything in my contact form for the last three weeks. And I've just noticed, when I went and tested it, that the contact form's not working anymore.

I'm sure I've had that nightmare at least once. And I think if you can avoid being in that situation where they're coming to you with something like, oh my God, it's broken, how do I fix it? If instead you can go to them and be proactive about it and just kind of keep your finger on the pulse.

Yes, there's a little bit of ongoing work, but like honestly, I jump on, I check all of the analytics maybe once every three months for my clients. I set aside one day to do it. Go and have a look through that. If I notice anything, I can usually fix it, make sure that we're collecting the data again before it becomes a problem.

And then that way when there is an issue, we've got data that we can back up and we can start from there and go, okay, yes, we've identified, here's where we need to do more research. And then we can apply something like usability testing to that.

[00:33:16] Nathan Wrigley: How much of your time on a monthly basis, let's say as a percentage, do you spend on usability of existing clients? Is this something that is a lot of the work that you do? What I'm trying to figure out here is, for people listening, is this something that they can turn into a real engine of their business?

Because you might get two days, three days work a week just on the usability of pre-existing clients. So in a sense, you've created interest and work out of thin air, because these clients already exist, they're in your roster, but there's a whole new thing that we can offer to them. So, how much do you spend doing it?

[00:33:50] Jo Minney: Yeah, so it's a great question. I would say it's cyclical. I couldn't really say like, I always spend this much amount of time. There might be entire weeks that go by where my whole life is usability testing, and there might be a month that goes by where I don't do any. And it really does often depend on where our projects are in the life cycle at any particular time.

So we're often working on projects that will span over years. And because of that, they might introduce a completely new part of their project. And that's a good time to reintroduce that usability testing. As I said, like you don't really want to do it just for the sake of doing it, but at the same time, if you can show that there will be value in making a change, if you can show that there is a lost opportunity somewhere, then a hundred percent you can sell that, the value to them of, hey, you could spend $1,000 now, but you could be earning $5,000 more every month for the next several years. That's a no-brainer, right?

People are happy to make investment if they can see that there's going to be a cost benefit for them in the future. Or if the thing that they're trying to do is maybe their government website or something, and they've got a particular thing that they need to meet, they've got KPIs. If you can show that you are able to help them meet those KPIs, then they are going to invest in doing that thing that you're trying to offer them.

[00:35:02] Nathan Wrigley: We talked about the Venn diagram of accessibility and usability, and the fact that there's a lot of an overlap. In the year 2025, this is a year where, in Europe at least anyway, accessibility, the legal cogs are turning and the screw is getting tighter. So accessibility is becoming mandated in many respects.

And I was wondering about that, whether there was any kind of overlap in legislation on the usability side. The accessibility piece is obviously easier to sort of define in many ways, and it's going to become less optional. But I was wondering if there was any usability legal requirements. I don't know quite how that would be encapsulated.

[00:35:41] Jo Minney: Sort of. An example that comes to mind is that there are a lot of practices that historically have been really prevalent on the internet, and they've been identified as being really bad for usability. And they've actually now been identified as being so bad that they're almost evil. And they've started to crack down on those.

And an example of that is, have you ever tried to unsubscribe from a gym? It's basically impossible. And so now if you, at least in Australia, I know if you have a subscription on your site, you legally have to have a way of people being able to unsubscribe without having to call someone or send an email somewhere.

And that is an example where that is actually usability. And I think there are definitely things where we are picking up on stuff that is maybe a shady way of working, and a shady way of developing websites. And those things are starting, we're starting to cut down on them.

I'm not sure if that is purely usability, or just like not being being a bad person. But I think that there is definitely, the only reason that we know that those things are a problem is because we have all had those bad experiences. And ultimately that's all user experience is, it's just how good or bad is experience of using a platform.

[00:36:49] Nathan Wrigley: I share your frustration with those kind of things because I've been through that process. Not just canceling a subscription but, I don't know, something that you've got yourself accidentally into and you don't want to be on that email list anymore. Seemingly no way to get off it.

[00:37:01] Jo Minney: They've changed the unsubscribe link so it doesn't have the word unsubscribe in it. And now you just have to look for the word that's not underlined, or highlighted in a different colour. That when you hover over it, something pops up and you're like, oh, that's the link. That thing that says manage preferences down the bottom, hidden in the wall of text. That is a shady practice. That is a poor user experience just as much as it's just a bad thing to do.

[00:37:23] Nathan Wrigley: I think it's got the label of deceptive design now. It used to be called dark patterns, didn't it? But deceptive design. This notion of doing things in such a way to just deliberately confuse the user so that the green big button, which is the exact opposite of what you want to click, is the one which is visible. And then there's this tiny little bit of greyed out text, which is the one which, clearly, you've ended up at this page, that's the one you want. That's the enemy of usability in a way. But for the business, it may be exactly what they want because it keeps the economic engine rolling.

Yeah, that's interesting. I wonder if there'll be more legislation to tighten those things up so that they're not allowed. Yeah, that's fascinating.

Last question. We're running out of time. Last question. And it refers to something that we talked about earlier. I'm guessing this really never ends. This is a journey which you begin, you tweak it, you do a little bit, you fix, and then you start again a little bit later and what have you. Is there ever a moment though where you go to a client and say, we did it? This site, as far as we're concerned, is now perfect. Or is it never a goal? It's a journey and never a destination.

[00:38:23] Jo Minney: I think you'll probably agree with me here, Nathan, that it's basically impossible to be perfect, because ultimately someone is always going to have a different opinion. Someone's always going to think that your shade of purple is too dark. Someone is always going to dislike the font that you chose, because it's not loopy enough, or it's too loopy, right?

So I don't think there is such a thing as perfect. But through doing five usability tests, five people, you can pick up at least 85% of the potential problems with your design. And I'm not aiming for perfect, but I know that for me, if I can confidently say to my customers that I've been able to identify 85% of the potential problems that they might experience in their project, then they can confidently go away and say, hey, we're pretty happy with what we've got.

We can definitely improve on that over time. But that is a huge milestone to be able to hit. And being able to have enough data, and enough research to confidently say that, I think is a really big win both for us and for our customers.

[00:39:26] Nathan Wrigley: Sadly, Jo, time is the enemy, and I feel like we've just pulled back the lid a teeny tiny bit on the big subject of usability. Honestly, I reckon I could talk for another two hours on this at least. You know, because you've got into colours there and all sorts, and there's just so many tendrils that we haven't been able to explore. But we've prized it open a little bit, and so hopefully the listener to this has become curious. If they have, where would they find you? What's a good place to discover you online?

[00:39:53] Jo Minney: Yeah, so I think the best place is to hit up my personal blog, jominney.com. So it's J O M I N N E Y .com. And I have a lot of stuff on there about usability, usability testing. I have a blog post that I wrote specifically for this talk that shares all of the resources that I used to put together the slides and everything. The talk itself will be on WordCamp TV. If you're on socials and you want to hit me up, pretty much the only platforms I'm active on nowadays are LinkedIn and Bluesky, and I'm Jo Minney on both of them.

[00:40:23] Nathan Wrigley: Jo Minney, thank you so much for chatting to me today. I really appreciate it.

[00:40:27] Jo Minney: You're most welcome, Nathan. Thanks for having me again.