As information architects attempt to carve their niche in the world of web design, they are forced to balance the needs of several disciplines at once:
- Clients require their business objectives be met;
- Engineers require designs that do not exceed technical limitations;
- Visual designers require specific skeletal work, but not direction;
- Quality assurance teams require infinite detail;
- And project managers require everything to take shape within the scope of the project.
All of these considerations must take place while keeping the goals and needs of the end user in mind. Once requirements have been gathered and features defined, IAs use a primary tool to fulfill these specific needs: wireframes.
As wireframes have such a varied and diverse audience, both internal and client, the format within which they are developed has been an often-debated topic. Currently, there are two primary schools of thought on this issue. One touts Microsoft’s Visio, a diagramming program available on the market since 1991. The other firmly believes in HTML-based wireframes (also described as “high-fidelity prototypes”). While the two schools are not mutually exclusive, an individual IA tends to settle on a preferred method and work with it as much as possible.
(Author’s note: While there are other wireframing options such as Microsoft Power Point and Norpath Elements Studio, the two techniques described in this paper are the most often used. As the popularity of other techniques grows, their merits will need to be compared with the status quo.)
As design organizations (design shops, user experience groups within companies, etc.) mature, they inevitably run across the debate of Visio versus HTML wireframes. The decision for one over the other is never a clear-cut one since, as with all things IA-related, it depends. This article seeks to sort out the issues in this debate by describing the pros and cons of each technique and pointing out specific situations where one may be more effective than the other.
Pound for pound: The contenders weigh in
Interactivity
The greatest and most obvious benefit of HTML-based wireframes is their interactive nature. The web application can “come to life” in the form of these clickable wireframes. The development team has the opportunity to click through a mock-up of the site, allowing them to make quick determinations about issues with flow and navigation. The client has the opportunity to view an early version of the site and determine whether it is going to meet their business objectives, as well as whether they have the resources to populate all the proposed features with valuable content.
Sean Gallivan, creative director at Braun Consulting, notes, “Clients become engaged when they can interact with HTML wireframes. Clients not only enjoy the process more, but they also get a better contextual understanding of the features than with paper prototypes. This understanding gets earlier and more complete feedback.”
Visio, though a static diagramming program, has attributed its increased use in the web design community to its hyperlinking feature. Any element on any page can be hyperlinked to any other element or page within the document, to an external file, or URL. Additionally, Visio has the ability to export the entire wireframe deck to HTML, allowing developers and clients to click through a Visio wireframes set fairly easily.
Working with visual designers
HTML-based wireframes can cause some real problems in the development process. Most important is the issue of setting the client’s expectations about how the final application (or site) will appear. Wireframes, by their nature, do not dictate exact screen layout. They imply hierarchy between elements and suggest screen layout but, ultimately, it is the visual designer’s skill and talent that determines the final “look and feel.” By developing high-fidelity prototypes, the IA can inadvertently bind the designer into a screen layout that the client has seen in the wireframes. This can result in a less than optimal design and cause strain within the development team.
It is an often-held misconception that developing wireframes in HTML will allow the team to see what elements of the design end up “above the fold.” As wireframes are intended to show the skeleton of the application and not the full graphics-intensive version, making this determination based strictly on wireframe presentation is premature. Costly redesign decisions can be avoided by saving judgment on this issue until the visual designer has had a chance to exercise his/her skill.
The basic appearance and geometric nature of Visio diagrams help limit the client’s expectations as to the final layout and design of the application. By not having a mental picture of what the site will look like, the client can review the visual design in an objective manner. This leaves the creativity with the visual designer, as blocks and shapes representing specific page elements do not dictate a certain look and feel. The ability to quickly shift these elements around the screen also offers a flexibility not found with HTML wireframes. All of these elements combine to form the true essence of what wireframes should be: the skeleton of the application.
Client review
Often, a client likes to take deliverables with them for review when they leave the office. Even with today’s paperless trends, it is still very convenient to review wireframes on paper. This allows careful studying of the prototype without the exacerbated eyestrain caused by long-term monitor fixations. Also, writing notes directly on a specific wireframe is a convenient way to convey edits and suggestions. HTML wireframes do not print in a fashion that guarantees a complete wireframe will fit on one sheet of paper. Usually, the page breaks occur at random points and cut off content midstream, encumbering the review process.
As a diagramming program, Visio behaves within the context of printed “pages.” Because of this, designs can be constrained to one page or a deck of pages. Each page can be developed to contain the information for one screen of an application. This allows for easy presentation and review of wireframes. Pages are noted by either their name or number and follow a sequential order determined by the author.
Visio allows for clean, logical printing of the wireframes. Each page equals a screen. This allows clients, both external and internal, to print a wireframe deck and review it on the road, against the development environment or as a final QA assessment. Notes can be written directly on the printout and handed to an IA for modifications.
Exporting is another strength of Visio. While Visio does not exist on every desktop or in the Macintosh world, the myriad of formats that can be generated from it provide more than adequate coverage for any conceivable file format need. These formats range from HTML to PDF (with Adobe Acrobat Distiller) to EPS to JPG.
Maintenance/iteration
Using popular development tools such as Macromedia’s Dreamweaver, information architects have the ability to create site templates that function as shells for pages of similar type. These templates can be configured to contain a consistent area dedicated to screen-specific information. Elements such as screen title, version, author, page logic notes, and callouts can be listed in one convenient location. This section, however, can be very distracting when the prototype is used in a usability test. Removing this section would require recoding all the templates or creating a duplicate set of wireframes without it.
Templates also allow the IA to make global updates to various screens that share the same template. The main drawback here is that there is no way to create a global template. In a situation where a change needs to propagate throughout a site, each template must be updated to reflect the change. Occasionally, this problem can be solved using a global “find and replace” feature, but this is not always the case.
On the issue of maintenance, HTML files must be linked to each other in order to maintain their interactive strengths. This results in fixed filenames for each wireframe. As updates are made and versions updated, it is not possible to update the filenames with version numbers without adjusting the hyperlinks on every screen that links to it. Whether it’s for versioning or other reasons, a changed filename can become a tedious chore to update throughout an extensive wireframe set.
Performing some of the same duties as Dreamweaver’s templates, Visio additionally offers the concept of “layers,” which allows for templates to build on top of one another.
For example, the base layer can contain nothing but project information—project name, author name, file save date, copyright, etc. This layer can then be used as the background for another layer which could contain, for instance, global navigation elements. The benefits here are that each layer can be used individually or can build upon another layer. When a global change needs to be made, the appropriate layer is simply adjusted and the change is applied to all pages and layers using that layer as a background. There is no danger of editing the layers within each page as their elements are rendered uneditable.
Finally, as one becomes more expert with Visio and begins to use a consistent array of shapes and elements, a custom stencil can be created. This stencil allows all of the commonly-used elements to reside in one place throughout the design process. This provides a consistent palette for the IA to use when building similar applications (websites) and is a considerable timesaver.
User testing
The interactive nature of HTML wireframes increases the ease with which the site can be user tested. Participants have something with which they can interact in real “web time.” Micah Schwalb, Senior Information Architect at Braun Consulting, touches on this point by mentioning that, “By having low-fidelity mock-ups of the page built in HTML, we can quickly usability-test those models with our target population (or even people off the street) without having to spend the time to explain the concept of a paper prototype.” Transactional applications can benefit from this greatly, as test participants can give instant feedback on the process flow, and modifications can be made long before the project moves into the build phase. Specific implementations of features can also be tested to ensure the best mechanisms (drop-down menus, radio buttons, checkboxes, etc.) were selected.
The ability to export Visio decks into clickable image maps proves handy when performing early usability tests. Process flow and site navigation can be tested effectively, but Visio really shines when testing labels. Test participants often note the “lo-fi” nature of HTML’ized Visio wireframes and seem to focus primarily on labeling rather than specific content.
However, testing of Visio wireframes does not yield optimal usability testing results. The results that are collected need to be analyzed carefully and modifications need to be made cautiously because it is typically the flow and labeling that is being tested and not the entire user experience.
Notation
During the design process, it is often necessary to add descriptions to features with the use of notation. This notation bears direct relevance to a specific element on the wireframe and needs to be tied to it. HTML wireframes make it difficult to place notes at exact locations on the screen. While the actual “action” (e.g., drop-down menus) that HTML elements can portray solves this issue some of the time, there are other instances, such as length of text entry areas that need to be noted elsewhere. These notes would most likely be implemented in a “screen notes” section, where they lose their immediate connection to the item they describe.
Through the use of background layers in Visio, IAs can set aside a consistent area on each page dedicated to screen notes. This area remains constant and offers the same page logic elements described in the HTML discussion. Additionally, since there are no table-based constraints as there are in HTML, callouts and notes can be made directly on the diagram and visually tied directly to the element they are describing. For example, the contents of a drop-down menu can be clearly listed without the need for any further examination by using a callout tied to a drop-down element.
Process
Proponents of HTML wireframes believe that, if developed according to company standards, the HTML can be reused to build the actual site. This would require the IA to have expert coding skills that take advantage of the latest developments and trends in coding such as XML, XHTML, and CSS. However, by building a high-fidelity prototype that is meant to be the codebase for the actual application, the IA has less room to experiment with various architectures and ideas as changes could alter code marked for reuse. Again, the “screen notes” section could not be implemented as it would not be part of the final application. This would relegate any supporting documentation to an external document which would then need to be compared with the prototype.
On a different process note, Visio has a tendency to appear as an extra step in the process during smaller projects and within smaller user experience groups. This can cause some pushback from the client questioning why this perceived “extra” step is being done. It is important to remember that, in a small-scale situation, developers often wear many hats, leading to the potential elimination of this step. However, in a more robust project, this step is critical in conveying the needs of the client along with the needs of the user to the engineering and design staff. It ensures that all elements are accounted for and provides a tangible record of what will be developed before coding begins.
Accessibility
Accessibility of HTML wireframes is a non-issue since all one needs to view them is a web browser. While the clean-printing nature of Visio is one of its strengths, viewing Visio files requires the user to have the program installed on their machine or to export the Visio deck into one of many formats, some of which can subsequently be viewed in a web browser.
Context of use
So when do HTML wireframes work well? There are several situations where this technique can really shine. Primarily, HTML wireframes work well on smaller projects and internal projects. Projects that require minimal visual design or adhere to a corporate intranet standard can benefit from this technique as it will speed up delivery. Data-heavy designs with high information density can be better illustrated using HTML wireframes, and they allow developers to see flow and density issues early in the project lifecycle. They can also be used in conjunction with other types of wireframes to illustrate a particularly complex transactional process. Finally, HTML wireframes can aid resourcing crunches, especially if the user experience group is small or their resources are limited. One multi-skilled IA can often handle developing wireframes and site authoring, combining the two tasks into one.
Visio’s true merits surface in robust projects with a large screen count. It can efficiently and effectively convey the implementation of complex features and illustrate the flow of transactional components. When “webifying” an existing thick client, Visio is an excellent intermediate step when attempting to translate features into an HTML-based environment. It simplifies the review process for clients, allowing them the freedom to work at their convenience, while offering clear and concise design information. It is also well-suited for brand-intensive engagements in which the visual designer needs to exert more control.
Conclusion
The constant demand to produce a quality online experience drives us to create better processes for its development. This article discussed two techniques widely used in creating wireframes for web applications. While each has its own merits and drawbacks, it is the IA’s specific situation that dictates which one to use. As user experience groups grow larger within organizations, they begin to add refinement steps to their processes in an effort to add value to their deliverables. It seems that the bigger the UE group is, the more likely it is to tout the benefits of finely detailed, meticulous design. For this type of design, Visio seems to fit the bill more appropriately with its capabilities of detailed notation, clean translation to paper, and ability to create “layers.” In a smaller or more rapid-paced situation, the multi-faceted IA can make great strides by creating high-fidelity prototypes in HTML. Which technique is best for your current needs? The answer is, as always, it depends.
This is a useful and informative article Jeff, thankyou.
I would like to highlight one point you make towards the end and actually feel that, rather than being a Visual Layout vs HTML ‘prototype’ comment, the discussion of ‘context’ of usage of these tools is of far greater importance. (It’s been a long day today so apologies if my sentence structure is a little ‘squiffy’ ;-p)
On nearly all of my projects for the past 8 years, I have used lo-fi (scribbled post-it note style wireframes) and higher-fidelity ‘html prototypes’, plus the many myriad of hybrid solutions in between. On some projects I have used all these methods, on others just the one. It really does depend on the context of the project and the nature of the work.
You are right about the usability differences between the two however, and this is indeed a difference that should not be under-estimated.
Whilst ‘paper’ wireframes aid in initial problem indentification, and basic solution discovery, the results of nearly all of my user testing have differed quite considerably after transposing from flat ‘2d’ paper and into a more interactive/immersive screen environment. I have always found it useful to be itterative within both environments as this, despite being initially time-consuming, really stops some of the later pitfalls of development.
An excellent beginners guide though Jeff, and something I wish there were more of ‘back in the day’ ;-p
hehe.. err that url by my name in the above response isn’t mine, and is NOTHING TO DO WITH ME. I don’t have time for a personal site so just typed in anything. I didn’t actually know that that existed, so it wasn’t an endorsement or anything. This one is though. The BBCi homepage was my last big project.
(sorry about that)
I used to be a huge advocate for HTML wireframes, but in the last two years have reversed my opinion, for a few reasons:
1) Clients thought the HTML work was basically done after the wireframes, not knowing that I had done them as rough and ugly (code-wise) as I could.
2) Like you pointed out, Jeff, printing them is a pain. One trick: Make one master page that contains a link to all the other pages (which is, itself, a pain to maintain). Then, when you want to pint out a whole set of them (usually to show the client), under Print/Options in IE, check the Print All Linked Documents box. They will still come out pretty broken up, but it’ll save a lot of time.
3) Vanity. They look lousy in a portfolio. Seriously. I never got complimented on my HTML wireframes and my Visio ones looks infinately more professional. I lost a job over it, I’m sure.
4) Developers hate them because they have to leave their programming tool to flip through an HTML site to find what they are looking for, rather than just have a sheet of paper next to them.
5) Same deal with Designers. No one wants to hop out of Illustrator to see what a tab is named.
A cool article though, one I’ve been waiting to see for a long time.
Dan
Hmmm… I´ve been using for quite some time only Power Point Wireframes. I realy would like to see the looks and feel of a Visio Wireframe. Could someone send me an example? (leosarma@brturbo.com)
I agree with most of the article. But I would like to add some.
I think a Wireframe is a structure… a skeleton of a necessity. The technology that will be used when the end meets, realy, that´s not of its concern. I prefer not knowing anything of HTML, XML or FLASH, and concentrate on designing the user experience, flat and square, and having a great development team backing me up. They worry about all the other issues. I think our job as IA is extremely important and should be unique, not following any model at all. Those technologies blocks us on their usual limitations. I´ll come up with whatever is necessary… let them figure out how to realize our “visions”. And the web will evolve.
Here is an example of a prototype (it isn’t really a wireframe) done in Visio. http://petervandijck.net/portfolio5.htm or http://petervandijck.net/images/layout500.gif It was exported as a clickable HTML prototype. I know others have done nicer looking ones, and *real* wireframes (with less design elements).
I prefer doing my wireframes in Visio, because of all the reasons mentioned, but mainly because you can give things a distinct *look* that clearly converys this is *not* the website design.
Thanks for the kind comments. I wanted to address Leo’s points specifically (and send him an example).
1. Depending on how your organization’s methodology is setup, you may or may not have a detailed functional spec document. Some use use cases, others use separate docs. In my experience, it is a big pain (as Dan notes) to hop between applications or even printed documents to get all the information you need to develop. Therefore, I strive to place as much functional detail on the wireframe. This requires me to understand the technology that will go into building the application and I often consult a tech lead on the feasiblity of an idea that I have.
2. That being said, not everyone has a great development team backing them up and so we are forced to understand the technologies we design. Also, understanding these technologies allows us to realize, reach and push the boundaries of our interfaces.
3. Finally, I agree that IA is a unique discipline but it DOES need to follow a model. Even in a good economy we all switch jobs occasionally and need a certain methodology to follow so that our deliverables meet the needs of our current development team. Don’t misunderstand, I am not suggesting you quit using PowerPoint. If it works for you, great, but if it doesn’t deliver the kind of information your developers need to complete their builds on time and on budget, then perhaps I have given you a new method to use within the context of my article.
Thanks for reading!
[Jeff Gothelf]
hehe Dan,
All of your points are valid and ones which I wholly identify with.
Your first point about the client is an absolute reality, and something which I come across over and over again. But to simply move from paper onto ‘finished design’, without planning and mocking up web work in ‘vanilla’ html first has always proved really detrimental to my final work.
AND I have worked with clients who refuse to believe that anything planned/drafted/presented on paper (no matter how meticuously) can be in ‘any’ way indicitive of final design. Despite the fact that the basic interaction HTML models always look/feel ‘less finished’ than the initial screens from which their build is taken.
Perhaps what we really need is not an article on what tools to use, but on how best to teach the client the ‘ways’ of us; that we know best, and to trust us (even if our IA stuff consists of post-it notes connected with string) ;-p
Often I find that different projects require different approaches. Sometimes I use paper prototypes and other times hi-fidelity HTML wireframes. If you are presenting multi-layered information to the user and are having a difficult time envisioning how it works, often I find that using an HTML prototype helps me see how things could be put together or more importantly see where things beging to fall apart.
Nothing says you can’t do both, either. First, do Visio/paper wireframes, then do a more fleshed-out prototype in HTML to see how the navigation and page flows really work. Easier (IMHO) to do any user testing on HTML prototypes than with paper anyway.
Hi Jeff, Good article. Thanks. I concurr with most of your points. Once thing though, Visio isn’t available on the Mac, but OmniGraffle is getting pretty damn good for drawing wireframe diagrams. Definitely worth mentioning in the future for those die-hard Mac Information Architects out there looking for a decent wireframing tool.
Excellent article. I’d agree with most of the points, but do want to add a few items (corrections).
As the author points out, there are other options for doing wireframes and IA work. As shawn pointed out, there’s OmniGraffle for the Mac. OmniGraffle is scriptable and great for doing wireframes, IA, and visual mappings. Additionally, there’s Adobe Illustrator – my personal favorite. And like Visio, Illustrator is able to export to various industry standard formats.
I have used Visio in the past and find it to be like trying to draw using chalk on a paper bag on top of gravel. Illustrator gives you much better control, precision, and allows for the creation of beautiful sitemaps and visual diagrams – http://messagefirst.com/downloads/CLO_Site_Mapv1.2.pdf (276k). And of course, it isn’t for the Mac :(.
One correction to the article is that you can actually quickly move objects on screen in HTML – if you create the wireframes using CSS for layout, which is how it should be done anyway. Tables are for data presentation, not layout. Using CSS for layout allows the designer/developer to make one quick edit in the CSS file and viola – the object can change size, shape, placement, and appearance in no time. While you can’t necessarily drag and drop like you can in Visio, you can accomplish the same goal of quickly moving objects.
A have to agree that one of the biggest pitfalls of HTML wireframes, or any type of refined wireframe for that matter, is that clients can tend to interpret them as final designs. I’ve had it happen once or twice. And when it did, it was a nightmare. I had to explain 6, or 7 times that these were not final designs, but a wireframe.
All in all, paper “lo-fi” and HTML “hi-fi” wireframes and prototypes each have their place. Feel out your client to determine which one will be more appropriate.
Excellent article. I’d agree with most of the points, but do want to add a few items (corrections).
As the author points out, there are other options for doing wireframes and IA work. As shawn pointed out, there’s OmniGraffle for the Mac. OmniGraffle is scriptable and great for doing wireframes, IA, and visual mappings. Additionally, there’s Adobe Illustrator – my personal favorite. And like Visio, Illustrator is able to export to various industry standard formats.
I have used Visio in the past and find it to be like trying to draw using chalk on a paper bag on top of gravel. Illustrator gives you much better control, precision, and allows for the creation of beautiful sitemaps and visual diagrams – http://messagefirst.com/downloads/CLO_Site_Mapv1.2.pdf (276k). And of course, it isn’t for the Mac :(.
One correction to the article is that you can actually quickly move objects on screen in HTML – if you create the wireframes using CSS for layout, which is how it should be done anyway. Tables are for data presentation, not layout. Using CSS for layout allows the designer/developer to make one quick edit in the CSS file and viola – the object can change size, shape, placement, and appearance in no time. While you can’t necessarily drag and drop like you can in Visio, you can accomplish the same goal of quickly moving objects.
A have to agree that one of the biggest pitfalls of HTML wireframes, or any type of refined wireframe for that matter, is that clients can tend to interpret them as final designs. I’ve had it happen once or twice. And when it did, it was a nightmare. I had to explain 6, or 7 times that these were not final designs, but a wireframe.
All in all, paper “lo-fi” and HTML “hi-fi” wireframes and prototypes each have their place. Feel out your client to determine which one will be more appropriate.
Nice article.
I’ve done several projects where the bulk of design was executed in Visio (i.e. pages that would be used by the greatest number of users), but key administrative pages were prototyped in Dreamweaver. Since Admin users are frequently on a known platform, my crude HTML prototypes *were* often used as production code for these pages — saving time for the front-end developers. This is a judgement call, depending on the client and the tasks and rsources at hand.
Another point – When working with visual designers, it’s helpful to collaborate closely and early with the visual designer in order to work out high-level navigation structures as you begin wireframing, whether using visio (vector-based hi-fi prototypes) or HTML. When I say high-level navigation structures, I mean the basic components of primary and secondary nav structures: tabs, horizontal or vertical layout, persistent forms such as search boxes, branding elements.
In my experience, the nav structures are often presented to the client or end-users throughout wireframing, so it’s best to *always* present to the client/users a solid high-level recommendation to present that both IA and visual design can support. This goes far in *not* presenting a visual designer with a fait-accompli, and not constraining their design before they’ve had a chance to understand the project.
To do this I’d build some time in the workplan to consult with visual design as I was moving from site maps/ flow diagrams/ task analysis and beginning to get down to wireframing. Depending on resource constraints it can be anywhere from 2 hours or a week of collaboration with visual design. Then the Visual Designer would roll off until later, when we had sufficient interfaces designed to begin concentrated Visual Design (usually 40-50%, including a Home Page if possible).
More great reasons to use Freehand: multiple page support (not in illustrator for *some* reason) and great SWF/Flash support. Perfect for mocking up storyboard animations also, and if the destination medium is Flash, you can also pre-define symbols and save time.
I have been using InDesign of late to construct wireframes and design docs; the PDF support is much better than Freehand. Freehand is probably the best all-around vector wireframing tool IMHO. Some clients really like a printable PDF that they can print and spread out on their desk.
That said, I am very excited by this article. A few years back when I tried HTML wireframing, my lack of skills with HTML held me back; it was frustrating. Now that I’m CSS/XHTML fluent, it totally makes sense, especially for application and internet design.
Todd W.: totally hear you about clients not getting the whole wireframe idea. I put so much extra effort into setting expectations and making sure the client understands *what* the wirframes are. Usually, the analogy of the architect’s blueprint gives concrete thinkers something to connect with conceptually. “You know-wall here, plumbing here, look-a door! etc.”
One problem I haven’t figured out how to surmount is clients that get it (or pretend to), but then have to get approval internally from people who they think can’t understand. What then? (sorry if that’s getting OT =).
As far as tools are concerned, I’d swear by OmniGraffle for flow representation (data or interaction). As far as wireframes, I’d strongly, strongly recommend Canvas (Windows & Macintosh) (http://www.deneba.com). You can do vector and raster illustration, multipage, multilevel, and even HTML export (along with PDF).
Anyone else using Canvas?
Very good article. I was unaware that wireframes were not WYSIWYG. Visio certainly isn’t. It is more “the best of a bad lot” solution. Where is Dan Bricklin when you need him?
Excellent article.
I have been using Visio and OmniGraffle for some time now. For those Mac users who also use or interface with Windows machines, I also recommend Software Odessa’s CONCEPTDRAW PRO.
OMNIGRAFFLE is very affordable and is bundled with some of the new PowerBook G4s.
CONCEPTDRAW has a richness of templates and palettes that rivals Visio itself, and it has the advantage of also supporting Windows and XML and exporting to Visio 5 and higher — for those occasions when when you want to share something with a Visio user.
As a consultant project and technology manager, I find that all of these tools are valuable.
Under Mac OS X, the Mac has become an excellent platform for the project manager. You can use ConceptDraw, OmniGraffle to replace MS Visio —
and AEC Software’s FastTrack 8 which is more than an acceptable cross platform replacement for Microsoft Project.
I find myself bringing my lightweight iBook out to client sites as often as a Windows laptop — which weighs 1.5X the weight of the iBook.
I just have to say that Braun Consulting “tools” are the last authority in Information Architecture. They have no forsight and their methodology is useless. They are a bunch of consultant hangers on. There work is the extra cream in the cash crop that consulting firms like to add on. It has no real value or no real service to anyone. Look at the idiots that work there, Sean, Mike, they are all ex Agency.com idiots that were basically vomited out during the dot. com crash. Schwalb does know his stuff, but for the most part Braun Consulting’s Creative, IA methodology is useless dribble that is completely ineffective.
I just have to say that Braun Consulting “tools” are the last authority in Information Architecture. They have no forsight and their methodology is useless. They are a bunch of consultant hangers on. There work is the extra cream in the cash crop that consulting firms like to add on. It has no real value or no real service to anyone. Look at the idiots that work there, Sean, Mike, they are all ex Agency.com idiots that were basically vomited out during the dot. com crash. Schwalb does know his stuff, but for the most part Braun Consulting’s Creative, IA methodology is useless dribble that is completely ineffective.
As with all these, it’s a balance, it doesn’t have to be an either/or.
Like others have said, I have used a combination of lo-fi and hi-fi mockups for years — currently using Balsamiq (one of the many that make it look hand-drawn) and hand-crafted HTML.
I enjoy using OmniGraffle for flowcharts, Garret IA charts, and of course ERDs. I recognize that it may be too lightweight for some purposes, however there is a nicely designed Wireframe Palette (@ http://www.studioid.com/projects/ia/omnigraffle.php) from Michael Angeles, aka jibbajabba on iaslash.org (@ http://www.iaslash.org). It’s rather basic, so I plan to flesh it out with some of my own designs which I’ll make available on my web site at some point. Definitely clients could not mistake this stuff for the final design! For those who do have that problem with clients, perhaps putting “DRAFT” or somesuch in red type would help avert any potential disaster?