Originally published February 2006
In part one of Web Information Architecture Deliverables and Diagrams I discussed the various deliverables and diagrams that are commonly used throughout the industry. In part two we take a look at the factors that influence the use of these deliverables and various implementation examples.
Understanding how to create information architecture deliverables is the easy part. Sure, creating documentation for large scale sites with complex functionality can be very challenging and tedious. But it takes additional expertise and a lot of trial and error to develop an understanding of how to best apply these deliverables. There is no magic formula to decide which deliverable or combination of deliverables to use. It takes a lot of experience to know when and how to best utilize the various deliverables available. This document takes a look at some key variables that should influence our decisions.
Access to programmers
Ideally designers, information architects, and programmers would work together closely as a Web site is built and refined. However, this isn’t always possible. I have been involved in projects where I was responsible for the requirements analysis, information architecture (IA), and design. But the actual coding was turned over to a set of programmers in another division or organization. Or perhaps conflicting requirements on other projects prevent you from maintaining regular contact with the programmers. In cases such as these it is important to create detailed documentation to guide the development. There may or may not be an open line of communication between the people that created the deliverables and the developers who are now responsible for developing from it. In the world of Government contracting this transition isn’t uncommon among separate contractors. Basically you can’t assume that the programmers will interpret your deliverables the way you envisioned, and you can’t assume they will be able to get clarification form you in the future. You need to explicitly describe how the system is designed to be implemented.
Programmers with design skills
Obviously the individual skill sets of programmers vary greatly. Some are former engineers or scientists with little or no design skills or artistic eye. Others may have once been designers, graphic artists, or just have been blessed with natural artistic ability. Some programmers may have a good understanding of Web usability, others may not. Senior developers may have enough experience to adhere to general design and usability guidelines that junior developers may not recognize. It’s important for you to recognize these characteristics. You need to understand the skills of the programmers you work with and customize deliverables accordingly.
It seems most Web programmers fall into one of two categories. The first group is part developer and part designer. The other sees things in black and white and will program exactly what is given to them. Once you are familiar with the design skills of the developer(s) you can cater your deliverables to match their needs. In some cases basic wireframes or flow diagrams may be enough for a programmer. It doesn’t take much time working with a programmer to ascertain whether they are capable of taking a rough design or wireframe and creating an effective interface from it. Some developers will program to precisely meet the requirements, but are incapable of injecting their own design elements. The key is to communicate the relationship and roles. If a developer has general design skills, then it may make sense to give them some freedom.
In some cases it may be the designer, and not the programmer, who is best suited to create the initial HTML for a site. It’s important to recognize that a designer’s or IA’s involvement doesn’t necessarily have to end with a site map or Photoshop mockup. Often it makes sense for the designer to be responsible for creating the HTML templates. Again, it comes down to recognizing and capitalizing on the skill sets of your team. In an ideal situation, and when I have enough time, I prefer to turn functional HTML over to a developer and let them do the “real” programming.
It’s always important to understand who the audience, both the primary and secondary, for the deliverable you are creating is. You may be putting together a story board with detailed wireframes for the programmers, but the document may inevitably end up in the hands of management. Thinking about the documents possible future uses can help. Adding additional documentation about the purpose and/or intended audience for the document can help add context. On a project with frequently changing requirements a good approach would be detailed wireframes with enough documentation for programmers, clients, project mangers or anyone else involved.
How quickly are these deliverables needed? In some cases there may only be time to sketch out rough designs on paper (paper prototypes) and put together general work flow diagrams. In other cases there may be time to put together detailed wireframes, and in other instances time to create HTML designs for the programmers to use.
There is usually a tradeoff between the workload of the designer/IA and the programmer. High fidelity designs and documentation require less overall effort for programmers than if they were given basic requirements and design specifications. If the programmer is given HTML they won’t need to spend time on layout and design. So whose time is more valuable? Who currently has the most on their plate? On a tight budget, who has the higher hourly rate? These types of questions should ultimately determine where the handoff lies.
Perhaps your group or company has been tasked with creating the design and/or information architecture for a Website. The actual development, testing, and implementation will be handled by another group. The fixed budget for your portion of the work has been set. Depending on the budget you will either have to deliver low-fidelity (wireframes, process-flow, etc.) or high fidelity (detailed story-boards, HTML) deliverables. Obviously the latter requires a greater level of effort and expense.
What type if system is being developed or who is it being designed for? If it’s a non-critical internal system designed to be used by staff, then it may be ok for the programmer to work with basic requirements. Obviously you never want to implement a system that sacrifices usability or accessibility, but it may be ok to deploy these types of systems with a less polished design. Websites that are higher profile (e.g. Corporate Websites, Large-scale systems) should be given additional attention. It’s important to keep tight control of the design and information architecture. Programmers should be working from detailed requirements so they don’t have to make design decisions on their own.
Familiarity with developers
If you regularly work with the same group of programmers over time you will learn their tendencies and individual skill sets. You may have developed a level of comfort with programmer A that allows you to hand them some basic flow diagrams and design specs and have confidence that they will be able to work successfully from them, making appropriate modifications where needed. However, programmer B may need precisely detailed deliverables or HTML design templates, or else the final product will suffer.
Now let’s take a look at some real world scenarios and the information architecture deliverables I would likely use in each.
My company has been asked to provide consulting services for a client that needs to design and launch a large new corporate Website. The organization has an IT group that will develop the site, but is looking for some outside expertise in the requirements analysis, design, and information architecture. They will be paying us on a cost (time and material) basis and have a relatively large budget set aside for our services. They want to spend the money up-front to get it done right and avoid costly redesigns in the near future. Fortunately the schedule isn’t overly tight and there will be enough time to do the work the right way. The work that I deliver on this project is a reflection of our company’s capabilities and will potentially lead to future work with the client. Therefore, I am going to spend additional time refining and “prettying up” the deliverables. Since the deliverables will be handed off to another company, they will contain extensive documentation and comments. After working closely with the client to determine requirements and establish target audiences, I decide that we will create the following deliverables.
I have been asked to assist another division in my company with the redesign of a website for a client they are currently working with. Let’s assume the budget they can commit to the design and architecture is enough to cover detailed wireframes and site mockups, but not enough to cover HTML designs. Fortunately they have a junior developer with good design skills who can effectively (and affordably) turn the wireframes into a fully functional Web site. I won’t be in close contact with the developer once I have handed off the wireframes, so I will make sure to add a lot of notes and documentation on the wireframes.
My group was awarded a new contract to develop a Website for an existing client. The timeline is very aggressive so we need to get moving quickly. The site is pretty basic and doesn’t require a lot of requirements analysis. The developers I will be working with are in my group so we will be working closely together as the project moves forward. I am already familiar with the skill sets of the programmers and their existing commitments on other projects. Therefore I determine that the quickest and most effective use of my time will be to sketch out some rough designs and put together some basic wireframes. I will use these to make sure the programmers don’t have any problems with the proposed functionality, and to get a quick buy-in from the client. Then I am going to build out the HTML for each major page or section. There isn’t a need to build out every page, just the ones that are unique. Once the HTML designs are finished the developers can quickly add their code and database connections, or break the pages up into includes or database elements. This approach gives the programmers a good head start and reduces their required level of effort.