… it’s just as important to be able to come up with a solid IA strategy as it is to be able to sell in that strategy. To explain to your stakeholders why your approach is the right one, and why they should approve it.
So, what if you’re really quite good at this ‘sales’ process. Rationalising the approach that you’ve taken and being able to describe that in terms that are aligned with the overall project strategy.
You sound confident and authorative and you use words that your client may not understand (but probably won’t tell you because they don’t want to look dumb).
What if you’re just really good at selling bad ideas?
everyone I know who loves agile-type methodologies has three things in common:
they work in a small team. Like, less than 10 people. Usually less than 5.
they don’t have to do monthly profit reports to management
they don’t have (external) clients.
That kind of environment makes it really easy to love a methodology where you don’t have to accurately define the scope of a project (what the client is going to ‘get’ at the end), and where iteration and collaboration is a way of life.
Consequently, over the last 12 months or so I find myself getting into lots of heated discussions with people over the value of functional specifications. The cool kids say that func. specs. are a waste of time, that they are creativity killers, and that there is no place for them in application design and development today.
I love the sound of that. Hell. I’d love to ditch functional specs if I thought it would give a good outcome. I don’t like writing them. Does anyone like writing them?!
But, can my clients cope without documentation? Without bits of paper that they rarely read but that allows them to feel comfortable throughout the development process – makes them feel that there is a process, there is a scope, and that we have it all under control. Tells them what they’re going to get for their money.
One of the aspects of RIA interface design that is causing some consternation (or at least discussion) at the moment, is around how we make the interfaces easy to use.
There are lots of great ideas being thrown around, techniques that look as though they could evolve into future conventions.
One thing I find myself thinking of often is how we go about documenting these conventions.
It has been my experience that in reading about RIA and usability, many of the suggestions made fall into what would traditionally be the realm of the visual designer or the application developer. Examples (from the article cited above) include:
… Visual attention is attracted by movement and high color contrast … We can use this to our advantage and draw the eye to the updated part of the page [Visual Design]
… By making sure the change occurs quickly …. we can ensure the eye is drawn to the appropriate place [Application Developer]
… Odeo provides effective feedback by using color (and) movement [Visual Design]
Now, for me, these are all excellent suggestions for making RIAs more usable. They are also things that, traditionally, I would have neglected to include in my project documentation. Say I was working in a large development team and wasn’t involved in the ‘production’ phase of the project (where the designers and developers took up my specifications and built the project), I couldn’t guarantee that these measures would be taken. I could only hope that they’d be picked up and recommended in later usability testing. Not good enough really, is it?
Image Attribution: card sorting exercise borrowed from the Card Sorting, A Definitive Guide by Todd Warfel & Donna Maurer
Today we take a little adventure in the land of card sorting.
Anyone who’s been doing IA for long (or even studying it) would have come across the card sort. Its one of the simplest and most frequently applied exercises in organising content into structure. It can be really helpful and help to ensure that you’re taking a user centric approach to the information design of the site.
As I’ve mentioned before, I’m working on a project which has number of specific international audiences. I have card sorting on my agenda in the pretty near future. What I’d like to do here is take a look at:
My name is Leisa Reichelt. I am the Head of User Research at the Government Digital Service in the Cabinet Office.
I lead a team of great researchers who work in agile, multidisciplinary digital teams to help continuously connect the people who design products with the people who will use them and support experimentation and ongoing learning in product design.
If you're interested in working with me or would like to talk more please email me