ux | work | life matters

Better, betterer, betterest

Yesterday I received a confirmation email for my submission to the IA Summit in Denver next year. I’ve never presented at a conference but it’s been on my wish list for a while. This year they were looking for submissions from new speakers and the subject was “Better”. How we as IAs can be better.

To me better it is about how we ensure, from the start, that we end up with a good experience throughout the whole project and an end result which excites the users, the client and the team just as much.
If you’ve worked with me you’ve without a doubt come across me talking about:

    [list type=”arrow”]

  • the importance of IA being involved from start to finish and of us working collaboratively across disciplines
  • how the IA needs to be involved in reviews, sign off designs and QA the technical deliverable to ensure the end product meets the requirements
  • how we should be involved in meetings, present our own work and be cc’ed in on emails (regarding requirements) to the client so we can follow the conversations that are taking place
  • how IA should be involved in the development of the CMS and how you shouldn’t leave content rules unspecified and rely on the internal content editors to enter the right type, and amount, of content
  • how the little details and consistency in design can make all the difference to the quaility of the end result and to the experience
  • why you shouldn’t define content strategies without input from the IA
  • how we should challenge client requirements/feedback to ensure the client understands our recommendations and things/changes are done for the right reasons
  • how rushing something live and cutting corners in the process in most cases results in an end product that cost more long term and/or which doesn’t fulfill what it was set out to achieve
  • how rushing something live and cutting corners in the process in most cases results in an end product that cost more long term and/or which doesn’t fulfill what it was set out to achieve
  • [/list]

My submission

The focus of my submission was related to the last two points in particular. More precisely how experience planning and utilising the lifecycle can be used as tools that don’t eat up the budget but instead…

    [list type=”arrow”]

  • …helps define not only the immidiate requirements but also the longer term ones
  • …ensures client buy in by involving them in the process and making them aware of both their and their users’ needs
  • …helps prioritise requirements and identify what’s most important
  • …can be used throughout the project as a reference point of what was set out to be achieved
  • [/list]

In summary, how it can help us be better IAs and turn projects we don’t talk about into projects we do talk about. Below is an excerpt from my submission:

We’ve all been there and we all cringe at the thought of them. The projects that were going to be so great but ended up being something neither the team nor the client particularly want to mention on their CV. They may not be a disaster, but they aren’t great so we rather just forget about them.
With tight deadlines and budgets it’s no wonder that we sometimes give in and let things go out the door which aren’t as good as we wanted them to be. Or that we let the client have their way even though it so obviously goes against what they should be doing. All perfectly understandable and at times it’s the only option. But, I would argue that in a large number of cases this can be avoided if we as IAs do our job better.

Hopefully I’ll be one of the lucky ones and get a chance to present. If not you can expect an extended blog post on the subject.

Image source: www.flickr.com/photos/jliba/8063227343

Have you read these?