Mention the use of HTML for wireframing or prototyping, and some information architects and interaction designers frantically look for the nearest exit. In some circles, HTML has acquired the reputation of being a time-consuming, difficult undertaking best left to developers. I’m here to convince you that this is very far from the truth. In fact, using HTML as the basis for your wireframing and prototyping can be a quick and rewarding experience with fabulous benefits, including easier user testing, improved client communication, and faster, more effective use of design time. As a matter of fact, at Sliced Bread Design, Dreamweaver is the ONLY tool we use for our wireframes, and we love it. For those of you who may stop right now because you don’t know how to do HTML, let’s first discuss why you would want to use it. Then, read the HTML Wireframing Primer to find out how to do it yourself.
What people are using now
Henri Olson of guuui.com recently conducted a survey of 52 people to understand their use of web prototyping tools. He found that only 28.3 percent of interaction designers surveyed use HTML tools such as Dreamweaver or FrontPage for prototyping. The rest use visual and diagramming tools such as Visio, Illustrator, PowerPoint, or paper. While I am happily surprised by the quarter of designers using HTML tools, I am still left wondering why more people don’t take advantage of the benefits of HTML. In fact, the survey found that over 67 percent of HTML prototypers agree with the sentence: “I’m perfectly happy with the prototyping tool I’m using.” And, in a question that measures how well their current prototyping tool lives up to their functionality requirements, prototypers agreed that HTML tools came out with the highest overall score. This compares to only 8 percent of diagramming tool (i.e. Visio) users and 50 percent of graphic design tool (i.e. Illustrator, Photoshop) users who are perfectly happy with their tool. So the question is, if HTML is so great for design, why aren’t more people using it?
Definitions
There are many different definitions of wireframes, prototypes, and visual design, so let’s start by defining how these terms will be used in this article. A wireframe is a grayscale block diagram that illustrates the overall navigation and the blocks of elements such as content, functionality, etc. that will go on the screen. It does not contain pictures and doesn’t necessarily need to link to anything. It just demonstrates what elements a web page or application screen will contain and roughly where they might go—although the location can change. It does not include visual design. An HTML wireframe is created in HTML using a program such as Dreamweaver. A flat wireframe is created using a program such as Visio, Illustrator, or Photoshop and does not have interactive components, but is a flat image of the elements on the screen.
What I call an interactive HTML prototype goes a step further by linking navigation on an HTML wireframe to other wireframes representing subsequent screens, filling in content as needed, and adding mock functionality such as drop-down menus and fields that don’t tie into any backend. Note that this sort of prototype is somewhere between high- and low-fidelity as defined by Chris Farnum in his recent Boxes and Arrows article. This prototype does not represent any visual design other than simple layout. It does not require enlisting the help of a developer because the interaction designer does all of the work in a program such as Dreamweaver.
The screen shot below shows one page of this sort of prototype. Notice that it shows that the design will have primary navigation with four categories (Dashboard, Database Setup, etc…), secondary navigation that integrates the steps of a wizard with navigation (an idea we were testing), a form to fill out in the middle that a user can try out, and navigation at the bottom that might be buttons or links when the design is complete.
Why avoid HTML?
I’ve heard many reasons why designers don’t want to use HTML for wireframing and prototyping. The most common reason they are reluctant to use HTML is because they are already comfortable with tools such as Illustrator and Visio. I’ve heard people say, “Making HTML really work is difficult” or “I don’t know JavaScript.” To combat these concerns about ease of use, the accompanying HTML Prototyping Primer article teaches you how to create quick, functional, flexible wireframes without any real programming by using Dreamweaver. But the flexibility and functionality of Dreamweaver is not the main reason to switch to HTML. Let’s go on a short tour of the benefits of HTML wireframing and prototyping that will convince you to make the switch.
Increased user testing
The most important interaction design benefit of HTML is the way it lends itself to ongoing user testing. Because of their interactivity, HTML wireframes are regularly used to user test design ideas on the fly with people in the office, friends, or anyone who happens to stop by. When there is no one around to show, we post designs to the web and instant message a friend to try them out – we always get some quick, useful feedback. For example, Sliced Bread Design recently worked with a company called Elevon on a new version of their enterprise budgeting software. From the beginning, the client had many different ideas for the flow of the set-up wizard. Some parts of the set up had to be done in a specific order, while other tasks could be done at the user’s convenience. We approached these different aspects of the functionality by creating a list of tasks involved in the set up, and disabling the tasks that could not yet be started (see Figure 2 below).
When everyone is satisfied with a wireframe, like the one above, we can then link all the screens together into a wireframe prototype and conduct more formal usability testing without having to do additional set up work. Of course, for formal usability testing we still have to create a script for the tasks that we need to test. Your prototype might need more or less modification to fully cover those areas you need to test. However, we’ve found that our wireframe prototypes convert to user test material with minimal effort because the framework for every page is already in place and is very flexible. Above all, our reliance on HTML wireframing lets us promise all of our clients that the final design will ALWAYS be user tested, even if only via guerrilla user testing – especially important if the budget is tight.
Creating visible client value from the start
Another big benefit of HTML is visible value for the client at the beginning of the project. Some of our clients are confused about the difference between interaction and visual design. By focusing on creating something interactive at the beginning of the project in the form of an HTML wireframe, we can demonstrate that the focus of our work will be on how people use the product as opposed to how it looks. And, as we are busy showing off our knowledge of interactivity, we are also demonstrating our awareness of technical constraints. Even if your wireframe is based on the simplest HTML out there (ours always are) and only takes 10 minutes to create, the fact that you have ventured out of the realm of graphics software demonstrates your concern with creating something that is implementable, not just a blue-sky concept.
Improved client communication
When it’s time to show the work to the client and demonstrate its value, the next benefit of HTML becomes improved client communication. Sometimes it may be difficult for a client to understand the brilliance of the user experience that is being proposed because they cannot experience it for themselves. Miscommunication can result from misunderstood verbal descriptions of how users will interact with a flat prototype. We experienced this on a project where client team members were located on multiple continents and had varying English skills. By demonstrating the functionality instead of describing it, we were able to greatly reduce miscommunication that initially resulted from teleconferences and documents in rough English. Furthermore, team members in different time zones could review designs that we posted on their own time without additional explanation. By allowing our client to experience the interaction, we knew that they understood exactly what we were talking about and had agreed with the direction we were heading early on in the process.
Communication through demonstration is especially important when the project does not have a pre-defined functional specification, i.e., a definitive list of the functionality and/or content areas that the product must have. For example, on the Elevon project, we were hired at the beginning of the project to help replace old desktop client server software with a shiny new web application. At this stage, there was no specification, so our work played an integral part in helping define the product’s functionality. By creating interactive wireframes that represented the functionality under discussion, we were able to quickly reach agreement on what worked best for the end users. Furthermore, everyone could click through the wireframe prototype to make sure that all the pieces were in there, and any functionality that had been casually discussed wasn’t getting lost. The Elevon team also used the prototype to reach internal consensus and demonstrate the project’s progress to management.
Disqualifying poor ideas
Another client communication benefit becomes apparent when your client suggests some interaction scheme that they are sure will work, and you are sure won’t. If a gentle suggestion to steer the client in the other direction doesn’t work, we’ve found that creating an HTML wireframe to demonstrate the problems of the proposed interaction is much more convincing than further discussion. Often experiencing an idea is very different from describing it. And, since the idea is now prototyped, it can easily be user tested if you need more ammunition to disqualify it.
Simplified implementation
If I haven’t yet convinced you of the benefits of HTML prototyping, perhaps this point will: return on investment (ROI). These days, everyone is chatting about the hot topic of ROI. By emphasizing your use of HTML to the client, you can also make legitimate claims about decreased development costs through more consistent implementation and quicker specification. We use our HTML prototypes directly in our specification to communicate to developers exactly how the final product needs to work. More complex functionality, not in the prototype, is explained via bullet points under the screen itself. Although the prototype lacks the final graphic design, it demonstrates the functionality and the flow, leaving little room for developer confusion, which in turn saves time during the development cycle. Furthermore, your client saves money because your time isn’t spent explaining every detail in a text heavy specification.
Upsell to marketing
And finally, the last client benefit is actually a potential follow-up project for you. Since you saved the client money in specification, you can now spend it by selling them a robust version of the prototype. Well-crafted HTML prototypes can easily be turned into marketing prototypes once the visual design is complete. Many projects that we’ve worked on take a long time to implement, but inevitably the marketing team always needs something to show next month at the big conference. Voila! With an existing prototype, it is easy to apply the final visuals for your client to show their customers before the final project is complete. Everybody wins.
HTML is for more than just the Web
Hopefully, now that I’ve sold you on HTML prototyping, the important thing to note is that HTML wireframing and prototyping is for more than just web projects. In the past, we have used HTML prototyping for both desktop and cell phone applications. For example, through the use of screen shots and some carefully placed web layers, we were able to create an interactive prototype of a Windows file management system. On another project, we prototyped in WAP (roughly HTML for cell phones) using a Dreamweaver plug-in. By creating a mobile phone interface to user test, we were able to capture interaction problems before we presented the ideas to the client. Once you get hooked on HTML wireframing and prototyping, you really can’t go back.
OK, I’m ready. What do I do next?
Read the HTML Prototyping Primer for concrete instructions that will make you more comfortable with Dreamweaver. Although it might be hard to abandon what you are used to and get turned on to HTML, hopefully, I have emphasized that in today’s tight economy, the benefits are well worth it.
- Results from a survey of web prototyping tools usage
- What an IA Should Know About Prototypes for User Testing by Chris Farnum
- Definitions used in this article:
Wireframe: a grayscale block diagram that illustrates the overall navigation and blocks of elements
HTML wireframe: wireframe created in HTML using a program such as Dreamweaver
Flat wireframe: wireframe created in graphics program such as Illustrator, diagramming programs such as Visio, or on paper
HTML prototype: HTML wireframes with actual content and interaction components filled in that are linked together to form a rough interaction
I think that using divs and .css for the more experienced developer could cut down on workflow.
There are templates available on the web, where the main elements are laid out and the css does the placement.
These have several different configurations that all use the same HTML page.
You can find the ones I use here
http://www.contentwithstyle.co.uk/Articles/17/a-css-framework.
Great description of the used terms in this article.
I’ve not been working with grayscale wireframes because I know 90% of my clients aren’t able to look trough the none color design and see the advantages of a (non) visual design as part of the process
Annotated prototypes vastly improve the requirements process. Protonotes ( http://www.protonotes.com/ ) lets you easily add and share notes on any prototype or web page. I also use it for heuristic reviews or usability tests.
Yeah, me too. Developing wifeframes with Visio is really piece of cake. Writing code is slow and expensive, of course sometimes you got to write few lines, but in most cases Visio is just enough !
I actually prefer mocking up my wireframes in photoshop. Visio is pretty nice, but nothing beats having complete control over the design…even if it’s the design of a wireframe. Even for prototyping, slices and HTML can automatically be generated out of photoshop. Then you don’t have to worry too much about writing the code.
I have heard a lot about the flash prototyping tool. Although it seems weird to me that all of this specialized software used for creating rich media also being used for user-experience design.
I vote for Illustrator as a prototyping tool. For me, wireframes are at least two generations away from final HTML. Having handy, vector wireframes are extremely portable into a designer’s hands – whether that be flash, photoshop, firefox, etc. While HTML can provide some insight into ‘how things work’ and are arguably better at demonstrating wiggly jQuery stuff, I think they’re a step out of the design process.
Nice article, Julie. Things have certainly come a long way in the last 7 years since you wrote it! I personally use an online tool called LucidChart ( http://www.lucidchart.com ) for my wireframing. It’s slick and easy. And it’s collaborative so I can invite others on my team or even clients to come in and view it with me.
Its refreshing to see some real thought put into web design, now-a-days people rely on templates and don’t stop to think about being unique!
There will always be these two school of thoughts. One that will vouch for HTML prototyping as the best tool to help end users and customers to understand the flows and interactions and the second, which will defy this approach for various reasons. My experience both in Waterfall and Agile has been that it all depends on the luxury of time, money and quality.
In the waterfall process, the designer can spend some time to make the HTML clickable prototypes in sync with the use cases and demonstrate them to the client and users and the internal dev team the concept of the workflows and designs. There is enough time to do so. My experience in Agile and specifically the Inception phases of the project dictates that the best tools are the ones that are the fastest and yet communicate the interaction in the most lucid manner. I am talking about tools as simple as whiteboarding, paper protos, ppt, digital notepads like the DigiMemo 692 etc. These allow for basic interactions to be quickly drawn and agreed upon by the stakeholders. It gives the devs to understand the UI constructs and the BA to plan the functionality asap. Should there be a need to show flows and interactions, tools like Axure help a lot. What you need is a good team of a UI dev and a Visual designer. An UI dev to understand and monitor the designs and the visuals and give his opinion on whats possible and easy to implement. I see these roles differently, though most will disagree, simply from the aspects of time and the mode of thinking- as a UI dev+designer I don’t want my initial design concepts to fall into the trap of ‘what possible’- that which again depends on how much knowledge of the UI dev I possess. This is however not an excuse to not know and understand the basics of HTML/CSS. I recommend that every designer understands the implementation details of the designs. And not just HTML/CSS, but the entire process of development, testing, deployment and release. There are other reasons why not HTML/CSS as others have mentioned-Cost, Color traps, non-reusable code and quickness. If you/re following Agile SDLC, a better approach for gathering feedback would be quick/guerrilla testing and a phased release/betas to the users. Happy Designing!
The primary reason I could see FOR doing HTML prototypes would be to take advantage of code reuse, except if your final product does not leverage the technology. I also agree that it helps to see the flow/interaction of the site or application by making it fully interactive.
I think HTML prototypes can work fine for high fidelity prototypes, but I personally choose not to develop my prototypes in HTML for the following reasons: it is not faster, there may be cross-browser issues, it is most likely going to involve more technology than HTML ( Javascript, etc ). And primarily, I like to create several different versions of my wireframes in low fidelity and gather feedback from paper prototyping.
White boarding and paper prototyping, imo, are the fastest methods to get ideas down. Then I can use programs like Mockingbird or Balsamiq to refine the lo-fi prototypes. HTML simply cannot compare with either the ease or the speed of working in this manner. This stage should be about ideation, and matching the user’s mental model. I think getting too far into a technology, even as simple as HTML, detracts from this. The lowest level of effort = the highest consideration for multiple revisions.
Enjoyed the article, Julie! A couple of comments. I have to admit that I’m hooked on Visio prototypes and can’t go back—so take these with a grain of salt.
Two minor downsides that I’ve found with HTML prototypes—probably can be overcome simply with very clear communication. First, I’ve found that people are much more tempted to make prototypes really pretty, with color, etc—spending unnecessary time on presentation simply because it’s HTML, and they’re used to doing more polished looking things in HTML. In the same way, on each of the couple of projects in which there was an HTML prototype, I’ve found myself having to fight to not reuse the HTML code from the prototype…I guess it just feels wrong to people somehow to recreate HTML that exists in some HTML version, regardless of how purposely slapped together that code was….
Also, you mention that one of the main limitation of one of the main limitations of the “flat” prototyping tools like Visio is that they’re not interactive or sharable over the internet. You can in fact create HTMLish prototypes in Visio—you can add a hyperlink to make one object (say a button) link to another page (through InsertàHyperlink), and then Save As HTML. It creates weird (and large) image map based pages, which are a bit quirky and buggy, but they are clickable enough to user test with, and sharable over the web. If you want to go nuts, you can even put code behind any of the objects through VB (I’ve not tried it, but I assume it could be conditional, etc.). The one thing you can’t do is have working controls (i.e. you can’t write in text fields, drop downs don’t drop-down).
Thanks a lot for your nice article explaining a possible way of prototyping using HTML.
HTML prototyping offers a lot of advantages such as a very realistic user experience. I personnaly use illustratorto make sketch and diagram using a mix of wireframe for the screen prototyping and some mix of UML and merisse for the functionnal flow and so on.
Before making prototypes, i was senior HTML integrator and client side developper using Javascript and so on… I should have make prototypes in HTML but i had the following problem : when u have made a first version of a site prototype, HTML is very heavy when you have to make an important change in the prototype.
An other problem is to want to be too much realistic in the user experience. If you prototype navigation, prototyping this navigation require sometime to develop all the machanism of this navigation and then, i ve a problem with this time wasting.
In my experience with Illustrator, my main advantage is to have a very fast authoring tool for modifications and free drawings. We can also make clickable demo using Illsutrator as authoring tool and exprot the sketch in SVG. I will make a demo of this because i think it could be really interesting to show to the community.
Thanks a lot again for your paper.
PS : excuse my poor english
Julie,
Your article implies that the reason designers avoid HTML is laziness, lack of training, and lack of personal comfort. There is however an important strategic reason to avoid HTML wireframes and prototypes.
Good interaction design processes strive to create artifacts that conform as closely as possible to the user’s mental model. This is difficult, of course, because the easy path to software product creation always adheres to the implementation model: that is, solutions reflect their construction methods and media.
Interaction design uses many methods to limit this effect. Most methods seek to remain “abstract” or “technology-neutral” during the early stages of design. Using HTML for early models and prototypes may seem innocuous enough, but it is not a technology-neutral technique.
For this reason designers often seek to avoid HTML until later in the design cycle.
I have to agree with L. Goffin that an HTML template (whether you use Dreamweaver or not) takes longer to develop and is more time consuming to modify or revise.
I do agree that an HTML template would work better when you are developing a web application rather than a concept for an entire website.
I’m responsible for client-side programming as well as wireframe construction and usability at my work. Even though I hand-code HTML templates I still prefer VISIO for developing wireframes. I would never really suggest writing a line of code until you have everything the client wants solidified.
I must admit that I do have a bias against Dreamweaver any any tool that generates code for you. In my experience the code is never as clean as when it’s hand-coded and there are cross-browser issues with the code that’s generated.
Hello,
I will respond in this comment to the issues raised in previous comments. However, I have to preface my responses with the bias that I spend most of my time working on large web applications as opposed to primarily content driven websites. I have not done enough research to comment substantially on process differences between working on web apps versus web content sites.
That being said, here are my responses.
Issue 1: Spending too much time on the visual look of the wireframe when it is in HTML
We actually deliberately go out of our way to make the wireframe not be very visually appealing and completely gray scale. One issue that we have found with the HTML wireframes is that it sometimes invites comments about the visual design such as “I don’t like that shade of grey” which we have been able to avoid by really just focusing on the interaction and not thinking about visual issues other than making sure that things generally align (which working with tables does for you anyway)
Issue 2: Reusing code
I feel fairly strongly that the designer should not be the implementor of a web application so that conflicts of interest don’t arise. As a result, we work closely with developers once the design is done to supervise the implementation and verify with developers while we are designing that things are feasible, but really don’t think much about reuse of code. Since we are not the ones doing the implementing we don’t personally feel tempted to have clean code or reusable code or any code related worries. We just want things to work in a smoke and mirrors sort of way to demonstrate/approximate the functionality that we are after. I can see that if you are the one who will be doing the implementation, the temptation to reuse code/clean up code may be great, but this is a situation that deliberately does not affect my work.
Issue 3: HTML being too heavy when making changes
I am not sure that we have run into this problem. L. Goffin could your provide an example of this? One thing I particularly like about HTML is that when have some big navigation change that goes accorss mutliple wireframes, we can use find and replace to change it once we have made it the way we want on one page.
Issue 4: Wasting time by spending too much time on making stuff realistic or messing with the HTML
I think it is important to be realistic of what you can and can’t accomplish with some quick HTML. Some things are best left explained and some elements of an HTML wireframe will still be flat and just a screen shot fitted into the HTML. THis is exemplified in the accompanying Primer article by the multi select box scroll bar which is just a gif and does not really work. I actually have the opposite problem of wasting too much time in Illustrator because I spend too much time aligning things and making them look perfect instead of being rough. For me, HTML has been a solution that allows me do things more roughly and more quickly. But, I think the key is to be clear with yourself and your client that you are not interested in the code behind the wireframe and that you are most interested in the functionality communication and not in the visual design. Since our HTML wireframes are so light weight and quick, we can change them quickly as client functionality needs change. We also tell the client to only view them in IE since we are not going to waste time optimizing code.
Issue 5: Avoiding being technology driven:
“Interaction design uses many methods to limit this effect. Most methods seek to remain “abstract” or “technology-neutral” during the early stages of design. Using HTML for early models and prototypes may seem innocuous enough, but it is not a technology-neutral technique.”
I am not sure that I agree entirely with the goal of remaining technology neutral. When I am designing a web application, I think it is important to be aware of both constraints and common practices on the web platform that you are designing for. A great example is a client that recently came to us with a web application that they had designed that they needed help with. Since they were not that familiar with the web, they had designed a web application where users double clicked on icons, could use function keys to access functionality, and right clicked to get accesses to a menu of options since there were NO buttons on the screen to control forms functionality. I am not kidding. Now while some of these things may be OK on a Windows application, double clicking for example is not OK on the web as everyone knows. Although design should not be tech driven, it should be tech aware and constraint aware. I think presenting designs with no idea if they could ever be implemented on the web to a client who is very focused on delivering a working web app can contribue to giving designers a bad name.
At any rate, that is my two cents. I am curious to hear of specific examples when people have tried to do an HTML wireframe and felt that it took too much time to see if the process there differs from ours.
IMHO I think the *best* thing about HTML prototyping is that it’s the easiest way for the client (and the dev team!) to understand the flow of the application… “What happens after i press save?”… … “Oh that.” This saves a lot of time and money. Totally agree with Julie’s standpoint.
As i told previously, one of the main problem of the HTML prototyping is maitaining and changing the prototypes. I read your primer about dreamweaver and then i remembered some technique to ease this maintenance of HTML prototype system.
A solution could be to use floating layers (DIV) and the Dreamweaver Libraries Object.
In the step of prototyping, the main issue is to validate some process and the website grid. Through HTML, you provide the ability to click and it’s great. For this step, we can imagine to make a browser dependant prototype HTML code.
So we could use floating layers positionned with an embedded CSS so we can change easily the grid within a whole site. It’s easier to manage than table. I love table but when i need to go fast, i use DIV. So through the DIV, we have a fast way to make the grid. Only one problem : it’s absolute positioning.. It can be fine for the main part of the interface of a site.
About the content of the DIV such as navigation, header, function bar, footer items that require to change all pages when we change something. We can use the Dreamweaver librairies object. It allow you to select a piece of code and stock it into kind of snippet (for Homesite user)
In all pages where u place this object, dreamweaver make a intelligent cut and paste of the code. If you change the object, Macromedia propose you to update the all the pages using the object. It does not require any server side technologie, i bet you dont want to make server side include for an HTML prototype. Librairies have an extra value according to search and replace and include because it updates the path to image or links according to the physical website structure.
For those using other wysywig HTML authoring tool, i think Golive does have a similar technique.
I think those 2 techniques can ease to maintain an HTML prototype. you’ll have probably a prototype working only on MSIE, but the goal is not to validate a corss browser HTML code yet.
It’s interesting that Denim hasn’t been mentioned. It is a tool that allows fast but intelligent prototyping of sites, from entire architecture down to page design, through sketches. It can then generates HTML output, so no need to create any HTML yourself.
Also the sketch like appearance of the generated html wireframes avoids the client spending too much time worrying about visual aspects.
Needless to say from the above testimonial, i find it very useful
Very fine points about prototyping and wireframes.
I would like to point out though, that both Powerpoint and perhaps especially Visio have close to excellent tools for interactive prototypes. They are not flat at all – unless you don’t know your tools.
One key issue with prototyping in Dreamweaver or other HTML based tool is the risk that the prototype might be taken for the product – or at least that some code will “spill” over to the end product. Prototypes done in totally different tools never do that.
For infos, u can find more infos about Denim at
For infos, u can find more infos about Denim at http://guir.berkeley.edu/links/
Julie,
I appreciated the article and agree that wire prototyping with HTML is very effective. I worked on a recent project where we used Fireworks screen images to prototype the system. It became very difficult to make changes after a few dozen screenshots had been developed.
There is an alternative to Dreamweaver and their ilk (sorry!) that I think people should consider. That is an HTML preprocessor. I wrote one a few years ago named htmlPX and it is freeware (www.wiserve.com/htmlpx). There are many others available.
You develop templates as plain text files and then build individual pages based on those templates. You can generate an entire site in seconds. Changes to the template creates a new look and you have a complete, interactive site.
It is then up to the designer to avoid falling into the trap of trying to make it look like a production quality site while they are trying to get feedback from the client.
Any thoughts?
I’ve always steered clear of doing HTML prototypes where clients are concerned. No matter how explicitly you try and explain that THIS IS NOT THE DESIGN, if they can see it in a browser, the client typically starts to focus on design issues, not interaction. I’ve just found that when it’s on paper (I user Visio), those problems happen less often.
The two main reasons why I don’t use HTML prototypes is that:
1. You have to struggle with tables, in order to layout elements on pages
2. If you want to make site wide corrections, or corrections which apply to a section of a web site, you have to alter each and every page manually
As you can read in my article, Visio – The interaction designer’s nail gun http://www.guuui.com/issues/02_03_02.asp ,Visio is pretty good at these two things:
1. You can drag-and-drop interface objects onto pages and place the anywhere you like
2. You can use layered backgrounds, which allow you to make changes to multiple pages – sections or site wide – by altering a background that the pages share.
As it has been mentioned, Visio has some flaws. It isn’t possible for users to enter data into text entry fields or interact with dynamic controls, such as drop-down boxes and list boxes. But those shortcomings are hardly ever a problem, and can be solved with a bit of creativity.
If you prefer to use a HTML tool for prototyping, I would recommend Adobe GoLive. It has a thing called a layout grid, which you can place elements onto, so you avoid having to struggle with tables. It has been a while since I used it, but I doubt it has the same flexibility as Visio when having to make rapid changes to multiple pages.
Wow. Lots of comments by people that don’t know how to use Dreamweaver.
Dreamweaver is a deleriously powerful tool for managing common elements or templates across multiple pages: indeed, superior to tools like Visio, Illustrator or Freehand.
The key is to use the Template and Library Item features within Dreamweaver. With these, huge chunks of a site’s navigation can be updated site wide _much more quickly_ than in Visio or (god forbid) Illustrator.
A key advantage to using HTML tables is that when an element is added to a layout (eg: you’ve added more links to the header, so it’s now 50% taller!) the rest of the page elements flow to accommodate it.
Sketching tools simply don’t do this. Changing a background layer in Visio isn’t going to bump your foreground elements down a skritch. Using HTML DIVs puts you in the same boat; that’s why Tables are preferable.
I’ve been using DW to do HTML prototyping for a couple of years now. Our company has an in-house DW extension that supplies a pallete of useful object libraries: paragraphs of Lorem Ipsum, breadcrumb trails, next and back buttons, etc. Elements have built-in CSS to give them appropriate font sizes, outlines, and clearspace. All in glorious technicolor shades of grey.
We can develop complex site prototypes more rapidly in HTML than in drawing or diagramming tools. We’ve checked. Through appropriate use of templates (and now nested templates in DW MX) we can rest assured that site-wide updates to navigation can be implemented instantly.
P.S. If you’re still worried about clients not “getting” the fact that the HTML prototypes are not designs… print them out!
Hmmm…I am not sure that I understand these concerns that people have about a) reusing code and b)clients being confused that it is just a prototype.
On the reusing code front, I actually don’t understand what would happen if you actually did end up reusing some code. Let’s say some code did “spill over” into the final product. What then? I am struggling to understand what the crisis would be if the code is still clean and works and it represents the final design. This case has never happened to us since we specifically avoid coding and the developers we work with don’t want to use our code, but I am not sure of the repercussions if it did. I just checked with our developers and they weren’t sure either.
On the client confusionissue over the prototype being final, I think this is easily avoided by either remaining fully in grey scale (since most company’s colors are not different shades of grey, it clearly does not follow their branding and so is not the final design) OR as Che suggested, printing stuff out. Again, I want to emphasize that this problem has literally never effected us after many many prototypes because we set expections before presenting to the client and sort of make them look a bit crappy on purpose.
Julie
re. reusing code, i do web development and ia on a large content site, and our html prototype transitions into the final product. we have a release schedule of flat protype, html prototype of top level pages, html prototype to a few levels down, apply visual design, and then complete the entire site.
there is added time in the initial html prototype stage, because we have to implement some of the technical framework, but especially regarding things like including global elements and dynamic creation of breadcrumb trails and leftnavs, there is a ton of time saved for later on in the development cycle.
we even have a prototype stylesheet with grayscale styles, so that the classes exist as we build. later, applying the visual design is extremely fast. (we applied our visual design to 1000+ pages in a week.)
so there are actually cases where it’s a benefit to have an html prototype that transitions to a live site.
great article julie!
We believe HTML prototyping and wireframing is the only way to go. Is the most realistic and allows people to actually *use* the wireframes and UI widgets. It also allows us to make revisions quickly and in real-time (to the client: “reload and let me know what you think”).
I have a slightly different perspective, since I’m usually on the implementation side of things. On my projects, I would work closely with an IA (and/or visual designer) to develop HTML prototypes, and I would also be one of the team who builds out the final site.
The templates and library items in DreamWeaver are indeed very useful, and can reduce the maintenance chore for common elements such as navigation. DreamWeaver (and GoLive) also generates much cleaner code than previous versions, though not yet to the point where developers can directly use it. I usually still hand-code in Homesite, since I’m most comfortable using that.
Modes of prototyping styles/tools are very individual…I know that I can be very effective with certain combinations of working styles/tools, but much less so with other tools such as Visio. The key is that the prototyper feels completely comfortable with the tool, so that there is little conscious thought required in translating the conceptual model to prototype (whatever form it may take).
To me, a big part of prototyping is picking a limited scope (information architecture, visual design, technical functionality, etc.) and then iteratively refining it. If you’re concentrating on designing the interaction flow, then you would want to limit the fidelity of the visual design (e.g. by using a greyscale palette, a “sketchy” font, etc.). If you’re iterating the visual design, then the data model underlying the functionality is not as important. If you’re concerned with the technical implementation (as is usually the case for me), then you would want to prototype using as close as possible to the final technologies which will be used, so that technical design issues can be worked out beforehand. It’s a matter of picking which aspects of the prototype you want to adjust the fidelity (high or low) so that it would fit your purpose.
So perhaps the IA and myself would start with a few sketches and discussions, then move to flat HTML, then as the visual design and technical architecture get firmed up, move the prototype to JSP (where I can implement real templates and dynamic navigation, and certain types of maintenance becomes even easier than DreamWeaver), and then move onto the build of the final site. As others have mentioned, this evolution of prototypes into the final site can be quite powerful.
Which brings us to the reuse of prototype code. I feel that the baseline expection with team members and clients should always be that the prototype code is not reusable. Now, it may happen that through good processes or code libraries (see comments by che, melly above), the prototypes yields reusable code or components. That’s absolutely great, but certainly doesn’t happen all the time, given the varying time and resource constraints of exploratory design. If the code isn’t clean enough, or the prototype code didn’t take into account some underlying technical functionality requirements, you end up having to rewrite the HTML anyway. Better to start with the expectation that you’re writing clean production code, and not assume that the prototype will give you a huge shortcut.
For my prototypes, I could usually glean the basic structure of the style sheet and the HTML code and perhaps Javascript or navigational components, though they would need further refinement to become the final HTML (especially if visual design hasn’t been incorporated yet). As the eventual implementer, I would try to push the fidelity of the code as far as possible so that I can reuse elements of it later, but never to the point where it slows down my prototyping.
Great article Julie, great points all.
Thanks Julie for great article.
I’ve been through this same problem with several different teams using different technology/platform.
Again, like Julie Stanford’s comment, my comment is bias toward designing large licensed web applications working with product managment, engineering, and ofcourse key customers – in full software development life cycle.
I believe using both (visio, illustrator, html, paper) is fine for different time and different stages for UI design development life cycle.
Believe it or not, lot of us do go through the whole –
low fidelity, medium fidelity (sometimes), and finally high fidelity prototypes or “wizard of oz” level prototype.
During the low fidelity – definitely – paper prototypes or visio level documents work the best for following reasons:
1. At this stage, we’re not concentrating on UI interaction too much at all. It’s all about identifying and verifying user’s tasks. Drawing are used get more information out of the targeted users.
If you are designing, large web applications, it’s critical you are desigining the system to meet user’s expectations and at the same time deliver your findings to product manamgent and engineering.
2. We found through several customer site visits that drawings(wireframes) works the best, when we apply “collaborative design” with customers.
During the design cycle, you will not have too much opportunity aks your users to help design the software on the spot. Users were able to make direct comments on the drawing or even make modifications to the drawings without hesitation.
Since they know it was just a sketch.
With more interactive prototypes, it was harder to make notes and make changes on the spot.
3. Our products try to take advantage of what
javascipt/DHTML, CSS, some plugins, and etc.
to enable best client side peformance and ease of use. As most you know, it’s really hard to just prototype let’s say “popup calender widget” on the spot in html. So don’t bother coding it, just show how this might look like. Lot of web applications now have very “complex” user interactions that cant’ be coded in html in matter of minutes, even with dreamweaver.
When to use HTML prototypes:
I suggest using it during “medium to high”
fidelity stage. By this point, your team
should have indentified most the user’s tasks and
technology requirements from your engineers.
Like, Jennifer Stanford said, html prototype generated at this stage shouldn’t be used in
production enviornment without your enigneers
consent. I advise not use it at all.
Instead work with developers or even by your self to make the prototype user experience real as possible.
You may need developer’s help, if you are going to be implementing complex UI widgets.
Final note:
Some of you may not have low to high fidelity protoyeps for your projecdts. That’s fine.
It depends on your schedule and scale of the project.
But I do feel, lot of the web application UI now have very complex client side codes, that even Dreamweaver can’t help you out of the box.
What then?
Learn from “thick client or desktop” UI designers have been doing for years.
My 2cents.
Thanks Julie for great article.
I’ve been through this same problem with several different teams using different technology/platform.
Again, like Julie Stanford’s comment, my comment is bias toward designing large licensed web applications working with product managment, engineering, and ofcourse key customers – in full software development life cycle.
I believe using both (visio, illustrator, html, paper) is fine for different time and different stages for UI design development life cycle.
Believe it or not, lot of us do go through the whole –
low fidelity, medium fidelity (sometimes), and finally high fidelity prototypes or “wizard of oz” level prototype.
During the low fidelity – definitely – paper prototypes or visio level documents work the best for following reasons:
1. At this stage, we’re not concentrating on UI interaction too much at all. It’s all about identifying and verifying user’s tasks. Drawing are used get more information out of the targeted users.
If you are designing, large web applications, it’s critical you are desigining the system to meet user’s expectations and at the same time deliver your findings to product manamgent and engineering.
2. We found through several customer site visits that drawings(wireframes) works the best, when we apply “collaborative design” with customers.
During the design cycle, you will not have too much opportunity aks your users to help design the software on the spot. Users were able to make direct comments on the drawing or even make modifications to the drawings without hesitation.
Since they knew it was just a sketch.
With more interactive prototypes, it was harder to make notes and make changes on the spot.
3. Our products try to take advantage of what
javascipt/DHTML, CSS, plugins, and etc. offer
to enable best client side peformance and ease of use. As most you know, it’s really hard to just prototype let’s say “popup calender widget” on the spot in html. So don’t bother coding it, just show how this might look like. Lot of web applications now have very “complex” user interactions that cant’ be coded in html in matter of minutes, even with dreamweaver.
When to use HTML prototypes:
I suggest using it during “medium to high” fidelity stage. By this point, your team
should have indentified most the user’s tasks and
technology requirements from your engineers.
HTML prototype generated at this stage shouldn’t be used in production level enviornment without your enigneers consent/review. I advise not use it at all. Instead conentrate working with developers to make the prototype user experience real as possible. You may need developer’s help, if you are going to be implementing complex UI widgets.
Final note:
Some of you may not have low to high fidelity protoyeps for your projecdts. That’s fine.
It depends on your schedule and scale of the project.
But I do feel, lot of the web application UI now have very complex client side codes, that even Dreamweaver can’t help you out of the box.
What then? Learn from what “thick client or desktop” UI designers have been doing for years.
My 2cents.
Flash As a Prototyping Tool
I want to point out the use of Flash as a prototyping tool, as a substitute to HTML or Visio, for more application-type interfaces. I am surprised it hasn’t been mentioned. Try rereading the article and replace “HTML” with “Flash”. Within the past three years, I’ve been working on designing products such as media players and enterprise software for both web based and desktop. It has proven to be of great value throughout the design process. Put it to some good use. It is not just for ‘flashy’ websites.
It is true that most designers and IA’s cannot be expected to already be familiar with Flash animation and scripting. As a tool for prototyping, basic Flash competency is all you really need. No complex scripting required. It probably takes just the same amount of effort to learn HTML basics.
Aside from the many benefits of prototyping in general already well stated in this article, here are some additional advantages with using Flash:
– Recreating the wireframe in HTML is less efficient. Why draw it twice? In most cases, wireframes are already created in vector format (such as with Illustrator or Freehand). These are easily imported into Flash.
– The wireframes and the prototypes do not have to look different, in fact should look the same. Using Flash, the prototypes are allowed to look like wireframes independent of aesthetics (as can be), not working code, therefore a technology-neutral technique.
– A rapid prototyping method is best when exploring interaction solutions. Recreating the wireframe in HTML may force you to deal with unnecessary implementation challenges too soon before the design is even tested or approved. Using Flash allows the design process to be separated from any code development concerns.
– The prototypes are sharable over the internet. There are no cross platform, nor browser rendering concerns therefore everyone is looking at the exact same thing.
– The way that the Flash application is structured, library elements are easily updateable. Prototypes may even be tweaked during usertesting.
– Almost all kinds of functionality may be ‘faked’ in Flash. Modes, states, and stickyness may be simulated and interacted with, especially in a non-linear way.
– HTML limits the level of interaction down to using basic components such as drop-down menus and form fields (which are now available in Flash as pre-built library components). Flash allows you to explore beyond the limitations of HTML, such as what can later be accomplished using DHTML and other technology. Promotes innovation.
– For desktop apps, the aspect of time may be controlled. Interactions that are time based may be tested such as the amount of lag for hover-activated tooltip or the duration of a transition. Audio alerts, keyboard shortcuts, these can be simulated in Flash.
– It makes for a very impressive presentation. It makes it easier for clients to “get it”.
Hi,
Nice article. The link to “HTML Prototyping Primer” article seems to be broken: I think it is now at
http://boxesandarrows.com/dreamweaver-primer/