Sunday, 9 August 2009

More blog posts on my main site

The Blockhead Blog is now incorporated in my main site. New articles will appear there, and I look forward to reading your comments.

Tuesday, 28 July 2009

Moving right along

I'm not the sort of person who jumps on every new bandwagon that comes along. No, I wait for them to pass me by and then run like mad to catch up. Many other technical writers started blogging long before I did, I was a relatively late arrival on the Twitter scene.
This week I have started to catch up with the blogging phenomenon known as WordPress. I was originally a bit put off by the need to set up a database on my website, but my hosting provider, made that bit really easy.
Installing WordPress itself was also very easy, though I did have a good friend standing by to help me out. It was certainly much less hassle than setting up Windows 7.
You can visit my new site at my regular web address, even though it is still very much a work in progress. If you're feeling sentimental, or if you're looking for material that I haven't ported over to the new site yet, you can still visit the old site. I have started posting blog articles on the new site, and in due course the Blockhead Blog itself will be incorporated in the new site.

Friday, 24 July 2009

First steps with Windows 7

For a variety of reasons, I operate as a business, and for a variety of other reasons, my business is a member of the Microsoft Partner programme. That shouldn't really surprise anyone, despite my frequent criticisms of Microsoft and its products over the years. The fact is that I, like most people involved in hi-tech, continue to use Microsoft products every day, as do the overwhelming majority of my business clients.

One of the advantages of being a Microsoft Partner, is early access to forthcoming products, which is why I have a copy of Windows 7 before its general release. This blog article follows my first steps with Windows 7.

Microsoft: "download now"
What I did: quite late in the evening, I followed the steps to install the download manager, and then started the download and went off to watch TV. 4 hours and 2.5GB later, I had the Windows 7 Release Candidate .iso file. (The download steps do include getting a product key.) Next day, I burnt the .iso to a DVD.

Microsoft: "use a dedicated test PC"
What I did: found an 80GB hard drive I didn't need, and installed it in my PC. I set the disk up with Win XP. Then I loaded the Windows 7 DVD.

The installation took about 30 minutes, during which the machine rebooted itself 3 or 4 times. There is an option to set up Windows 7 as a dual boot, but I didn't choose this, I created a completely new clean install.

First impressions:
The visual appearance is very much like Vista, with a rather odd background graphic with a strange blue fish. I wonder who chose that?

First problem:
Windows 7 didn't automatically recognise my wireless networking PCI card. I installed the drivers for the card from the original CD. I still found the Networking dialog a bit confusing, and I still couldn't use it to connect. However I did connect using the wireless card's own software utility, and happily found my way to the Internet. Hurrah! But the Windows 7 Networking dialog still didn't recognise that I was connected.

When I installed the wireless card software I was prompted to approve the action, Vista-style. I wonder how often this is going to happen.

I have now gone back to my Win XP PC to get work done today, and I'll continue my experiments with Windows 7 over the weekend.

Tuesday, 23 June 2009

STC Action Plan

My earlier post on the STC looked at the problems, but didn't address what the Society should do now about its financial crisis. Some people have asked me what I think the Society should do about raising money. Some of the ideas I've seen, like imposing a levy on members, looked crazy to me, so I thought I'd offer a few of my own, which might not be quite so crazy.

  • Announce today that dues for the next membership year (2010) are going up by 25%-30% for all categories.

  • Offer members who renew for 2010 before 1st November 2009 a big discount on next year's rates.

  • Ask any local Chapters with excess cash in their bank accounts to lend money to the Society as an interest-free, standing loan, which the Society will repay when it can (which may of course be never).

Those are my ideas on finance. But my main idea on STC's dwindling value proposition remains the same. The Board urgently needs to address the key question that every individual member is asking themselves:

  • What can STC give me that I can't get cheaper, or for free, somewhere else?

Sunday, 21 June 2009

Does the STC deserve to survive?

