Designing service

kevinbarefoot — Tue, 29 Mar 2011 10:00:00 +0000

Service Design is the activity of planning and organizing people, infrastructure, communication and material components of a service, in order to improve its quality, the interaction between service provider and customers and the customer’s experience.

It appears that service design is gaining traction in many design schools, and even has an international network of academics and professionals.

Three main directions:

Identify the actors involved in defining the services

Define possible service scenarios, verify use cases, sequences of actions and actors’ role, in order to define the requirements for the service and its logical and organisational structure

Represent the service, using techniques that illustrate all the components of the service, including physical elements, interactions, logical links and temporal sequences

Yet unlike traditional design, a service is both tangible and intangible. From the Wikipedia article:

“It can involve artifacts and other things including communication, environment and behaviours. Several authors emphasize that, unlike products, which are created and “exist” before being purchased and used, services come to existence at the same moment they are being provided and used. While a designer can prescribe the exact configuration of a product, s/he cannot prescribe in the same way the result of the interaction between customers and service providers, nor can s/he prescribe the form and characteristics of any emotional value produced by the service.”

Running a successful beta program

kevinbarefoot — Tue, 15 Mar 2011 15:03:00 +0000

Yes, there are many types of software betas. In fact, Saeed Khan claims that delivering a successful beta program is one of the hardest things for a product manager to do. Why? Because so much is out of the hands of the PM and dependent on the engagement of the beta testers. So he has created a very thorough document on beta planning to help bring as much predictability as possible: Building a Better Beta.

Some key findings:

Recruiting is the most critical aspect of the beta program – get the wrong sites, wrong mix, not enough, and you are unlikely to meet the program goals
Usage: expect only 50 per cent of your beta sites will actually install and use the tool, and only 25 per cent will provide meaningful feedback (Joel Spolsky estimates 20%).
So that your sites aren’t just ‘playing around’ with the tool, provide them with example beta test scenarios based on expected product usage.
Evaluate beta product readiness by tracking usability, performance, installation, and upgrade path separately with their own criteria and requirements; simply tracking all open bugs and their severity leads to potentially arbitrary decisions about you are ready.

The paper also notes that betas need to involve the entire organization. Dave Daniels identifies that this helps answer key questions for beta program: Is the product positioning and messaging correct? Are your delivery and support teams ready?

Drastically reducing the number of screen captures in a document

kevinbarefoot — Sat, 05 Mar 2011 09:26:26 +0000

In my experience translation vendors charge per screen capture translated. One way I’ve found to drastically reduce the number of screen captures in some of my documents (and therefore the cost) is to take one screen capture of the entire desktop with several dialog boxes open, and then use this capture throughout the document, cropped to display only the section or dialog box in question.

Managing Online Forums

kevinbarefoot — Sun, 18 Apr 2010 07:24:09 +0000

In reading Patrick O’Keefe’s Managing Online Forums, the most significant lesson seems to be that starting an online community is a significant endeavour (there’s a long chapter on “Banning Users and Dealing with Chaos”). Another significant lesson seems to lie in the fact that the “Making Money” chapter is very short. If neither of these lessons are a deterrent, the book is a good survey of important considerations when creating a community, and has a few insights into the area of motivating users to contribute (“user promotion,” “member of the month,” “awards programs”). Like many real-life constructed communities, in my experience, online communities can start with a fury of activity and attention, and then slowly dwindle, and usually the path of least effort is going where your users already gather (Facebook, Linkedin, etc). But if you have the resolve to create your own, this book is a good reference.

Should you do the screenshots internally or rely on a vendor?

kevinbarefoot — Mon, 15 Mar 2010 00:41:34 +0000

Speaking of software localisations, one of the pain points in the process is capturing localized images of the software (dialog boxes, menus, etc) for use in the documentation. To capture these screens, you first must have the user interface text strings localised into a number of non-native languages, and then incorporate these new languages in the software. Then ‘someone’ must go through the documentation and capture screens of the software in each of the languages. It is often assumed that the someone should be a member of the development team that built the software; but this isn’t always the case. Localisation vendors offer this service if you can provide them with the software and a script for creating the correct scenarios. The decision, of course, should be based on economics. Here are a few things that feed into the costs.

Can a build of the software be easily installed at the translation vendor?
If it takes day to install and configure your software appropriately for capturing screens with dongles, license keys, etc, you’d better quantify this cost.
Is it easy to change languages in the software?
Typically the answer is yes, but if No this could be costly with a vendor doing the work.
Does the software need a localized operating system to display the translated user interface correctly?
Often Asian languages don’t display properly in software that isn’t running under a localized operating system. In my experience, most development teams don’t run localized operating systems for viewing and testing translations.
Can you create a simple script and provide sample files to produce the desired results?
A translation vendor needs a script and sample files so they can properly capture the screens. It takes time to create this. Estimate how much and calculate the cost.
Who will capture the screens on your development team?
Typically this will be a technical writer, tester, or developer. Calculate the cost of their time.

As you might have already guessed, keeping screen captures in documentation to an absolute minimum will have a significant effect on your translation costs.

Managing technical support via social media channels

kevinbarefoot — Wed, 03 Mar 2010 14:33:52 +0000

I had an information interview with a colleague at a local software company the other day to discuss managing social media channels for technical support. When we first setup the meeting, he wrote me about a ‘channel management problem’:

