ARM Technical Publications is part of the Services Division of ARM that provides product support and training for our customers.
In 2010, ARM contracted Mekon Limited to conduct a content strategy audit on our customer-facing documentation deliverables. They reported on the following:
- Document management
- Document creation
- Document review process
- Document delivery
- Information reuse
We supplied Mekon with a number of documents from different areas of the business. They interviewed some members of our Technical Publications team and a number of Engineers.
Mekon reported back to the Technical Publications team in July 2010. Unsurprisingly, they found room for improvement in our documentation. Their overarching recommendation was to introduce a DITA-based authoring environment and a content management system.
We were satisfied with these recommendations because they confirmed the strategy that we had been working towards for almost 18 months. It was gratifying to see our business plan and views endorsed by a third party.
Surprisingly, Mekon recommended a series of user and task analysis interviews with our customers to discover how they use our documentation. I had never made direct customer contact in my eleven years with ARM, so this was something of a revelation. Mekon advised that we conduct the analysis interviews in collaboration with an external consultancy.
Peter Jones, then a Technical Publications Team Lead, now our Information Architect, got in contact with our sales team to facilitate a series of customer meetings. Peter and I conducted these meetings together where possible so that one could take notes and the other could interview without distraction. We valued the opportunity to meet interviewees in person to form the basis of a good working relationship.
ARM has a very positive attitude to any form of customer contact and prioritises travel for this purpose. Our divisional VP, very supportive of our migration to DITA, approved and funded our travel plans.
Why Would We Want to Talk to Our Customers?
The information sources for the content strategy audit report were internal but we decided to confirm all or some of the recommended changes with our customers.
We wanted to involve our customers in our migration to a DITA environment. We have found that our audience tends towards the conservative when it comes to change. Many of them have worked with us as partners for many years and have a definite expectation about the quality of our content and where to find it. Providing an opportunity for them to help implement that change and improve our output was irresistible.
We didn’t know how our audience used our content:
- Did they require Reference information?
- What about Tasks?
- What Concepts did they need?
- How often did they use information?
- Were they interested in receiving information on-line?
Why Would Our Customers Want to Talk to Us?
Our customers wanted to be involved in the change. Feedback indicated that past modifications had not been as well received as we had hoped. They often asked us why we had changed the content, structure, or location of information in the documentation. Effective change management and consultation necessitated involving customers closely with future improvements that our replacement system and processes would provide.
The content strategy audit had reported that the structure and content in some of our documentation could be improved.
We have two audience groups:
- Established customers (partners) who collaborate with us to develop products. Their product knowledge is often as good as ours and their documentation requirements are fairly well covered.
- Less experienced customers who require detailed information about how to use our products. This group has different needs, and we wanted to investigate those as part of this activity.
Peter and I found ourselves in the fast-moving world of sales and the even faster-moving world of the sales organization. It is a dynamic world of ever-changing schedules and requirements. Sales Managers are supported by Field Applications Engineers who provide close technical support to help complete a deal. These engineers form a relationship with the customer engineering groups. They were invaluable in helping arrange and, as chaperones, conduct the interviews.
We found that our usual methods of communication were inefficient. In this sales-driven and customer-focused environment, last minute cancellations and changing schedules are common. Urgent sales opportunities and customer technical issues rightly take priority.
It often felt as though we were involved in a game of chance. Arrangements were quite often left to a single day’s notice. In a couple of instances, there were no firm arrangements until a couple of hours before the actual meeting. Despite these pressures, our colleagues successfully organized meetings, transport, and meals.
We soon learned that the best strategy was to be flexible and adapt to these constantly-changing circumstances.
We had been provided with a script for the interviews. It consisted of a list of 23 questions. Responses would form the basis of their report. A consultant conducted the interviews, whilst Peter and I took notes.
Our preference was to conduct interviews face-to-face whenever possible. There is no substitute for personal contact as an effective method of communication. We also wanted to build a relationship with our audience. There were a couple of occasions when we didn’t achieve this, and I feel that the quality of the interview suffered as a result.
The collaborative nature of the interviews was extremely important. Creating an environment where customer engineering groups and managers, ARM Field Applications Engineers, ARM Sales Managers, and the consultant could converse with Peter and me in a mutually understandable language was no mean feat.
There were a couple of times that we did not manage to meet our interviewees face-to-face. Though unintentional, this situation was difficult for our consultant. A combination of prior commitments and late notifications from us meant that he could not attend interviews in person. There were a few occasions that he dialled in to conduct the interview from hotels and airports.
Peter and I spent almost three months traveling across time zones at irregular intervals. Sometimes there was a 12 hour difference, sometimes only one hour. The result was that we were constantly tired and jet-lagged. I do not envy the professional traveler. International time zones were also an issue for the consultant. He had to dial in for some interviews at awful hours in the early morning or late evening.
The sessions were planned to last around two hours. Some of them exceeded four hours. On a couple of occasions, the interviewees left the meeting after responding to our questions and called in reinforcements for a second session. One reason for the meetings overrunning was that we had not anticipated the extra time that cultural and language differences would consume. For example, in Asia it was common for the interviewees to huddle and have intense discussions before presenting a group response. The interaction between our ARM chaperones and the customers was excellent. They provided explanation and translation so that all parties had a good understanding of the discussion topics.
Our local ARM colleagues provided invaluable advice about national culture, and we supplemented it with our own web research. For example, the manner in which you exchange business cards is significant in Asia, but in the West it is usually a casual part of the introductory handshake. A conservative business suit and tie are expected in Japan, but in India, China, and the USA, a smart jacket, open-neck shirt, and slacks are acceptable. In all cases, we asked for and received good advice from our ARM chaperones prior to the visit.
What We Learned
Customers see you as part of the company that you represent. They make no distinction between Sales, Product Marketing, Legal, Product Delivery, Engineering, or any other department. Sometimes they wanted to talk about ARM. We then made sure that we delivered feedback along with relevant background information and, if appropriate, contact information. Not all feedback was negative, and we were pleased to pass on praise to our colleagues.
At ARM, we have an internal policy that we do not duplicate content across books. This policy has obvious advantages to help us avoid providing contradictory information and easing the maintenance burden but it presents our audience with a fragmented view of product documentation. Another issue is the sheer amount of similar content we provide. It is difficult to find information when there’s so much to search through.
What Does Our Audience Really Want?
Our audience wants more pictures. Some nationalities have a real cultural need for pictures. For example, Japanese restaurant menu choices are accompanied by a photograph or drawing. Most street direction signs in Japan are accompanied by a graphic representation of the destination.
Our audience does not want to waste time looking for information. Time is money. They live in a dynamic environment with very short design cycles. Leading-edge products have a current shelf life of around 18 months. This life cycle puts the semiconductor industry under tremendous pressure to create and deliver innovative high-quality products in a very short time.
What have we learned about talking to customers? In summary, plan the engagements with customers as thoroughly as possible and be prepared to change the plan at the last moment. Listen carefully to what customers say and resist the temptation to try and fix things on the spot. Use expert consultants to help you with the engagement.
How are we following through on the findings from our customer research? As part of the post-support procedure, we participate in a customer survey. There is a question about document satisfaction. Approximately 5 percent of responses are from dissatisfied customers. We get in contact if a customer states that they are dissatisfied and wish to discuss their concerns. We stay in contact until the issue is resolved. We investigate possible enhancements if the dissatisfied customer does not wish to discuss the issue.
We react quickly to errata when customers raise them. The issue is checked by an Applications Engineer who raises a support case. The issue, if appropriate, is recorded as a defect or enhancement request against the document for resolution as part of the next update. The customer who raised the errata is always thanked.
In collaboration with our product marketing teams, we are redefining the delivery and format of source files with some of our customers.
We are working with a cross-divisional team to standardize ARM deliverables including our documentation.
While our customers rely heavily on our reference material, they also need the related task descriptions that support their designs and workflows, and the conceptual information that binds this content together. They need all this information in a coherent form that they can easily navigate, written in a way they can understand, and delivered so that they can use it not only on their desktop terminals but also on paper for annotation.
About the Authors:
Ian Ampleford is a Scottish ex-paper delivery boy, ex-milk delivery boy, ex-bread delivery youth, ex-electronic engineer, ex-tank commander, and ex-data manager who went into technical writing for the excitement and lifestyle. He is currently the Director of Technical Communications for ARM Limited where he manages a global team of 50+ authors and supporting staff.
Peter Jones joined the Technical Publications Department at ARM in 2002 where he evolved from Author to Principal Author and then Team Lead. Peter is ARM’s Information Architect. He works on the deployment of DITA within the Technical Publications teams. Peter is a Chartered Engineer, holds a Masters Degree in Technical Authorship, and is a Fellow of the Institute of Scientific and Technical Communicators.