After you publish, test and review

As a consultant to business and government, I know my clients often see publishing as a project that has a start, middle, and end. Once they’ve published their app, their data, or their text and media, they often express relief that the job is finished and then want to forget about it.

The thing is, they’re not finished. If the app, data, or content is mission critical, they must not simply forget about it.

A story: Averting failure

To illustrate what can happen when people publish and forget, here’s a simple story. It’s from the perspective of a customer or “user” of some material that was published by others. In this story, I am one of those customers.

I wanted to meet a colleague near London’s Liverpool Station, so that we could attend a design event together. To decide where to meet, we used the internet to access a tool, data, and material published by others.

We needed to:

  • look at a map of Liverpool Street Station
  • choose a meeting location nearby
  • have a look at the event brochure


We tried to choose a restaurant near Liverpool Station, but we encountered errors on the map—either with the app’s function or with the location data on it. Then, I tried to look at the event brochure, but I had to wait several minutes for it to appear on screen. Instead of reading the brochure, I instead relied on my colleague’s interpretation.

My colleague and I were in different places, so as we used the map and tried to view the brochure, we used a chat tool. Here’s our conversation:

Colleague: Tomorrow is the last day of the London Design Festival. There is one exhibit at Exchange Square Broadgate that sounds cool, and would be esy for each of us to get to, and easy to get home from. We could meet at or near Liverpool Street Station and walk over. Me: OK. Meet at what time? Colleague: Let's aim for 4:14. That gives me 45 minutes to make the trip from W11.

Me: The bus from here goes directly to Liverpool Street Station. It's big. Where exactly shall we meet? Or do you mean the Underground station rather than the train station?

Colleague: Underground. It's basically the same station. Exit onto Old Broad Street. There is a Pret à Manger near a Boots drug store. Me: Near Liverpool Street Station there are THREE Prets. One on Eldon, one on Bishopsgate, and the one on Old Broad. Good thing I checked: it's the Old Broad, right?

We picked a restaurant chain. As it turned out, there were multiple locations near Liverpool Street Station. We both realised the potential for confusion.

Colleague: There are 2 Prets on that street! Damn. The one nearest Broadgate Circle, near the Boots. Me: How about an address? LOL. Colleague: Address is 19-20 Liverpool St. Ec2M 7PD. Me: The closest Pret is on Eldon Street.

While trying to be clear about our meeting place, we realised there were differences in our maps. Was it an error in the map data?

Colleague: I don't see that on my Google map. Me: Never mind. Let[s just meet at 19-20 Liverpool Street. I don't see a Pret at that address, but I'll just go to 19-20 Liverpool Street. … I am also using Google Maps.

To clear up the confusion, my colleague sent me an image. We needed to make sure we were looking at the same thing.

Colleague: I'm sending you a screenshot. The screenshot shows a map near Liverpool Street Station, with a Pin or bubble marking a Pret restaurant location. Me: What's wrong with the address? 19-20 Liverpool Street. (I'm now going to look at the screenshot.) OMG, there are FIVE Prets near Liverpool Street Station.

Colleague: That's the right address: 19-20 Liverpool Street. That[s what I get when I click the Balloon. Me: Me too. Interestinglyy, when I enter 19-20 Liverpool Street as the search criterion, the pin appears elsewhere. Nearby,but on a different street. Colleague: Weird.

Next, I added my own information to the image—I marked it up using circles and arrows—in order to confirm our meeting place.

Screenshot shows the map, now with annotations circling the incorrect clocation and the correct location. The correct location has a black arrow pointing at it. Me: I'm going to the Pret at the black arrow. Colleague: Yes. Me: LOL!

We realised it took us longer to choose a meeting place than we expected. So, since we both work in user-experience design and content strategy, we joked a bit about about the user experience and the quality of the content.

Colleague: 20 minutes later, we have a time and place…. Me: Who says technology fails? There's NO content problem, whatsoever.

Me This entire thread is hilarious. Colleague: Indeed. Me: So, London Design Festival it is.

Next, my colleague recommended I read about the event in the brochure. But she warned me not to use my phone.

Colleague: Check out, on your laptop, this URL. (Location of a PDF file titled "LDF17 Guide AW Digital". Me: On my laptop? Not on my phone? What is this?? Content Failure Night?

Colleague: See page 24. It loads forever. (It's not very digital, imho.) It took 5 minutes to load on my laptop! If you want to tie up your phone data for 30 minutes, be my guest. It's a PDF full of high-resolution images.

I’m sure the paper version of the brochure looked great. The online version was so slow to load, it caused me to stop reading. (Of course, the brochure should have been reconfigured into an online product, rather than published as one PDF of large images. But that  is not the main point of this blog post.)

“Publish and forget” can lead to failure

This experience is a good reminder for me, as a consultant, to ensure my clients don’t just publish and forget. After publishing, I need to help them follow up:

  • After adding data to a third-party tool, such as a restaurant location in Google Maps, schedule a periodic review. And then correct any errors and edit confusing data.
  • After publishing content, such as a brochure, test it on a variety of devices that have different sized screens. Test it on a variety of connections, such as a LAN cable, by Wi-Fi, and by mobile data. Check its compliance with accessibility standards. And then address any issues with speed, layout, or accessibility.
  • After publishing an app, observe people using it, not only to find bugs in the application, but also to find recurring data problems that people have entered in the app. And then figure out how to resolve those problems.

Leave a Reply

Your email address will not be published. Required fields are marked *