design::writings
Using Flowmaps (Powerpoint file) :
Presentation from the 3rd Annual ASIST Information Architecture Summit held in Baltimore this past March. I was on the panel about Deliverables with Dan Brown, John Zapolski (pdf preso) and Jesse James Garrett.
I presented the process we use to create our large flowmaps at AOL and showed some examples of the maps in action. The important thing to note is that the map is a tool that is used for collaborative discussions and solutions with the other team members. The presentation shows examples of the map in use by the engineering team as well as what happens to it through the life of the project.
Project Process Diagram (PDF file, 25k) :
This diagram visualizes the project process cycle
that my User Experience Design team at AltaVista used when working
on new projects. The diagram shows the roles, responsibilities and
deliverables for the team across a timeline of sectioned steps in
the UE design process.
One of the important things about this diagram, is that we developed
this process in conjunction with other cross functional team members.
The process also shows the iterative loops and interactions with
other main team members - Usability, Product Marketing, HTML and
Engineering. There are other groups in the cross functional team,
but for the purposes of the design cycle - they are minimal in terms
of interaction and influence over the design process.
We found this visualization helpful in defining roles and responsibilities,
especially in groups with overlapping skillsets (IA and Usability)
and also helpful to upper management to describe the process of
collaboration and handoffs. My team consisted of Information Architects,
UI designers, Visual designers and Technical Writers. The breadth
and depth of our skills and responsibilities is reflected in the
main body of this diagram. For some organizations, this center section
could be divided into two - with IA separated from design - but
I personally feel, and built my group to reflect this, that IA is
part of the overall design process and shouldn't necessarily be
separated out. (our team experienced this for a couple of months
after a reorg and it was a disaster given the skills and talents
of the group)
This process diagram does not have any assigned timing to the sections
and was intended to be a telescoping process - moving and adjusting
depending on the overall product lifecycle.
I believe this diagram (or variations of it) can be a useful tool
to the design group in many types and sizes of organizations.
Userflow, Wireframes, Process Samples (PDF file, 291k):
This PDF file shows examples of the AltaVista registration
process* development documents. The initial user flows were sketched
out then presented to the development team. Handwritten notes and
annotations were made on the userflow. Then the files were updated
and suggested or required changes made to reflect the discussion.
This process happened a few times as technical requirements were
settled on and the developers were more clear on what could and
couldn't be done in the time frame. From there, each block in the
flow was scoped out as a wireframe diagram of the page. Functionality
was clearly exposed and text as well as basic layout decided on.
The wireframes also went through the same iterative process. User
testing was done with wireframes. From this point the visual designers
could start with the design and in some cases, layout was offered
as different points of emphasis were explored. The last screen shows
a final screenshot of the shipped product.
This presentation was given with lowtech paper examples at the 2000
Advance for Design Summit in Telluride, Colorado. All participants
made presentations and several are available on the Advance site.
*This functionality is no longer on the AltaVista service, and I
am no longer employed there.
What
Is An Information Architect (PDF
file, 8k)
What We Do
(PDF, 6k):
When I was at AltaVista, we struggled with the definition of Information
Architecture. We KNEW what IA was and our team was a nice blend
of MLS people, UI people and writers turned IAs. We worked well
together, thought about the user, slipped in some guerilla user
centered design processes and everyone was happy. Then Marketing
people from another division got involved and they knew no more
about IA than rocket science. We then had to go through a whole
explanatory phase. This involved definitions as well as benefit
analyisis of our work with real world justifications as to why that
extra 2 weeks in the schedule was needed for IA and couldn't be
skipped by just jumping to visual design. It was frustrating. We
were no longer happy. So we set out to conquer and educate.
What we did was come up with some documents to help. The process
doc (at the top of this page) helped show where we fit and how we
interacted with other teams. But a definition was required as well.
I wrote up a short one pager that described what the role of the
IA was at AltaVista and what we did. This helped some more.
Then a staff member of mine took those highlights and rewrote them into a onepage document that was short, to the point and also mentioned cost benefits to our skills and expertise. By the time we got to this sheet we were a larger multidiscipline team (IA, UI/interaction, graphic design, technical documentation) so we covered several slots on the process document. This sheet along with the process document became a regular set we handed out whenever we started work with a new group.