The Society for Technical Communications (STC) is a membership organisation for technical writers and related professionals. It is more than 50 years old, and has been in decline for some years. The rate of decline has now become precipitous, and the economic situation of the last year has added a financial dimension to the STC's ongoing crisis. The Society's leadership has reacted to the financial crisis by inviting suggestions for action from members.

I have been an active member of the STC for more than a dozen years. I have served on the managing bodies of both the Israel Chapter and the UK and Ireland Chapter, where I have served as President and as Treasurer. I am now Co-Manager of the Europe SIG and serve also on a number of Society-level committees. In the past I have been a loyal supporter, and have advocated STC membership for many reasons:

  • STC membership puts you in touch with an international community of tech comms professionals, most of whose members are in the United States

  • STC membership provides you with a peer-reviewed quarterly academic journal

  • STC membership provides you with a regular magazine of interest to tech comms professionals

  • STC membership gives you heavily discounted access to conferences (mainly in the USA)and Webinars

...and so on. This has been STC's "value proposition" - the things that it provides that its members value enough to pay money for.

Recently, I have begun to feel that there is not much value left in STC as it stands today, and it is in need of a radical overhaul in order to survive. I believe that outside the rarefied atmosphere of the STC Board and Head Office, this view is widely shared.

The elected leadership has now invited suggestions on solving the financial crisis. Most of the member suggestions I have seen are about reviewing or changing the Society's core activities, not about saving costs or generating revenue. To me this is an indication of a dangerous disconnect between the deliberations of the elected Board on the one hand, and the concerns of the membership at large on the other. Do Board members not realise that the financial crisis is just an acute symptom of an underlying chronic condition, which is the decline of the Society? One Board member at least has acknowledged the breadth of the problem. Mike Hughes has written that he probably would not recognise proposals to make STC appealing to a new generation of professionals.

Elsewhere, Sarah O'Keefe has summarised the STC's ills by writing that it lacks "velocity", "community", and "openness". This contrasts with the official statements from the STC Board, which imply that all the Society needs now is more money.

In another blog, Keith Anderson suggests that a core problem of STC is that it tries to cater for too many interests, including those of academics and those of professionals. As a professional who is also a part-time academic, I would have to agree that this is problematic, and the result is that STC fails to serve either community adequately.

Many people are contributing to an open debate on Twitter, sending suggestions with the hashtag #stcorg . I have contributed several myself, some of which are expressions of my frustration as a community leader. Here are the ideas I posted to Twitter:

  • embrace the social media technology we champion as professionals

  • provide affordable branded training courses at all levels of the profession

  • provide pro-active support for volunteer local leadership

  • provide excellent service to individual members and local volunteers when they call the office on any topic

  • remember we are a non-profit membership org that needs business-like management, but we are not a business

The unstoppable Tom Johnson has a more detailed list of even more practical suggestions.

As an active and loyal STC member, I have been saddened by the conclusion I have now reached. If STC fails, I don't believe that anything irreplaceable will be lost. Local groups may or may not continue, meeting in person or on the web. The social media tools available now at low cost or no cost make community-building on the Internet almost childishly simple, and show STC to be behind the times. Techcomm bloggers and pundits will continue to write and self-publish articles, while STC publications recycle blog articles that have been in circulation for months. Some conferences will still take place. Outside the USA, other national techcom societies will certainly continue (and within the USA other societies exist as well).

So to answer my own question, does STC deserve to survive: if it can join the current communications game of blogs and wikis rather than email and print; if it can slash its overheads and extricate itself from damaging contractual commitments; if it can establish the kind of zero-based budgeting that it wants to impose on its local communities, and if above all it can make itself relevant and vital to the profession in the 21st century, then of course it should survive. The articles from Tom and Sarah and Keith mentioned above have plenty of suggestions about what could be done to achieve these goals, and I am more than willing to contribute constructive ideas for a revitalised STC, and to continue to commit my energies to them. What we need from the Board is inspiration to achieve them.

