Daniel Brown | Plot the Web course
- By Joab Jackson
- Nov 14, 2006
I think what we're seeing these days is Web sites [managers] trying to be much more incremental in their changes.'
Web site development documentation might not seem the most exciting of topics, but it is one that developers keep returning to, says consultant Daniel Brown. He may have a point. Although only released in September, his book, Communicating Design: Developing Web Site Documentation for Design and Planning
, (New Riders Press) already is generating buzz in the federal Web development community. The book outlines 10 forms of documentation every Web developer should be aware of, from site maps to wireframes (basic drafts of Web pages). In addition to his consulting duties, Brown also helped start the Information Architecture Institute and is involved in chapter meetings in the Washington area. We spoke with Brown about government, Web usability, information architecture and his new book.GCN: Tell us about your government experience.
Brown: I was a federal employee for about two years at the Transportation Security Administration, and then I was contractor for the Postal Service for about a year and then I worked as a contractor for the Federal Communications Commission for little more than a year.
When I was a fed, I was more of a project manager. I was responsible for helping stand up the agency's content management system. For the Postal Service and FCC, I was doing more generalized information architecture and user-experience work.GCN: In your blog, you talk about how you still see 'old-school usability' in government. What is that?
Brown: In my mind, old-school usability is something that we are still doing today, and it is only more recent advances in Web technology that allow us to rethink how usability is done. When I say old-school usability, what I mean is putting a bunch of users in front of a prototype in a lab, then cataloging the observations and making recommendations based on those observations.GCN: It sounds awfully expensive and time-consuming. ...
Brown: I think the hard part is that it takes time. I think what we're seeing these days is Web site [managers] trying to be much more incremental in their changes.
They try to change [their sites] a little bit each day. They are trying to respond to the user community by actively soliciting feedback. You see this probably most explicitly in this notion of perpetual beta'a Web site that is constantly undergoing changes and keeps forums open to allow people to post comments.
I think we can take this a step further. Technologies [that allow us] to follow our users' behaviors online explicitly, and hopefully do real-time testing are becoming more and more inexpensive. [With these approaches] we can test two or three or four different variations on a page.
Right now, you see this only on massive Web sites, such as Amazon. You go to the site and suddenly the product page looks different. It is clear that they are testing a new product page. They get enough users where they can make strategic decisions based on data from simple traffic.GCN: So is there a fundamental difference between working on a government site and working on a corporate site?
Brown: For me, the most interesting thing to think about is the government contracting process. At its fundamental level, government contracting is about which budget is money coming from to pay for an endeavor. Modern Web sites try to break down organizational silos, and yet at the very fundamental level in the government contracting process, we see these silos in effect.
This is something that happened to me at TSA. I was building systems that served the entire agency and yet it came out of my budget. So I was working with limited resources. It seemed like a system that was fundamentally set up to not encourage that level of collaboration.
In the commercial sector, you can say this is coming out of my budget, but it basically serves the bottom line. It is a lot easier to build momentum that way.GCN: Why write a book about documentation?
Brown: What I wanted to do with the book is fill a niche that I didn't see filled. We see a lot of books about the Web design process, project management and creative management, but what I have not seen is a book about the artifacts that emerge out of that process. Whenever you do some shop talk, the first questions are, what kind of deliverables are you working on, what your site maps and wire frames look like?GCN: What are the biggest mistakes people make in Web site design meetings?
Brown: I think there are a couple of things that happen. [The biggest mistake might be] moving too quickly to design. [You're moving too quickly if] if you don't have a common understanding of who the users are and if you don't have common understanding of the purpose of the Web site. It is very tempting to start documenting Web pages on a white board, but if you haven't thought through the foundation stuff yet, there is really no point to doing it.
Another mistake people make is they go in very emotionally attached to their designs. I think everyone in the meeting needs to bring a certain emotional detachment to it, because there is something valuable about the collaborative process. Good ideas emerge when people work together. What will happen is the designer will walk in and be so married to work [already] done [that he or she would be] unwilling to hear new ideas from a documentation point of view.
And from a documentation point of view, we see designers are more attached to the documentation than to the overall purpose of the project.GCN: What is information architecture?
Brown: The best way to think about it is that IA is the underlying structure of the Web site. It lays a lot of work for Web design. There's always a need to look at how the content is organized. There is [always] more and more content out there. If you take a snapshot of an information architecture, it will never be able to accommodate the months and years of content that is going to come.
Joab Jackson is the senior technology editor for Government Computer News.