the Design Experience Weblog Archive

I was reading the Polar Bear Book and just starting thinking about their various definitions of information architecture. I like the definitions about the goals or IA, that is, making it possible to find and use the information you need. This is somehow related to knowledge management, besides being a buzzword, of course.

IA stresses categorization, and metadata, usually of a more formal nature. And KM also has some of those aspects. I would like to see how to take more organic techniques for finding data such as Google, tags, and RSS and make them fit into the concepts of IA. Knowledge management seems to have a little more thought in this direction, in the area of Personal KM, usually related to weblogs, and more now with e-portfolio type applications.

I searched for "information architecure knowledge management" and found a course of study with the same name. It seems to combine library science, computer science, visual design, and communications. I'll have to explore that some more. I like the idea of combining visual design with the other subjects. This reminds me of Edward Tufte and the basics of designing information visually.

John Hiler at Microcontent News gives a great overview of the evolution of hierarchy vs. search for finding information. I have been thinking about this since I read The Inmates are Running the Asylum.

Well, really I have been thinking about it since I have had to organize large amounts of email. When I started filing things in folders, it was a pain to find something. Once I saw gmail, I adapted that model to my IMAP email with mutt. Now I have everything in my inbox, over 3000 items now, and search. It is still working fine. Maybe its not the best solution but it works for me.

Adapting these ideas to content management, organziation, and findability of web site data, I have been using search, combined with categorization, and other metadata filtering of search results. I think this is a good way to go, but the trick is figuring out what metadata is useful, and how to present it in the user interface.

Dan Brown writes about the underlying model behind CMS products, taking into the the concepts of workflows, roles, etc. He says the models are an Idealized Cognitive Model. The model resembles a factory. We can do better if we model a CMS to work like real people do. This is a great opportunity for Open Source content management to fill a need that real people have. Instead of modeling the content authoring and editing process around the coporate hierarchy, model it around the real process of real people writing. This is obviously why weblogs, and the models they are based on, are so popular.

I have been thinking about this in much simpler terms in the back of my mind for a while now. The first assumption most CMSs make is modeling the site in a hierarchy of folders. This works for people who understand hierarchal filesystems, which if you read "The Inmates are Running the Asylum" is not everyone. How can we model the structure and organization of content, and the authoring process, around how people think about their web site. I have a feeling its a combination of tags and some yet to be discovered organic metadata that doesn't look like metadata to the content authors.

I realized the main difference in the approch of Interaction Design and Agile Development. ID assumes the cost to change software once it is written in very high. Agile processes are defined precisely to reduce the cost of change, and that is how it can work closely with direct customers, and do more, and smaller designs. Basically it takes the 1 year design, 3 months coding schedule of the ideal interaction design project, and shortens it to an extreme. The other big difference is that Agile allows coding during design. Agile also says that each interation must be able to stand along as functional software. With such short design and programming phases, it is possible to do a good job, just on a much smaller pice of software.

I still haven't figured out how Agile can support integration of a huge application from all the pieces. It seems risky to design one feature in the first iteration, and expect somehow that the interaction for the users will integrate with the whole application, and not change dramatically. I think changing interfaces is a huge training and probably morale problem, even if the changes are improvements. So this is a place where I think ID really has the advantage. I know there is still more to learn.

I am thinking more about interaction design and agile development, and how the ideas connect between them. One theme in The Inmates are Running the Asylum, is that the goal of design and development is to build a product that many people will be delighted to use. This product will not do everything, and will not be for everyone, but it will do what it does very well.

Constrast this to Agile development, often used in custom software development, works directly with the people who will end up using the software. I think the idea is to give these people exactly the software they need.

I was thinking about the differences between Interaction Design and Agile development. One interesting point Alan Cooper makes is that the people who will use the result of development are not skilled enough to know what the best design is. Instead the interaction designers invent personas that represent the attributes of the most important users of the final product. One disconnect between the ideas of interaction design and Agile is the goal of product based development vs. custom development.

When you are developing software as a product, you don't know who will buy it, so you need to come up with some ideas to develop towards. With customer for-hire software projects, the customers are the people who will end up using the software. I think the idea of an expert who has good suggestions for how people will interact with a system to get their jobs done is great, but I am not so sure this expert should be all alone, designing without the people who use the system, or the people who will build it.

Strategy by Design by IDEO's Tim Brown, discusses how thinking about design can improve planning and strategy for business. I like how the ideas fit into Agile software development.

It's a process of enlightened trial and error: Observe the world, identify patterns of behavior, generate ideas, get feedback, repeat the process, and keep refining until you're ready to bring the thing to market.

Product design doesn't map one-to-one with Agile software development, but I can see parallels. I especially like the idea of "elightened trial and error." One place that Agile software development differs from the ideas in the article is the concept of prototype. A prototype is a quick design experiement to stimulate the imagination and get more ideas. With Agile development, the idea of throwing away the steps of iteration is gone. You plan to keep the results of every iteration and build on it. So each step is complete as it can be, as a part of a whole.

Following a recent discussion around Don Norman's recent rebuttal of Edward Tufte's opinion on Powerpoint, I found Beyond Bullets, a weblog and book about better communication. The site provides free templates to help you organize you thoughts and presentation more effectively.

There is even a discussion board. I found a thread about planning for training which turned into a thread about organizing using mind maps. The secret is figuring out the starting point to organize the story around, using a mind map.

To me the critical decision is what to put into the "center". When you put Laura's solution statement in the middle, the whole thing becomes a very clear, coherent, and scalable story.

I definitely need to learn more!

I'll just link to this google search and go through the links later. As usual, so other folks have some thoughts on how Interaction Design and Agile might fit together.