Using Information Architecture, Examples and Samples 2/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.
HTML skills
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.
Targeted audience
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.
Turnaround time
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.
Staff workloads
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.
Budget
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.
Project/System Use
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.
Example 1
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.
- User Profiles
- Content Inventory
- Sample Use-Case Scenarios
- Web Site Map
- Paper prototypes (documentation of testing our IA assumptions)
- Detailed website wireframes / story boards
- Mockups
- Web style guide
- HTML designs and .CSS
Example 2
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.
Example 3
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.
|
