This article seems to show the opposite of the agile approach featured in the first article of this ALA #273.
I believe there is a middle land. I tend to define content types and applications to manage those types first, I would give the client a generic content management and generic admin interfaces for specific content types and let the SMEs enter the content in the Database, while designers work on the HTML/JS and Photoshop eyecandy and while the programmers work on the functionality.
If some content is available for a start, I prefer to use generic content management system that handles tasks such as building site-maps and navigations from the content entered into the system allowing to organize and reorganize the content on the fly. It is definitely more client-friendly and more convenient than setting things in stone in unreal documents.
It is good to work with unreal things to a certain extend, although certain aspects of the work you suggest to carry out, before a line of code is written, are too far.
Copy & paste the code below to embed this comment.
Keith LaFerriere
Hi, František:
You mentioned that the documents may be unreal, but I wanted to point out that this is an iterative process. The content, the requirements, the strategy are all things we would like to have up front not only to properly plan the entire site (or application), but to give clear guides to the design and development team, help the client save costs, and keep things in scope.
To wit: The IA would, for example, take the responsibility of conducting a nomenclature interview. The outcome of this interview would have a direct impact on the design (navigation, most certainly), but that doesn’t mean that the designer has to wait for their turn in the cycle. The designer (and creative lead / director) should be holding their own court to find out what the brand elements and design approach should be.
It’s a small example, but there are literally hundreds of things that have to happen at the right time in order to make the project a success. It’s all happening in and around other events.
Most designers n developers.. leva alone clients don’t understand the importance of Information Architecture. This article has thrown a lot of importance on the subject. I wish people become more aware about IA as a cruical aspect that dictates the website development project.
Copy & paste the code below to embed this comment.
rod homor
Hi. Thanks for the great article. It was full of great reasons why IA is important, and how to present certain concepts to clients.
It also reminds me of a lecture that I saw at Chicago’s “An Event Apart” last year. It talked about how IA is and should be part of everyone’s (who are working on a web project) considerations, and not solely left to the Information Architect. I wanted to pass this along, because developers, designers and content managers who work on a web project can also put an IA hat on to help keep a project on time/budget and minimize scope creep. Heck, even account managers!
Thanks, ALA, for continually publishing helpful ideas…
It is always interesting to see the difference with a repeat client who you couldn’t talk into spending the time and budget on a good go at IA the first time. Without the proper IA at the beginning of a project I have never had a great experience getting to a finished site.
However, despite the inevitable frustration that comes without the proper IA, when I get the chance to work with the same client again and am able to show them what could have been avoided if we had spent the time at the beginning in IA and they give it a chance with the second project, it has always proven to make both sides much happier in the end.
Thanks for the great article laying it all out…hopefully, it will help me talk first-time clients into spending time in IA rather than learning the hard way!
Copy & paste the code below to embed this comment.
Keith LaFerriere
Hi Jason:
To give you a helpful selling point: Make sure the client is aware of not only what IA is, but how they can save money. It’s not bad saying to a client, “I know your budget is tight, but this will actually help us save you money and time on rework”.
To illustrate this further, take a generic example to them. Use a previous project, wipe out the name and explain how much work was saved by the correct emphasis up front in IA.
If you have a project that endured a lot of change, use that one. Good luck!
“If we want our customers to embrace IA, we must help them understand why we need it.”
This is so often forgotten, I think it is crucial that we step outside of our environment and make sure that we are communicating effectively with our clients, and educating them is a big part of that process.
I know this irony is partly due to juxtaposition with an article you didn’t create, but…
This article reads a lot like the waterfall process reengineered for information architecture instead of software development. And in ALA, the two articles seemed to be:
1: “IA needs a waterfall analogue”
2: “Draw on Agile; current economic conditions sound the death knell to waterfall”
Again, the irony doesn’t all belong to you… but the pair of articles current today left me thinking more about irony than I wanted…
Copy & paste the code below to embed this comment.
james retuya
As a prominent marketing agency, we always emphasize on the value of custom logo design since it will be the frontliner of any business. In the webpage, we further enhance it with flash design while still following SEO standard to properly index the page. We may not be an established web design agency should we not gain the secrets of making all website design be indexed.
I’m intrigued that the discussion has veered into the differences between a Waterfall and an Agile approach. The thing I took away from reading this was another thoughtful reminder of how important it is for designers, engineers, and product owners to communicate in a shared language. The actual language used isn’t really the point—except when it is.
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 ArticleFrantišek Malina
This article seems to show the opposite of the agile approach featured in the first article of this ALA #273.
I believe there is a middle land. I tend to define content types and applications to manage those types first, I would give the client a generic content management and generic admin interfaces for specific content types and let the SMEs enter the content in the Database, while designers work on the HTML/JS and Photoshop eyecandy and while the programmers work on the functionality.
If some content is available for a start, I prefer to use generic content management system that handles tasks such as building site-maps and navigations from the content entered into the system allowing to organize and reorganize the content on the fly. It is definitely more client-friendly and more convenient than setting things in stone in unreal documents.
It is good to work with unreal things to a certain extend, although certain aspects of the work you suggest to carry out, before a line of code is written, are too far.
Keith LaFerriere
Hi, František:
You mentioned that the documents may be unreal, but I wanted to point out that this is an iterative process. The content, the requirements, the strategy are all things we would like to have up front not only to properly plan the entire site (or application), but to give clear guides to the design and development team, help the client save costs, and keep things in scope.
To wit: The IA would, for example, take the responsibility of conducting a nomenclature interview. The outcome of this interview would have a direct impact on the design (navigation, most certainly), but that doesn’t mean that the designer has to wait for their turn in the cycle. The designer (and creative lead / director) should be holding their own court to find out what the brand elements and design approach should be.
It’s a small example, but there are literally hundreds of things that have to happen at the right time in order to make the project a success. It’s all happening in and around other events.
Maneet Puri
Most designers n developers.. leva alone clients don’t understand the importance of Information Architecture. This article has thrown a lot of importance on the subject. I wish people become more aware about IA as a cruical aspect that dictates the website development project.
rod homor
Hi. Thanks for the great article. It was full of great reasons why IA is important, and how to present certain concepts to clients.
It also reminds me of a lecture that I saw at Chicago’s “An Event Apart” last year. It talked about how IA is and should be part of everyone’s (who are working on a web project) considerations, and not solely left to the Information Architect. I wanted to pass this along, because developers, designers and content managers who work on a web project can also put an IA hat on to help keep a project on time/budget and minimize scope creep. Heck, even account managers!
Thanks, ALA, for continually publishing helpful ideas…
Jason Jones
It is always interesting to see the difference with a repeat client who you couldn’t talk into spending the time and budget on a good go at IA the first time. Without the proper IA at the beginning of a project I have never had a great experience getting to a finished site.
However, despite the inevitable frustration that comes without the proper IA, when I get the chance to work with the same client again and am able to show them what could have been avoided if we had spent the time at the beginning in IA and they give it a chance with the second project, it has always proven to make both sides much happier in the end.
Thanks for the great article laying it all out…hopefully, it will help me talk first-time clients into spending time in IA rather than learning the hard way!
Keith LaFerriere
Hi Jason:
To give you a helpful selling point: Make sure the client is aware of not only what IA is, but how they can save money. It’s not bad saying to a client, “I know your budget is tight, but this will actually help us save you money and time on rework”.
To illustrate this further, take a generic example to them. Use a previous project, wipe out the name and explain how much work was saved by the correct emphasis up front in IA.
If you have a project that endured a lot of change, use that one. Good luck!
Aaron Irizarry
“If we want our customers to embrace IA, we must help them understand why we need it.”
This is so often forgotten, I think it is crucial that we step outside of our environment and make sure that we are communicating effectively with our clients, and educating them is a big part of that process.
Jonathan Hayward
I know this irony is partly due to juxtaposition with an article you didn’t create, but…
This article reads a lot like the waterfall process reengineered for information architecture instead of software development. And in ALA, the two articles seemed to be:
1: “IA needs a waterfall analogue”
2: “Draw on Agile; current economic conditions sound the death knell to waterfall”
Again, the irony doesn’t all belong to you… but the pair of articles current today left me thinking more about irony than I wanted…
-Jonathan
james retuya
As a prominent marketing agency, we always emphasize on the value of custom logo design since it will be the frontliner of any business. In the webpage, we further enhance it with flash design while still following SEO standard to properly index the page. We may not be an established web design agency should we not gain the secrets of making all website design be indexed.
M. David Green
I’m intrigued that the discussion has veered into the differences between a Waterfall and an Agile approach. The thing I took away from reading this was another thoughtful reminder of how important it is for designers, engineers, and product owners to communicate in a shared language. The actual language used isn’t really the point—except when it is.
Duncan 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.