For large scale projects, sure, I completely agree with this approach. I’d go as far as to say this kind of documentation is absolutely necessary to avoid scope creep and arguments along the way.
But on a day to day level? On a day to day level it’s pointless, even counter productive, and unnecessary, especially if we’re working to a minimum budget spec. The client knows what they want, I know what they need and want, and it doesn’t come down to much more than a design job.
Of course we could treble or quadruple the time we bill them for by going through the rigmarole of wireframing, employing UI “experts”, documenting everything, then going through multiple iterations of the process to reach an outcome.
In my experience, on ‘most’jobs, clients view lengthy documentation as a pain in the ass. And I would tend to agree with them.
Copy & paste the code below to embed this comment.
Keith LaFerriere
Hi, Duncan:
It’s only counterproductive if you make it more than it needs to be. Every project, large or small, deserves attention to detail. Even if this means you put in 2 hours of your own time to truly understand a problem and document it in rough draft for your own team. I do, in fact, spend some non-billed hours doing this on almost every project.
This isn’t to say you should, mind you, but it’s what I believe.
Copy & paste the code below to embed this comment.
Erik Reppen
If I didn’t run into so many poorly designed sites when trying to find out more about it. Links to PDFs without indication that you’re not linking to markup. 25 bullet point lists done in ul tags that reference other bullet points by number. Those two examples are from official-looking IA organizations on the front page of a Google search. I won’t even go into the blogs or words like “deliverables” or improper use of focus groups who have to tell you something even if they thought nothing.
34 Reader Comments
Back to the ArticleDuncan Macdonald
For large scale projects, sure, I completely agree with this approach. I’d go as far as to say this kind of documentation is absolutely necessary to avoid scope creep and arguments along the way.
But on a day to day level? On a day to day level it’s pointless, even counter productive, and unnecessary, especially if we’re working to a minimum budget spec. The client knows what they want, I know what they need and want, and it doesn’t come down to much more than a design job.
Of course we could treble or quadruple the time we bill them for by going through the rigmarole of wireframing, employing UI “experts”, documenting everything, then going through multiple iterations of the process to reach an outcome.
In my experience, on ‘most’jobs, clients view lengthy documentation as a pain in the ass. And I would tend to agree with them.
On HUGE projects though, sure thing.
Keith LaFerriere
Hi, Duncan:
It’s only counterproductive if you make it more than it needs to be. Every project, large or small, deserves attention to detail. Even if this means you put in 2 hours of your own time to truly understand a problem and document it in rough draft for your own team. I do, in fact, spend some non-billed hours doing this on almost every project.
This isn’t to say you should, mind you, but it’s what I believe.
Thanks for the comment!
Harnish Goradia
I have found continuous education of my employer a bigger part of my job than the actual job! Does anyone else have this experience?
Erik Reppen
If I didn’t run into so many poorly designed sites when trying to find out more about it. Links to PDFs without indication that you’re not linking to markup. 25 bullet point lists done in ul tags that reference other bullet points by number. Those two examples are from official-looking IA organizations on the front page of a Google search. I won’t even go into the blogs or words like “deliverables” or improper use of focus groups who have to tell you something even if they thought nothing.