But if all the Board wants is more of my money, then I'm afraid I'll be giving a different answer.

Friday, 12 June 2009

Limits of community support

One of the trends I mentioned during the meeting in Vienna this week was the growing importance of user generated content.

User generated content can mean many things, but in the context of commercial products and services it generally means allowing users and customers to add comment to your company's web site through open wikis, blogs, or user forums. Some companies encourage their own staff to engage with their customers by responding to forum comments and questions, by writing blogs and inviting comments, and so on. Other companies are happy to let the users - the customers - get on with things by themselves, without interference from the company. They even deliberately use the term "user community" or even "community support" to encourage their customers to take part.

On the other hand, there are some serious objections to user generated content. Many companies believe that any information published about their products needs to be authoritative and reliable. For example, if you are manufacturing electrical equipment you need to give your users accurate information about the correct voltage for your products. If you leave this sort of thing to others, you might be opening yourself up to legal challenges, and more importantly, people could even get hurt.

Nevertheless, there are independent, user-run forums for many products, as well as company-sponsored ones. An ongoing research project sponsored by STC has found that independent user forums are more popular, and more trusted, than vendor sponsored ones. Perhaps you don't find that fact surprising. After all, the Internet was all about sharing information amongst peers long before the commercialisation of the World Wide Web, and many people feel strongly about the freedom of information.

Something happened to me this week which made me recognise a limitation of community support. I often use Huddle, an online collaboration platform, to share documents with clients and colleagues. My use of Huddle is quite low volume, and so I only use a free account, which means I don't have direct access to Huddle's tech support. This is reserved for paying customers, and I quite understand that distinction. Although this little anecdote may sound critical of Huddle, I think it is a great product, very easy to use, and definitely worth evaluating if you are looking for an online collaboration tool.

This week, I wanted to share a rather long document with a client. It was much too big for email, so I uploaded it to my workspace on Huddle, and tried to invite the client to join the workspace. Inviting people is a very standard action, something I'd done without a problem many times before. This time I could see that something was broken. Clicking the Send Invitation button got no response, and instead I saw a line of code in my browser's status bar. I have been around software long enough to recognise a bug when I see one, and I wanted to report this to Huddle.

When I went to the Support page, I found that as a free account customer the only option open to me was to post a message to the community forum. I found that someone else had encountered exactly the same problem, and had posted a message to the forum some six hours before, but there had been no response. I added a "me too" comment, and waited.

Community forums are really great for how-to information, and for tips and tricks, but communities can't fix software bugs, not even the most trivial ones. I hoped that the messages posted to the forum would alert Huddle to the problem, and that they would look into it.

After waiting a few more hours, I decided to turn to another sort of community to see if i could attract Huddle's attention. A message on Twitter, with the tag #huddle, got three friendly and helpful responses from the company very quickly, and I am pleased to report that the problem I experienced was soon resolved. (It may even have been one of those minor bugs that resolves itself when something else happens on the server, I don't really know.)

It was unfortunate that Huddle hadn't provided a Report a problem link for its free account customers, and I have suggested that they should consider doing so. I am certainly going to continue using Huddle, and continue following Huddle staffers on Twitter as well.

Thursday, 11 June 2009

Notes from Vienna

Let me put your minds at rest - despite the possible pun in the title, this is not a posting about Mozart. (I leave that sort of musing to my STC colleague Tom Johnson.)

