Delivering a digital strategy for Parliament – Interview with Rosie Hatton

From the Cherryleaf podcast: The UK Parliament is one of the oldest organisations in the world. So how do you deliver a strategy to a body that has over 700 years of content? Cherryleaf’s Ellis Pratt interviewed Rosie Hatton, Strategy Digital Lead at the Parliamentary Digital Service, to find out.

Topics covered:

  1. What is Parliament? 1’56”
  2. The content Parliament creates. 3’38”
  3. What is the PDS? 5’08”
  4. The I AM PARLIAMENT programme. 9’00”
  5. The PDS’s digital strategy framework, its assumptions and principles. 10’18”
  6. Having an open and agile digital culture in a traditional organisation. 13’08
  7. Working in a continuous interative process. 20’45”
  8. Sharing ideas with the Government Digital Service. 25’24”
  9. Where does the PDS’s content strategy fit within its digital strategy? 28’22”
  10. Tracking the impact of changes to laws on other laws. 37’01”
  11. The similarities between PDS and Open Source software projects. 41’55”
  12. Crowdsourcing a digital strategy. 43’30”
  13. Benefits management. 44’00”
  14. How to manage and sell change. 47’50”

Links:

People:

Is your documentation AI and chatbot ready?

It seems likely Artificial Intelligence (AI) and chatbots will play a key role in helping users, in the future. Amazon, Facebook, Google, IBM and Microsoft, as well as smaller technology companies, are all developing platforms for simulating an intelligent conversation with human users.

This raises a question:

Will chatbots mean we’ll write a how-to task in the chatbot app, again in the Help, and again in the tutorials?

It’s not very productive to write the same content three times, in three different places. It makes even less sense if you need to update the content on a regular basis, or translate that repeated content into multiple languages.

One solution is to store different types of data in its native format until it is needed, and then serve that information to the AI or chatbot system. You write the content once, and “serve” it to the chatbot, the online Help, the tutorial, and so on.

This requires that content to map accurately to the chatbot’s information structure  –  the use cases; the user’s intent, role and sentiment; and the entity (i.e. the problem and product) that relates to the user’s question.

As a technical communicator, this means you can start by making sure your content is in a structured format. For example, it has metadata (and uses a taxonomy) that will help the AI system or chatbot know which piece of information to serve the user. This includes common metadata such as product, symptom, problem, version, user role and operating system. It may also include new metadata relating to responses based on the user’s current mood (“sentiment”),  and the context in which the question is made to the chatbot.

This approach makes it more likely that your documentation will AI and chatbot ready, at the time when it’s needed.


Tryo Labs has published a useful summary of the different approaches and technologies you can use for creating chatbots. See: Building a Chatbot: analysis & limitations of modern platforms.

See also:

Towards content lakes

Cherryleaf’s technical writing services

Just in time documentation – some pros and cons

Bri Hillmer has written two articles on Just-In-Time documentation (https://www.knowledgeowl.com/home/just-in-time-documentation-a-practical-guide and  https://www.knowledgeowl.com/home/just-in-time-documentation). This is an alternative to what she called Just-In-Case documentation. The idea is you write topics that answer real world queries users ask the Support team. This rather than writing a comprehensive user guide, just in case someone wants to know about topic X or topic Y.

This approach focuses on user needs, answering the questions user have. It also provides users with worked examples, each one aimed at solving a particular scenario. In a complex environment, users may need to combine a set of functions or features in order to solve their problems. Sometimes a topic-based approach doesn’t provide that type of information. Just-In-Time documentation could help users understand individual features and how to combine them. And it may be that 80% of the queries relate to 20% of the product’s functionality.

However, this approach does require the technical authoring team to be able to turn around these articles quickly enough. It’s likely that similar topics will come up a regular basis, so there also needs to be a way to reuse some passages of text, in order for the Technical Authors to work in an efficient manner. Also, there might be a legal requirement to provide a comprehensive guide.

Is this an approach you have used? If so, please share your experiences, using the comments box below.

Software companies are not selling boxes anymore

Wistia’s Chris Savage has written an article on how the company focuses on articulating its company vision to differentiate itself in a competitive marketplace.

In the article, he states:

“To buy software back in the day, you’d go to the store, buy a box, and bring it home. Inside of the box would be a shiny CD, which had your new program on it.

You’d install the program on your computer, and then you’d use it for a few years. When the next version came out, maybe you’d get a discount because you bought the previous version. If it had some good upgrades, you’d consider making a purchase.

That’s all changed.

Now when you’re buying software, you’re not getting a static product. You’re buying something that’s continually evolving and changing. At Wistia, like most SaaS companies today, we deploy fixes and improvements multiple times per day.

When we buy software today, we’re not just buying into the current benefits, features, and price. Instead, we’re making a bet on the product’s future.”

Customers expect a continuing relationship with companies. They expect the product to grow, to see an ecosystem to evolve. Interwoven into this, is the support they receive. They expect high quality information when they want to explore how to get more out of the product, or troubleshoot any issues. This means User Assistance, the online Help, must become part of the initial design, and part of the user experience. It can no longer be an afterthought bolted on once the product has been developed.

Protecting your brand using technical communication

Lisa Thomas

On BBC Radio 5 live’s Wake Up to Money programme today, Lisa Thomas, Chief Executive of advertising agency M&C Saatchi, said:

“We can’t just think about just one advert. We have to think about the brand and the relationship that consumers have with that brand, and be aware that consumers see your brand and your product everywhere now.

They can have a very direct relationship with that brand, whether that’s via Social Media, whether that’s via just by being more in more contact with those brands and the business, so there’s more imperative now to think holistically about the brand than before, and be more creative.”

The co-presenter, Mickey Clark, commented that he’d heard from David Kershaw (a director at M&C Saatchi)  that even the through the toughest economic times, companies are anxious still to protect their brands, even if they have next to no money.

Brand means the customer’s expectations of what they will get, or experience, when they use a product or service. Today, organisations have to protect the promise, that expectation, and make sure that promise is matched by what they actually experience.

Organisations that think more holistically, and focus more in terms of brand than simply advertisements and sales orders, need to ensure the brand image is consistent throughout the whole of the customer’s experience with it. In this context, technical communication, the instructional content that supports users as they use the product or service, becomes an important means of protecting the brand.

That’s because, when the customer has left the store, all the packaging has thrown away, and the customer is actually using the product, one of the few things left to sustain the brand’s reputation is technical communication – the User Assistance, the technical documentation. This will help support the user through the periods they spend using of that product or service.

The big questions in technical communication

David Farbey wrote a semi-existentialist post on the challenges for technical communicators yesterday. I’d like to look at the issue in a different way, by looking at the big questions in technical communication today. The answers to these questions (which may be decided by people outside of the profession) are likely to affect the future direction for technical communicators.

Continue reading “The big questions in technical communication”

What does Stack Overflow’s success mean for traditional User Assistance?

Last night, I saw Joel Spolsky speak at a London Enterprise Technology Meetup, held at the London School of Economics. Joel is one of the founders of Stack Overflow, a hugely popular question-and-answer website on the topic of computer programming. He also claimed in a blog post back in April 2000, no-one reads manuals (see our article If no-one reads the manual, then why bother?).

So I asked him about his thoughts on the relationship between question-and-answer sites like Stack Overflow and traditional user documentation.

Continue reading “What does Stack Overflow’s success mean for traditional User Assistance?”