Work

For my CV and portfolio scroll down to the bottom of the page or click here.

What do I do for a living? I'll tell you in a minute (unless you can't wait). Before that a brief resume: When I left school I wanted to be a rock star. So I bummed around, rehearsed and gigged with various amateur bands, and worked in a local art shop and later a record shop. In 1975 I started playing professionally on the pub circuit with an Irish folk band called Country Wine and over the next few years played with the same basic core of musicians in bands like Crannog, Brahms & Liszt, Poteen, Chanter, Irish Mist, Zozimus, Mr JJ and the Joe Giltrap Band to name but a few. Some were very folky, some were very rocky, all featured the same long-haired herbert on very loud - and very good though I say it myself - bass guitar. In the late 70s I decided I needed a real job so I trained as a chef and worked for a while in Ormonds restaurant before finding myself back in the music biz doing sound engineering at the Sir George Robey. Did some more gigs as well.

Then in the mid 80s I went to work for Haringey Community Workshops, taking the arts out to the disadvantaged. They were good days but bad management meant that it collapsed, so I went to work for Wandsworth Social Services in their mental health team. For eight years I trained and practised in group and individual psychotherapy and counselling before bailing out in 1996 'cos I couldn't stand another Christmas in the drop-in cafe. I applied for all kinds of jobs and eventually was hired by Psion Software to help write the documentation for the upcoming Series 5. I stayed with Psion through their transition into Symbian and then... redundancy, in June this year. Bit of a bummer for all concerned. Unfortunately the mobile Internet wasn't happening as fast as some people thought it might and the expected huge demand for prohibitively expensive mobile devices that allow you to browse about a quarter of the Web at 40x20 resolution hasn't happened. Wonder why?

No, really though, I can't help thinking that the whole Symbian thing was a bit naive. It was great fun while it lasted though! After that I went to work for Categoric - and spent 18 months commuting 4 hours a day before finding my way to Mobile Innovation to work on a project for Nokia alongside many of the people that I used to know at Symbian. That contract ended, as contracts do, and then I went to work for IDX as a tech author and trainer on the CfH (Connecting for Health) project implementing Carecast for the NHS in London as part of NPfIT. IDX were then taken over by GE Healthcare, and it's all a bit up in the air at the moment.

Yes, so what do you do???

I'm a professional technical author, which means that I take complicated stuff - usually software - and write about it in a way that non-nuclear physicists can understand. My audiences vary from you - yes you - through real numpties like my mum who barely understand what a mouse is (and why should they, you might ask?) to computer professionals. In practice, a fair bit of the work is writing the online Help for Windows products that nobody reads! Mind you, there's a reason - or a number of reasons - for that, not the least of which is that most of it is extremely badly written (including, I might add, the Help for my own company's product. Not my fault, nor my boss's - we're both new and we both want to rewrite as much as possible when we get time). As well as the Help I also write user manuals, although these are getting less common now as companies try to cut costs by not bundling a printed document. There's also a general trend towards online documentation because it's so much easier to update and maintain.

While I've been at IDX and GE I've been a lot more involved in training as well, writing Word docs & Powerpoints and then delivering courses to people from the NHS, BT and assorted hospitals in the London area. This has been fun!

In addition to Help, user manuals (generally referred to us "user docs") and training materials I also write "user interface specifications". Basically there should be (I say "should be" because all too often the req or UI spec are omitted and the software looks awful or doesn't do anything very useful, very well) three kinds of spec when software is being developed, and they are written in the following order:

  1. The requirements specification ought to come from the sales, marketing, research and tech support departments. It sets out what the software is supposed to do, who it's aimed for, and some parameters about what it isn't required to do, how easy it should be to use, what spec machine it needs to run, etc. This doc is then discussed with engineers who claim it's a load of impossible pants and then eventually, after some negotiation, an agreement is reached. This then becomes the immovable definition of what the software will do (although see the change request process below)
  2. When the requirements have been agreed, the Interaction Designers move in (assisted by people like me, if the company has any sense) and begin to map out what it will look like, how it will behave. What buttons and icons should there be? What menu commands? What needs to be up front and easily accessible, what needs to be hidden away so it doesn't accidentally get pressed? Most importantly, what are the user's goals? What will the end user really want to do and what will they need to do (often two different things... I need to finish this spec - I want to go to the pub)? How can it be enjoyable and "charming" (a Psion/Symbian word) to use? Interaction Design is a relatively new discipline and many companies (including my own, right now) don't have any at all - you can always tell when software has been designed by the engineers (see the Interface Hall of Shame for some really bad designs). After a couple of years working with some good UI designers (Hi Scott, Mat, Nick et al) the ideas and sheer sense of good UI design rubbed off on me and I'm a pretty good UI consultant now - although I wouldn't pretend to be an Interaction Designer. Anyway, the end result of all this is a User Interface Specification that consists of lots and lots of mocked-up screenshots, menu tile layouts, dialog designs and wordings, etc. This is what the software will look like. I write UI specs as well as user docs and, assuming I've been involved up to now, I can start on the Help now because I know what it's going to be like - after all, I helped design it.
  3. At some time during the development of the UI spec, senior engineers are brought in and they get a first look at what they're going to be asked to do. They get their heads around what's being asked of them and, after much thinking and discussion (and negotiation) they produce a Functional Specification (or Implementation Specification). This sets out how they are going to tackle the problems, what language they're going to code it in, what pieces of existing software will be used or modified, what modules will need to be written from scratch, etc. The func spec is a very technical piece of writing and I've rarely understood much of what I've seen in them, but the engineering team will. So the func spec says how the engineers will write the software.

After all three of these documents have been agreed they enter a period of change control. What that means is that everybody knows, despite the agreements, that in the development lifecycle there will be changes. Features that can't be done in time for the ship date, things that don't work as planned, things that are just too difficult to use despite the best efforts of the ID people and usability researchers. But engineers can't just change things willy-nilly (or there'd be an almighty mess) so every potential change is submitted as a "change request".

The person who wants to make the change (and they can come from anywhere) submits a written proposal describing the problem and a suggested solution such as "drop this feature", "let's do it differently", "move that button over there", "delay the ship date by a month so we can do it properly", etc. Then a "core team", comprised of representatives from all the interested parties, meets once a week or so to discuss all the change requests (CRs) and agree the best way of tackling them. Some are just turned down, of course, and the engineers have to find a way of doing the impossible. A really good engineer usually can :-). With a proper CR process there are no unexpected changes and the documentation can keep up with the product. Which is my main job.

My CV and Portfolio - here's my CV in Word or HTML and here are some of the things I've done: