Boxes and Arrows: Comments by Henrik Arndt

Henrik Arndt — Fri, 17 Aug 2007 22:27:10 GMT

What information architects demand of a good website they should do themselves: Structuring and presenting information in the language and style of their target group (the client) and not insist on their own language and structure. If business people can understand what they get for their money, they pay for information architecture.

Great interview.

Henrik Arndt — Wed, 12 Sep 2007 19:04:52 GMT

I can open a bottle of beer with my gaspipe pliers. But why should I? If I wanted to open a bottle of beer, I’d use a bottle opener, even if I am able to open a bottle with many other things (and even if that would look much cooler).
Of course I can prototype a website in Powerpoint, as Maureen explains, or in Acrobat, as Kyle demonstrates. But why should I? If I wanted to prototype a website, I’d ask a programmer to adapt my scribbles, wireframes or layouts into code. That does not take much longer than building a prototype in Powerpoint or Acrobat (the larger the prototype, the faster the programmer compared to me prototyping with Powerpoint or Acrobat).
Programming prototypes has so many advantages compared to Powerpoint or Acrobat. Changes can be made much more easily (as only the altered element has to be changed, as opposed to all touched pages). Many things beyond the UI can be tested (e.g. if the navigation can be implemented with the CMS as planned, or if the data from a database can be filtered and presented as intended).
If I only want to have a quick feedback on a few pages I’d show (or test) wireframes (non-interactive). These does not present less information to testees or clients than those “You-only-can-click-here” or “This-page-is-not-available-in-this-prototype-please-go-back-to-previous-page” prototypes.
Let the programmer prototype and in the meantime work on your next project.

Henrik Arndt — Wed, 08 Aug 2007 11:42:26 GMT

Thanks Kyle and Terry for considering my comment.
Maybe I wasn’t clear enough, so I’ll elaborate: If a programmer codes a part of a website or a webservice as a prototype it does not mean that it looks (or is) finalised (especially if a CMS is used). There is to all intent and purposes no difference between the appearance of the coded prototypes that are used in my projects and the wireframes that are shown in this article. The problems that can appear if a seemingly finalised layout is tested or presented too early in a project have nothing to do with the decision to code a prototype. But none-the-less, coded prototypes are faster and cheaper to build and in many cases the code can be used in the final production.