“We used to put all of our documentation in user guides for each
product. FAQs and troubleshooting guides would be included in these
and updated with each release. If a user had a problem they would
contact us via email for support.”

“Now we have several channels for support and documentation. People can still consult the product documentation, but will often find other useful information (some not covered in the product user guide) in online forums, blog posts, wikis, email lists etc.”

“We’re now finding a lot of people asking for support (indirectly) in
blog posts, blog comments and tweets. This is really hard to manage.”

“For example, we constantly monitor Twitter for @company messages and tweets that mention us or our products. Once or twice a day we’ll find that someone has asked a question about one of our products or complained about it. This can difficult because the answer may be too lengthy for a tweet, or too awkward (e.g. a bug has been found) to respond to publicly. For those cases, we try to direct the tweeter to our product forums or email support.”

When we met, he mentioned that they’ve recently started using a twitter productivity tool that helps them manage tweets from various users at the company. But some challenges remain:

How do you respond to tweets in other languages?

How do you use a URL shortener (like bit.ly) to track traffic to a support resource?

Is it useful to monitor traffic from social media channels separately?

Is it worthwhile to implement a redditt/digg mechanisim on the support portal to get crowds to identify popular support posts?

What do analytics reveal about documentation usage on the support site?

I’ve certainly used web analytics software on support sites to get a general sense of what topics/areas of the product are causing issues. And capturing most popular search terms can certainly tell you where users struggle.

Four reasons you shouldn’t rely on developers to localise

kevinbarefoot — Wed, 03 Mar 2010 00:29:12 +0000

For most software product managers I know, localisation can be a four-letter word. Localisation is the process of adapting software for non-native environments, usually other nations and cultures. Localisations take a long time and require significant development effort, but they are usually necessary if you want to sell into foreign language-speaking markets. Typically the localisations are of the software user interface, and the documentation and training materials.

While working in product development, I occasionally hear the suggestion that we can have one of the developers or field engineers that speaks the local language localise the product. Although this seems like an efficient solution, there are many reasons to avoid it; here are a few:

Inconsistencies. Localisation vendors use a database, called a Translation Memory (TM). If you don’t have an existing TM, the localization is likely to be inconsistant. If you do have an existing TM, the developer wouldn’t likely have access, which requires the purchase of a license, their translation may be inconsistent with what already exists. Also if your company does have an existing TM, there is a cost to update the TM with the internal localisation.
Overhead of coordinating internal localisation. Most people with experience know that this is a non-trivial task; the localisations need to be reviewed and corrected, and this all takes time.
Opportunity cost of paying engineers to localise rather than code.
Lack of local knowledge. The developer may not be familiar with regional variations/style.

If you are only looking at a few sentences and are in a screaming hurry, localising internally and then updating the TM is an option, but for the reasons outlined above, you may find it’s less efficient than planned.

Listening and engagement through social media

kevinbarefoot — Fri, 26 Feb 2010 09:09:37 +0000

Brian Solis’s ebook on customer service provides some good examples of organizations using social media to reach out for customer service.

From the book:
“You can bet that for every inbound customer inquiry, that there is a significant  percentage of existing and potential customers actively discussing the same  topic out in the open, simply looking for guidance, feedback, acknowledgment,  and/or information. And usually, these discussions transpire without company  participation, leaving people to resolve issues and questions on their own.”

Some organizations mentioned: Southwest, Freshbooks, ACDSee

A blog bio in five sentences

kevinbarefoot — Wed, 17 Feb 2010 10:00:06 +0000

I’ve recently been rewriting some blog bios and wanted to capture key points to include. It’s generally good to have a bio of varying lengths (one sentence, 100 words, 250 words, etc). Numbers 1 and 5 below are required and can be squeezed into one sentence if necessary.

The first sentence should include your name and clarify what you do, and for whom (your audience).
“My name is Kevin Barefoot, and I am a technical writer and product support manager who operates Barefoot Consulting, a freelance business that helps Vancouver-area software companies plan and manage documentation and support.”
The second sentence should indicate key professional achievements (including awards, degrees, memberships)
“I hold a degree in writing from the University of Victoria, and for the past ten years have worked at Creo and then Kodak as a technical writer and product support manager where I ensured that software products met business goals by managing service through the stages of alpha, beta, and production.”
The third sentence should indicate what differentiates you from the competition.
“I have spent significant time learning from and helping end-users, and defining an overall support plan covering areas such as: service risks, tools, and profitability; beta programs; end of life or migration; documentation; training; translations; call reporting; and maintenance requirements.”
The fourth sentence should indicate what you are working on now, or interesting side projects.
“Lately I’ve become interested in using social media tools to deliver service and support.”
The fifth sentence should include your contact information.
“You can reach me at kevin dot barefoot at gmail dot com or @kbarefoot.”

Customers as the Service

kevinbarefoot — Thu, 11 Feb 2010 16:31:39 +0000

The goal of customer experience management (CEM) is to move customers from satisfied to loyal and then from loyal to advocate. When you match customer advocacy with a social media channel such as an online community, you can end up with the customer as the service, where advocates answer questions and provide solutions to other customers’ issues. As noted in Shel Israel’s post about the SAP mentors initiative: “When customers defend a company, it has greater influence than anything a company spokesperson could hope to accomplish.” This can definitely relive some of the burden on your technical support team, but they’ll still need to listen to the conversation, even if they don’t always participate.