Information architecture (IA) means so much to our projects, from setting requirements to establishing the baseline layout for our design and development teams. But what does it mean to your clients? Do they see the value in IA? What happens when they change their minds? Can IA help manage the change control process? More than ever, we must ensure that our clients find value in and embrace IA—and it’s is our job to educate them.
If we want our customers to embrace IA, we must help them understand why we need it. IA is about selling ideas effectively, designing with accuracy, and working with complex interactivity to guide different personas (potential customers) through website experiences.
The following talking points may help your clients understand the value of IA.
IA incorporates requirements, goals, and user paths#section2
Explaining the purpose of IA to the client should be easy once you discover a project’s purpose. Is it to increase awareness of a product or service? Is it to make the purchase path easier? IA incorporates these requirements and marketing goals and outlines traffic patterns so that the website can become a successful extension of a product or service.
I often tell clients that IA establishes the baseline, or foundation, for a solid site structure. It helps create the traffic patterns and navigational routes that get the customer from A to B in language that is helpful and easy to understand. In fact, IA is the first step in meeting customer goals and can therefore increase brand awareness and product or service sales.
IA mitigates scope creep#section3
Since requirement gathering usually takes place at the same time as IA, IA can serve as a guide, keeping the project on track. IA ensures that project requirements are met since it establishes functionality, customer flows, and design.
With a solid IA, the customer’s project gets delivered on time and on budget. Changing requirements means changing IA, and that means the entire downstream process will need to be adjusted.
IA validates the site’s purpose and goals#section4
When working with your client to gather requirements, there are ways to validate whether or not you’re on the right track. Take those moments to step back and explain to the client what you’re doing and/or thinking, and validate current and future work. Once your IA is defined and agreed on, help clients understand that redesigning or adding development time after this point compromises schedule and adds cost.
If the client asks for changes to the IA, cost out the hours, resources and overall effort. Supply a cost analysis or a quote for the additional work so that they understand the consequence of changing direction.
Well-executed IA can be used to defuse any future questions in both design and development. Barring any large changes in scope, the IA will document and protect the project, so long as you educate the client along the way.
Defining IA’s deliverables for the client#section5
All project members should have input into the architecture. That seems pretty simple, but as the project moves from phase to phase, from iteration to iteration, keeping the deliverables tight becomes more difficult. Since this can be applied to any type of website, we’ll keep things generic and worry about the deliverables.
Phase one: discovery and initial approval#section6
Not all deliverables listed here need to be part of your project, but the team should understand the associated expectations as they work through the design process from concept to production.
| Deliverable | Phase One Expectations | Audience Notes |
|---|---|---|
| Deliverable | Phase 1 Expectations | Audience Notes |
|
Content Survey |
A high-level content assessment. These larger, more loosely-defined chunks help the team understand the scope of the entire project. The content survey should be delivered to the team as soon as it’s approved. |
Every project member should have interest in this document, but the client project team should have the majority of the input. |
|
Content Map |
The content map is a box-and-arrow graphical representation of content by section. It should eventually transition to the site and navigation maps. As pieces are moved between sections or areas of the site or application, the content map helps manage the traffic and controls content edits. The design and development team should receive an early iteration of this to understand which sections intersect. |
Client subject matter experts (SMEs) and the designers should be well aware of this direction. Walk through this document with the user interface (UI) developers once this is set in stone. |
|
Detailed Audit |
A detailed audit lists pages of content with unique identifiers. These identifiers are then used on the site maps and user flows where space is tight. These unique identifiers are especially helpful for new content. |
The client SMEs, the developers, and the quality assurance (QA) team should have copies of this once it is approved to use as a guide for the project. |
|
Site Map |
In the early stages, the site map needs to, at a basic level, reflect the combination of information and functionality to be accessed by the user. The site map is not, in my opinion, a navigation tool. Using unique identifiers from either the detailed audit or established in the site map itself, the flow of the user experience should be detailed as if the user is interacting with it. The site map, of course, is a critical deliverable in the early stages of design and should be signed off by the client before design enters the post-concept stage. |
All project team members should use this as a baseline guide. |
|
Navigation Schema |
At the onset, a navigation schema will be hard to define without help from the client’s SMEs. Defining taxonomy and the navigation between interactive elements can be one of the longest tasks on a complex project. Not only are you dealing with the constraint of real estate, but you are also dealing with multiple-language factors, marketing preferences and the initial user experience. Get as much as possible set in stone at a high level before you begin design. |
The entire team will benefit from this deliverable. The main audience for this is the client’s SMEs and the design and development teams. |
|
Persona Definitions |
Early persona definitions should be available from the client product or project team. These personas can be enhanced to meet the demands of the online environment. Persona enhancement depends on how many personas there are and any common elements that may be reused. The usability and design teams should be part of this task. Client SMEs and the marketing groups must provide input. |
Once definitions are in place, the design and usability teams will need to use them as they do their tasks. |
|
Use Case / Requirements Document |
Typically the responsibility of the business analyst or client SME, the use case or requirements document must define tasks to be performed. Most times, a set of use cases needs to be submitted to help define user flow. For example, Use Case 1: Log in, Use Case 2: Forgot Password, etc. Without detailed requirements, it is incredibly difficult to scope, design, and develop a website. At the very least, a list of use cases should be presented to the team at the same time as the site map. This helps everyone see the correlation between form and function. |
The business analysts, project managers, client’s SMEs, and IA team members need this documentation to do their jobs. The project manager or the business analyst should update this during the project. |
|
Wireframes |
Another “gold standard,” the wireframe must be complete before post-concept design can begin. In many cases, internationalization and multiple-language points must be addressed, as well as basic layout guidelines for the breadth (or lack) of content. Don’t allow the client to dictate the design unless you’re incorporating the work into an existing website. Always work with the usability specialist and designer before you hand off the wireframe for approval. This is one of the most critical project deliverables. It’s something that everyone on your internal team should see before you seek approval. |
This set of deliverables is for all project team members. Along with the site map and requirements, wireframes will guide the team as they complete their tasks. |
Phase two: design and development#section7
As the team moves from concept to development, deliverables get updated and are worked into the project flow. Expectations for each deliverable will change and should be communicated to the team as either an edit or an official change, depending on the level of complexity. Here’s how expectations change for deliverables during design and development:
| Deliverable | Phase Two Expectations |
|---|---|
| Deliverable | Phase 2 Expectations |
|
Content Survey |
The content survey should not be updated. It should be placed in the project repository as a completed asset. |
|
Content Map |
The content map is a living document. During design and development, the content map helps identify scope creep. New requirements should be added and communicated as quickly as possible. |
|
Detailed Audit |
If a detailed audit was completed, the document should note delivered content and content edits. If new content is added and the project can withstand it, update the detailed audit at the same time as the site map. |
|
Site Map |
At this point, the site map should be updated with new drive-down flows and any additional supporting information on how pages or functions interact. The site map is a living document and must be updated when content or functionality is either completed or changed. |
|
Navigation Schema |
In phase one you defined the basic navigation schema, taxonomy, and user flow. In phase two, changes should come from either usability testing or from direct user feedback. Change decisions must consider layout, design, and functional elements. |
|
Persona Definitions |
Persona definitions should not change after phase one. Designers and usability specialists often refer to persona definitions to make sure that the user’s needs are met. |
|
Use Case / Requirements Document |
In phase two, use case lists and high-level user flows must be expanded and the true functionality defined. In the “Log In” use case, the expanded definition will include the ways in which users will log in, both technically and in visual design terms. |
|
Wireframes |
In phase two, wireframes are added to complete the design process and assist production. If a major change is introduced during phase two, produce a new template and get it approved. All new wireframe tasks must stem from the template. Changing legacy wireframe documents once they’ve hit production can be a fruitless and costly exercise. |
Can you spare some change?#section8
The change control process makes or breaks your profit on a project. In some cases, change control can be tricky for you and your client. After all, your client expects you to complete the work they give you, even if it isn’t part of the initial set of requirements. The change control process protects the project, your costs, and the client’s best interests.
The following table outlines the process and some decisions on how to effectively use a standard change control process:
| Deliverable | Sign-off | Notes |
|---|---|---|
| Deliverable | Sign-off | Notes |
|
Content Survey |
Sign-off occurs when your client has given you all the content to be used on the site or application. |
Initially, minor adjustments mean minor influence on the project. Once this is signed-off, any large edits will affect the entire IA process. |
|
Content Map |
Complete an initial sign-off as soon as the main requirements are set. |
Changes to the content map mean changes to the requirements. Be aware of this and you’ll have the documentation you need to manage project changes. |
|
Detailed Audit |
Sign-off the detailed audit as soon as you are ready to start documenting requirements. |
Most projects will not have a detailed audit. If one is created and updated, use other deliverables, such as the content map and site map to manage change. |
|
Site Map |
The site map requires sign-off any time a change is made (past the initial review). The site map can drive the entire process. |
Site map change is huge. It’s critical to keep the site map up to date and call out any major changes. It will directly influence the design and development phases. |
|
Navigation Schema |
Sign-off the navigation schema as soon as the team agrees on the site map and taxonomy. |
As you move into the navigation and user flows of the project, you’ll need the navigation schema to dictate the influence on other phases. Late-phase edits to this deliverable can be costly because they mean changes in the entire development cycle. |
|
Persona Definitions |
The sign-off for these should happen before you begin design. As personas are created, vet them against the navigation schema. |
Different folks will take different paths. Be aware of who the audience is and what they need to manage any changes. |
|
Use Case / Requirements Document |
The sign-off for this documentation is paramount to your project. Whether you receive completed requirements from the client or are helping to create them, you must get sign-off before you begin the design process. |
Any edits to the requirements should be taken into consideration for scope creep. Changes to the requirements influence the entire project. |
|
Wireframes |
Complete sign-off for certain pages (home, drill-down, specific functionality) before you start to design. |
Before changing the wireframes, make sure the changes are either template level or page level. Page-level changes can be conveyed in the design, but template-level changes should be completed and signed off. |
Flexible fuel#section9
Websites are flexible and every deliverable must be able to grow (or shrink) with the site. Changes can come from outside forces as well, including focus group data, usability testing, and even server architecture or hosting changes.
Transparency—educating the client on standard processes and deliverables—is tantamount to the success of a project. By using these standards, IA can more easily help manage both the decision-making process and the overall cost. The team lead must take on the responsibility of training the client for the designers and developers to produce accurate work.
Proper IA, when done with an informed client, becomes the flexible fuel that drives the user experience.
I thought this article was easy to understand and very thorough. It was complete and made it easy to help me explain this to a client. Thank you for providing this resource.
Throughout my schooling wire frames, site maps, use cases and the like were part of the projects. I really value this type of planning.
But after school I found myself working at a small company building sites for small clients. Planning for these projects involved gathering requirements from the client, creating a mockup and then building the site.
Just because our clients were small didn’t mean their sites were small. Instead, the budget was the most limiting factor. These clients didn’t see a lot of value in planning ahead and the larger the project was the more difficult it became to build.
I’m still searching for the best balance between IA and time/cost but this article is going to help. Thank you.
Thank you for this discussion on the benefits of IA for clients. The suggested talking points are perfect.
I wonder if some other aspects should also be considered in your Phase One, if not before. These are the dynamic information (data) flows and trust boundaries, and thus consideration of the sensitivity of the data being handled and who can access what. Without doing this, ad-hoc security controls need to be added later in the project’s life cycle which will be more costly and probably less effective.
Also, in creating use cases, it’s also worth trying to think about misuse cases, but this can be a harder concept for people to grasp.
This article, in my opinion, can easily turn into a book if you elaborate on some of the points, and provide templates.
This is a concise and comprehensive discussion of Information Architecture. Thanks…
Kevin did a fantastic job with the illustration for this idea; it’s brilliant!
Dana: Thank you for pointing something out that I should have mentioned / done a table for in the article. Even small projects have, or should have, elements of the IA process. UX firms should be willing to use their own methods and processes even when they do their own website. It’s important to plan it all, even the small stuff.
Clerkendweller: I believe you are correct that if the team can maintain a larger IA compliment, then user flows should be included in Phase 1. As you’ve pointed out, even before this if possible. I agree! The IA, business analyst, project manager, and creative lead / manager should map out the user flows ASAP so that the rest of the IA process can enjoy a natural cadence from both the user flows and the high-level use cases.
PM Hut: Is that an offer? If you have connections, speak now! 😉 Thanks. (I am not, however, available for weddings or Bat/Bar mitzvahs.)
I think that information architecture is the most important part of web development. The approach I use is the pry as much information from the client as I can about what their site’s purpose is, and get as much content as possible from them, and then design the site around that. From an interaction standpoint, information architecture is nothing more than a series of links, where they appear, and where they are on the page. That’s the way I approach is to the client, rather than showing them some idiotic diagram.
If this article would be a video, I’d out it on IA Television every day :-)…
thx
I’ve been doing this kind of IA planning with clients since 1995, and one thing I’ve learned is your planning documents have to make sense to the client. Keeping it simple is a good way to do that. IA doesn’t have to be complex, but it is essential to even the smallest website project. Heck, even the odd client who needed just a temporary one page placeholder site, we still sat down and outlined what content would need to be on that page and how it would be presented, and I still wrote up a simple document to get sign off on that.
But I find IA most valuable in helping to discover what it is the client actually needs/wants, because clients often don’t know what they need or want.
I run a relatively young web design business and at the moment we are trying to find the best way to manage our projects and clients. I found this article really helpful as I do the site as a whole.
The article raises a lot of very interesting points, from a novice point of view its very difficult to know where to start! How have other users of this site learnt how to apply these principles? Can anyone recommend a resource which examines the subject in greater detail, or where we can see detailed examples of each stage to use as a starting point?
Any pointers would be greatly appreciated.
This is totally a wrong approach. It assumes that the client knows what he/she wants to present (in the real world there are no clients that say: “Hey this is my content, please make a website of it!) and assumes also that this can be defined by a survey. This approach would be very boring too, I would for my self wouldn’t want to work for these kind of clients, because they already decided which and how the information should be presented.
This approach would cost to much. Just spending a lot of hours to come up with design deliverables and billing them will be a business killer. The competitors will build a working site for the same budget!
I agree that for example use cases are very important. But writing complete and accurate use cases is a hell of a job and most of the time useless because the developer needs to read them for hours and research again what the use cases try to explain. Most of the time the developer will find out that these are incomplete, not detailed enough or make bad assumptions.
If this is the wrong approach, what is the right approach?
– It depends of the team, the client and the assignment.
Fantastic article. I can see myself using the spirit of the piece in my next sales call to help explain the value of a well developed Information Architecture. The 1/10/100 rule from my programming days applies to IA as well: it’ll cost you a dollar to put the time into thorough discovery up front, 10 dollars if you uncover a key content area/goal/functionality during development, and 100 dollars to engineer that in after the site/system/design is built.
Yes, there are certain projects (small sites or standard cookie-cutters) that don’t require an extensive IA phase/process, but I don’t think that’s what the author was focusing on. Even for those smaller projects, while we don’t spec or bill for an IA phase, we do adhere to the general principles of sound IA while working through discovery.
And I don’t think anyone can understate the value of hammering out the content requirements and shepherding the client through the content gathering/writing. Having been in the web arena for over ten years and speaking with dozens of colleague firms along the way, a recurring theme of missed launch dates is the failure of well-intentioned clients to provide their content. This goes for small firms and Fortune 500 alike. I like how the author weaves content and IA related accountability through his process. We’ll certainly be doing more of this on our end. Cheers!
CAT EYE: Thank you for your input. I do, however, disagree. I’ve read your post over and over and it comes through (to me) as though you’re not used to working on very large or complex problems. Please correct me by explaining an example so that I can better understand your approach.
In Web application (read: web applications that people are selling online), IA is huge and it takes a while. I’m not actually only referring to content when I discuss IA, but, rather, a very exhaustive process up front to uncover as many workflows and functional requirements as possible so that you’re not retrofitting critical pieces later on (which as Robert Simmons rightly points out is quite expensive).
Re: use cases, the idea that you wouldn’t want to have them because an engineer wouldn’t properly use them or wouldn’t care to is actually pretty surprising and slightly defeatist. Here’s a thought: How about the IA and the designer do an incredible job laying out the entire system in both visual and black and white deliverables so that the engineers’ job is easier. That way, the use cases become a reference, not something to which you fall asleep or misunderstand. (By the way, there are some engineers who have read this and may also disagree and feel somewhat slighted.)
Here is where the truth hurts: BIG design up front saves BIG money down the road when working on BIG projects.
If you’re on a smaller gig, then that’s fine as well; IA still has an important role. In the article I mentioned that you don’t need to use all the outlined deliverables.
Re: how boring a process it is…
If you go into any situation with the mentality that it is boring, then boring it will be. Make it fun. It’s a challenge to get some clients to focus, but that doesn’t mean, especially in the creative field, that you can’t find a pleasant way to execute a task.
Re: costing too much…
Again, don’t try to sell the whole thing if the client doesn’t need the whole thing. Use the pieces that fit the project. Try adjusting the deliverables to be at a higher level. That way you don’t give up the quality while saving costs.
@Keith LaFerriere
I know that the method you described is a good practice and i wrote the comment just to let people think about the arguments that you will encounter from colleagues and or clients that does not want a structured way of working.
Nevertheless it is not complete nonsense. The reasons i summed up are in some circumstances fact very valid. But that is why software development is an craft and not art or a job. It is finding the perfect balance between the demanded requirements and realizing also non required functionality (like performance, security or usability).
The approach you mention can be very dangerous in wrong hands. Software development is not following a template and filling in the variables. It doesn’t also make a difference if it is a big project. (How can one determine big? Amount of functionalities (google search is 1 functionality and is big) or the lines of code?)
Think about the process you want to follow and don’t use silver bullets.
I take a view somewhere in between Cat Eye and Keith.
The 1/10/100 argument about getting all the IA sorted before design (and especially before development) is very strong; I work in a mid-sized web agency and our biggest problem is change control and clients saying “I didn’t realise it would be like this.” Of course, establishing a detailed, signed-off scope early on is crucial.
However, there’s two problems:
#1. Many of our projects, including big ones, are on a very tight timescale. Drawing up all of these documents and getting them signed off (often by multiple stakeholders who need to feedback etc) will simply take too long, even if it saves us some time downstream. We merge some of your separeate documents together, particularly the first stages: (content survey / map / audit / scheme / map / nav schema is all in one “Content Outline and Site Map” doc)
#2. Most of our clients simply don’t know what they want. Cat Eye’s point about them just giving over content or finding it in a survey is relevant here. If you imagine that there are no client SME’s.. how can we insist that they complete and sign off many of these documents? Together we might well be guessing about personas, so how useful does this process end up being? Depending on budget, we may do a simple design first so that they can discuss and decide around a visual thing rather than writing up a more abstract document.
Really useful article and discussion, thanks all!
James
Didn’t realise that pound signs did that to the formatting! Sorry, please edit if you can.
JAMES BROWN: Thank you for your comments. A good point to mention: a lot of these deliverables can be worked on simultaneously and sign-off is made easier by having the client engaged in the process. Combining structure documents is a great idea if your client is willing to sign off on that much data at once. The only caveat being if you’re in a second phase and the designers/developers are waiting for the next batch of wireframes, but they’re being held up due to another document.
Regarding content from SMEs / non-SMEs and surveying: I’m going to be an oak tree here. I believe it’s our job to teach them this process and to engage them in the value of GREAT IA. It’ll save them money in the long run and it will bring out content that they never knew existed (but need in order to help their cause).
Keith:
There is no doubt you know your stuff. I love the idea of this process and your ability to clearly explain each deliverable is why I’ll bookmark this article for basically the rest of my career.
I’ve gone through and read all three of your articles and I’m impressed with your breadth of knowledge.
One thing that I think was mentioned before are examples. I’d love to see this article be expanded. Part II, perhaps? ALA, are you hearing what I’m throwing down?
Anyway, thank you for the resource.
As a former web developer who has also held the title of information architect, I enjoyed your article very much. However, I’m putting on my current hat of origami illustrator for my comment.
While I appreciate the illustration by Kevin Cornell, I’m disappointed by his utter lack of knowledge of origami. The bird, which I can only assume is meant to portray the traditional origami crane, bears only superficial resemblance to the actual origami model. Worse, the crease pattern shown under the bird not only does not match the bird, it is impossible to fold.
It is ironic, and a bit sad, that an article that talks about doing things properly features an illustration that says the opposite.
This article touched on all the fundamentals that go into a proper IA. If you’re building sites properly, you should pretty much know this stuff already.
bq. This is totally a wrong approach. It assumes that the client knows what he/she wants to present (in the real world there are no clients that say: “Hey this is my content, please make a website of it!) and assumes also that this can be defined by a survey.
I am assuming that Mr. LaFerriere didn’t imply that you should skip Discovery and go straight to IA. And for that matter, part of proper IA is Content Development.
bq. _If you imagine that there are no client SME’s.. how can we insist that they complete and sign off many of these documents? Together we might well be guessing about personas, so how useful does this process end up being? Depending on budget, we may do a simple design first so that they can discuss and decide around a visual thing rather than writing up a more abstract document._
There is nothing “abstract” about IA. Jumping straight to “visual design” is just the wrong approach. How are you suppose to understand the depth and complexity of the project and make proper decisions without blueprints? Also, there is no “guessing” in proper web design. You need an answer, you ask the right question to the right audience.
You will find that most clients have not been through a proper web design process before (Discovery/Strategy, IA, UI Design, Production, and Launch and Post-Launch). _Part of your job as a web designer is to help educate the client._
Proper web design takes time. And it takes money. Don’t cut corners. After all, you wouldn’t build a house without blueprints?
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.
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.
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!
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…
-Jonathan
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.
On HUGE projects though, sure thing.
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!
I have found continuous education of my employer a bigger part of my job than the actual job! Does anyone else have this experience?
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.