Tom and I have both been in Vienna this week for the 10th Anniversary Conference of the STC TransAlpine Chapter. Tom gave a workshop on WordPress, and two other sessions, while I gave my talk on ignoring users (I'm against it, by the way) and took part in a panel discussion about trends in technical communication. These prosaic and unmusical notes are about the conference themes and that discussion of trends.

Most of the conference was about the basic challenges that technical communicators face. We talked about getting messages across to users, improving the documentation we create, and trying to improve the product we write about. I was very impressed by the lively discussions from the audience, and the spirit of collaboration and participation at all the sessions I attended. The feedback I received to my own presentation was particularly valuable, and I hope my next audience (at Technical Communications UK 2009) will benefit from some of the ideas my audience in Vienna suggested.

The panel on trends in technical communications covered a wide range of issues. We talked about the impact of the world-wide economic slowdown on job prospects for technical communicators, and the need to keep our skill-sets up-to date as part of our response to this. We talked about the continuing need to demonstrate value to our employers and our clients. We talked about the challenges and opportunities to technical communicators presented on the one hand by the growing adoption of structured authoring techniques such as XML and DITA, and on the other hand by the growing importance of user-generated content through blogs, wikis, and discussion forums open to customers and the public at large. Despite not being able to provide definitive answers, I hope the panel discussion highlighted areas of interest to watch in the coming months.

As is usual, the social aspects of the conference were important too. It was also a great event for meeting other professionals, with delegates from a dozen countries. I enjoyed being introduced to the sights and sounds, and to the tastes, of a new city, and I really enjoyed a very worthwhile trip. My thanks to all the organising committee for inviting me.

Tuesday, 19 May 2009

Tech writers are special

Occupational classification is a matter governed by national statistical bodies in different countries and is the subject of international agreements. Getting anything changed can be a long and hard struggle, as various different bodies need to agree.

The STC has made some progress in the United States on the question of professional recognition for technical writers. After several years of negotiation with the Bureau of Labor Statistics, STC has persuaded them to accept that what technical writers do is different from what other kinds of writers may do. According to a recent press release, the next edition of the Occupational Outlook and Handbook will include a separate report on technical writers.

This is good news, as it sets a precedent that may eventually be followed by the UK's occupational classification scheme, which still lists technical writers alongside "artists".

Wednesday, 29 April 2009

Losing your audience before you begin

I am always telling software developers and project engineers that the people who use their products and software are not replicas of themselves - they have different expectations, different motivations and intentions, and completely different levels of knowledge about the product. Part of the contribution that technical writers is opening up the field of knowledge about a product by creating user guides and help systems that are clearly written and easy to understand.

But are we as writers in danger of falling into the same trap? Do we always remember that the people using the user guides and help systems are not replicas of us either? For example, do we bear in mind that some of those users may have sight or hearing difficulties? We could be losing a large proportion of our audience before we even begin.

That's why meetings like the STC UK and Ireland Chapter's Accessibility in Technical Communication and the Workplace event on 13th-14th June is so important. It's a chance to learn how disabilities can affect people and what we can do to make our work more accessible to everyone.

I understand that places for this event are limited, so make sure you book soon.

Wednesday, 15 April 2009

Down with (stupid) grammar rules

I am just popping my head above the parapet of a thankfully heavy workload to raise a small cheer on the 50th anniversary of the publication of "The Elements of Style". This little book by William Strunk and E.B. White, has been a very influential guide to English grammar since its publication, much beloved of American college students (or at least, much beloved of their instructors).

However, I am not cheering for Strunk and White and their famous little book. Rather I am cheering for Geoffrey Pullum, Professor of Linguistics and English Language at the University of Edinburgh. In his article 50 Years of Stupid Grammar Advice, Pullum points out that neither author was an expert in grammar and that their book gave incorrect examples and ignored its own advice. Pullum recognises that their advice on writing style is bland and "mostly harmless" but complains that their strictures on grammar were generally incorrect and unjustified.

Before I became a technical writer I studied English and learned enough to understand that language is not fixed, but is continually changing and developing. Knowledge of good grammar helps readers understand written text, and helps writers - particularly technical writers - construct prose that is clear and unambiguous. Inflexible rules, of the kind advocated - but not always followed - by Strunk and White can obscure and obfuscate rather than clarify. We need to recognise that we only serve our readers when we write prose they can understand. If we need to "bend the rules" then perhaps the rules we were taught aren't right any more.

Sunday, 22 March 2009

An apology to developers

I've been told that my earlier post on The best place for technical writers was critical of developers. I appeared to be suggesting that they weren't interested in customers, or in the "customer experience" around their product.

One correspondent wrote:
I read your article, David, and I'd have to disagree. In fact, your article came off as a bit... angry. Evidently you've had some frustration with developers as of late, because implying that they only care about customers as far as their paycheck takes them is just insulting.... of the "pure" developers I've worked with over the years, all of them were just as interested in a positive user experience as anyone, just in a different way. Developers are very left brained - they understand code, they read code, they talk code. They want the customers to use their code, and have no problems - no errors, no lag, no conflicts between systems. In this way, they hope to produce the perfect user experience...

If that's how people, particularly developers, read my blog, I apologise. What I actually wrote was this:
Marketing are interested in pre-sales - getting new customers in. Customer services are interested in post-sales - keeping existing customers happy. Development are interested in engineering and in code. Did you notice the subtle difference there? Development aren't really interested in customers. Of course, in general terms they want the company to have customers because they know that's where the money to pay their salaries comes from, but their day-to-day focus is not on customers. The tech writers' focus is on customers, or at least it should be.

I wasn't writing about individuals, I was writing about departments. I admit I was a bit casual in my use of prepositions, referring to "development" (a department) as "they" (implying a bunch of people), but I think that can be forgiven in a blog. I am sure that there are many individual developers who care deeply about the product users and the user experience, and I have had the pleasure of working with many of them. It's just that in my experience of a wide range of enterprises, it is often the case that the prime focus of the development department as a department is not on building customer (or user) satisfaction. Therefore I have found, and again this is my experience, that the technical writer can feel like an outsider in that department.

Another of my correspondents was passionate that the best place for tech writers was in the development team:
Most [tech] writers have to fight like hell to get onto a development team simply because their management doesn't see them making a positive contribution. If a capable TW does manage to get onto a team and does manage to make a significant contribution, it builds the profession....I believe too often we aren't willing to be aggressive enough in trying to make our little box larger.

I have a good deal of sympathy with this view. It is often the case that if a tech writer is outside the development group there is no chance of them learning enough about the product to be able to do their job, so being part of development is a great step forward. But I'd like tech writers to be aware of the way their work focus needs to differ from that of their developer colleagues.

Saturday, 21 March 2009

Back to basics: talk to your users

Yesterday I gave a presentation at the STC France Chapter Conference in Paris in which I presented evidence suggesting that, on the whole, we (technical writers in general) are not very successful in our jobs: many people still find technical manuals confusing. The evidence comes from my recent survey and other sources. I suggested that we need to get back to basics, and do our very best to talk to our users, as the leading lights in our profession have been telling us to do for years. (If you missed me in Paris, you might want to catch up with me in Greenwich, or in Vienna, where I'll be giving repeat performances.)

Today, Scott Adams had a go at interface designers in his Dilbert comic strip. So when it comes to not being very successful in our jobs, we are not alone.

Friday, 27 February 2009

The best place for a tech writer

I have spent most of my tech writing career working with product development teams in software and other hi-tech industries. It is what I enjoy doing. It's what I do best. And I have come to the conclusion that it's not the best place to be.

That conclusion may surprise other tech writers, and it did surprise me a little as well. Usually the discussions are about whether the tech writers should report to marketing, or to customer services, or to development. The general consensus is that being part of the development team is best because daily contact with engineers and developers helps tech writers understand the product features they need to explain. It's also a good place to be because the end-user documentation, like the product itself, is usually seen as a deliverable item.

Let's look at this question from a slightly different angle. Where do shared interests lie? Marketing are interested in pre-sales - getting new customers in. Customer services are interested in post-sales - keeping existing customers happy. Development are interested in engineering and in code.

Did you notice the subtle difference there? Development aren't really interested in customers. Of course, in general terms they want the company to have customers because they know that's where the money to pay their salaries comes from, but their day-to-day focus is not on customers. The tech writers' focus is on customers, or at least it should be. That's why we share so much affinity with usability and user experience people, and with training people. That's why we try to write end-user documentation that is about tasks people have to do, rather than about features the product can offer. That's why we don't really fit in to a development team.

Where would the ideal place for tech writers be? I'd say that we are part of the team that looks at customer needs and how they are met. That would be a team with a slightly wider viewpoint than the development team, and I would call them the product management team. (I know that "product management" in many organisations is a marketing function.) Product management would have the responsibility for delivering useful tools to customers, and those tools include products, task-based documentation, training, and support. Where this kind of product management team doesn't exist sticking around the development team is clearly the preferred option, but I'd say it's not ideal.

Sunday, 1 February 2009

Different kinds of technology company

Technical writing is all about explaining technology to people who need to use it. What users need to know is often very different from what the designers of the technology think the users need to know. That means the job of the technical writer is to filter the available information, and present what's useful in the most effective way.

As a self-employed technical writer I typically work with a company for a few months, and then move on to my next client company. This means I have the opportunity to work with a broad range of companies in various industry segments, all of which are involved in some way or other with technology. In my professional career I've noticed two contrasting approaches to technical writing, and I think that these approaches are typical of two different kinds of company (or of different teams or departments within a company).

The first type of company I'd call the "pure technology" company, and it's usually quite small, and often at an early stage in its development. The inventor of the company's core product is still the CEO, and the brilliant minds who develop the product are the company elite. Everyone is justifiably proud of the company's products and achievements. All their customers are highly technically qualified people themselves - archetypal "early adopters" in fact. People in this type of company expect that all future users will be mirror images of themselves - knowledgeable, confident, competent, and enthusiastic about technology for its own sake. If these people ever allow a technical writer in their midst, they have very high expectations: the writer must be able to understand the product with only the barest minimum of instruction, and must write a manual that describes every last nuance of functionality. What users may actually want is of little or no concern.

I refer to the second type of company as the "technology service" company. Typically this is a more mature organisation which uses its core competency in a specialist field to provide services and solutions for customers. While the technologists responsible for product development still command great respect, the focus of the enterprise has moved towards sales and marketing. In some cases, the original technology sale is only the start of a long and profitable relationship with the customer which includes training, consultancy, support and maintenance. In these companies the attitude to customer support is quite different, as is the willingness to listen to customer feedback. Technical writers in these companies are more likely to be recognised as an important contributor to the value chain supporting customers.

Recently I worked with a "pure technology" team that had once been an independent company but had been taken over in the recent past by a much larger "technology service" company. My biggest challenge was to win the confidence of the development team who doubted my ability to explain their product, and were sceptical about their product being presented to a wider and less technical audience. I was, however, able to persuade them that, in the context of the larger organisation, introducing their product to less skilled audiences was very much to their advantage, as it would (or at least, as it should) generate more work for them in the form of ongoing consultancy and advanced training.

Monday, 26 January 2009

Presenting survey results at forthcoming Conferences

At the end of 2008 I conducted an online survey to find out attitudes to user documentation. It will come as no surprise to hear that many respondents felt that user documentation in general wasn't really very good. It's more than ten years since the publication of books like Dynamics in Document Design
and User and Task Analysis
so why should poor standards of documentation still persist, and what can we do to remedy this situation?

I am going to be discussing these questions and presenting my survey results at two conferences in the near future. On 20th March 2009 I am speaking at the STC France Conference in Paris, and then on 3rd-4th April 2009 I am presenting at the Information Design Association Conference in Greenwich (London). I hope you'll be able to join me at one of those events, and if not, please check back on my web site after those dates for articles about my results.

Saturday, 24 January 2009

Barriers to DITA adoption

(A response to Tom Johnson's blog "Where I stand on DITA")

Tom Johnson has decided it's time for him to seriously evaluate DITA for his work. I completely agree with Tom's comment that DITA is perfectly suited for developing and delivering easy-to-digest chunks of information, and so, theoretically, it should be eagerly embraced by all of us jobbing tech writers who want to make our work relevant to our readers and effective for our clients.

What's missing from Tom's post is an appreciation of the barriers to adoption that still exist. As an independent consultant working mainly with small businesses I find that my clients are reluctant to commit to DITA for a number of reasons:

- they are looking for something that's very easy to use and won't require too much training;

- they are looking for something that has low initial costs and even lower ongoing maintenance costs;

- they prefer to be offered a solution that comes "straight out of the box" and won't need a lot of customisation;

- they want something their own staff - who aren't trained technical writers - will be able to work with easily;

- they are looking for a familiar brand name as that seems to be reassuring;

- sometimes, they still need to be convinced of the value of investing anything at all in improving their end user documentation!

As DITA authoring tools become more user-friendly and more readily available some of these barriers will begin to fade. I do have a particular interest in one tool becoming easier to use, but in general terms, the more DITA tools that become available, and the easier they become to use, the better for everyone.

Wednesday, 14 January 2009

Wouldn't you like $300 million dollars extra revenue from your site?

Thanks to Twitter (go ahead and follow me) I am delighted to share the link below to a tremendous success story from Jared Spool.

Jared is one of the world's leading experts on usability. Many of the people I write user guides or online help systems for don't really know much about usability. They don't really know very much about the people who are going to use the products they work so hard to produce. That's a great shame, and a bit disappointing.

When I ask people if they have thought about including usability testing in their development plans they often say that the product has been through QA, or that they have allocated three days for User Acceptance Testing (UAT) at the very end of the project. Neither QA nor UAT is a substitute for usability testing.

QA testing is important, as it makes sure that when someone clicks on button A the programme displays screen B (or whatever). It doesn't test whether an ordinary user can find out if they need to get to screen B, and if they do, whether they'll know that the best way of getting there is by pressing button A. UAT is important, as it allows the client's representatives to verify that the product being delivered meets the requirements in the spec (that's always assuming that there is a spec). In my experience, UAT is normally a rushed job, and is commonly so close to the product delivery deadline that there is no time, or budget, for any remediation if a problem is identified. Moreover, UAT rarely involves any of the front line staff who are going to use the product, so it can't answer the question of whether the product helps them do their jobs.

I often spend time with product development teams and hear all about the many wonderful features of their truly amazing products. But when I ask them to tell me about the business tasks that will be easier to complete successfully by using their product, they don't have an answer. They don't have the user's point of view. Without understanding the user's point of view I can't write effective user guides and online help, and developers can't really create useful products.

Usability testing is all about the user's point of view, and the user's experience of doing their job with your product. It involves observing real users performing real tasks, and watching what happens. It involves being objective about your product, and listening and taking notice of what people who are totally unconnected to the development process - yes, complete strangers and total amateurs - have to say.

If you think that usability testing would be a waste of time and money, would delay your development timetable, and wouldn't bring you any tangible rewards, it's time for you to read Jared's story. Enjoy!

Tuesday, 6 January 2009

Coming to a status line near you

I like to think of myself as quite a good business networker - I have accounts on LinkedIN, Xing, and Ecademy, and I'm a social networker too - you can find me on Facebook. Up to now I have resisted the urge to join Twitter, the micro-blogging service, where you have just 140 characters to update your status. This was mainly because I wanted to avoid being mistaken for a Twit.
However, after some persuasive prodding, and in the spirit of new things for the new year, I have relented and you can now find me on Twitter as well. After all, what can a fellow do? I look forward to following, and being followed by, you all.

Monday, 5 January 2009

ISTC Fellowship

I am very pleased to announce that I have become a Fellow of the Institute for Scientific and Technical Communications (ISTC). The ISTC is the UK's national organisation for technical communications professionals and Fellow is the highest membership grade. I have been a member of the ISTC since 1999, and I am now one of the Tutors for the ISTC's open learning training courses in technical communications. I look forward to helping the ISTC grow and flourish in the future.