A recent conversation with a friend generated shock (and even a little scorn) that I’d been producing wireframes. I was firmly entreated to sketch instead. Around the same time a recruiter approached me with information on a job that would require detailed annotated UI specs of around 40 pages every fortnight.
The profession is still judged, by and large, by the quality of our documentation. Most recruiters and hiring managers seem more interested in the quality of annotation than the quality of thinking.
I’m rather inconsistent in my approach to documentation. Mostly the medium is picked for the context. Is the project agile? How good are the developers? Is there a remote team? Do lots of people need to be consulted? What are their reading preferences?
Whilst I’m happier with pen and paper than computer, I think it is far to say that I doodle a good deal more than I sketch. Now there’s always a way to get chickens into a blog post… this little trio were sketched during a conference presentation, presumably a scintilating one and probably about something 2.0 related given the labelling of the fowl.
In fact, it appears I doodle most when irritated by the speaker. In this case , rather than asking an insightful question to highlight the cliched and superficial nature of the argument, I wrote “blog, wisdom of the crowds, whatever”. That told him, I’m sure. I do still want this mug though:
None of this is what my friend had in mind though. She’d like this more: part user journeys, part concept map, but mostly not very pretty. Not really for sharing (apart from with you lot, of course) but it could be re-jigged into something more respectable.
I do these little pages all the time but again they aren’t for collaborative purposes. This one was so I could sanity check we had all the functionality we’d need on the product backlog before the supplier drew up the drawbridge.
Then of course, there’s cheating. Those search forms I shared recently were created in Visio but with the sketchy stencil:
I very rarely do this kind of documentation anymore. My business stakeholders are bored by them and the developers are best told what to do by pointing over their shoulders.
I do still do content models. This kind of specification still gets traction with the developers:
But, horror of horrors, a lot of my documentation these days is actually reasonably high-fidelity mock-ups. These are really aimed at the business stakeholders. Colours and fonts are pretty much fixed by our visibility requirements, so the business units know better than to ask for their favourite shade of puce. And they worry less if they don’t have to try and visualise from wireframes. It doesn’t take me any longer as I’ve got a colour stencil and the choices are pretty limited.
Is this ironic? I’m working for an organisation of and for blind people and I’m producing the most colourful deliverables ever. But then you should see the colour of the office floors.
Zack Perry | 24-Sep-09 at 2:04 pm | Permalink
This is a good point of view. I’d say over the years I’ve had to adjust my IA documentation greatly. I’d like to think we are slowly transitioning away from heavy documentation as things like agile take hold. I honestly believe that if you have solid research in front of you, then the sketch method inside an agile framework is the ideal way to go.
But you hit on a very good point early on. Take this into context. Teams these days are all over the place, complexity is the monkey running free in the park, VPs think they are designers, etc. etc. etc. Hopefully one day we’ll reach the true pathway forward.
Lauren Bopp | 24-Sep-09 at 8:01 pm | Permalink
I’ve seen a lot of discussion on the UX blogs lately about prototyping. It’s interesting to come across fresh perspectives since I think often many of us who don’t focus on UX are still locked in the old “gray-box Visio wireframes with func spec in Word” paradigm. Exploring these new prototyping tools has been really eye-opening. I decided to write my own blog post about it, particularly about how I think prototyping can provide value to the developers, not just the client stakeholders.