Thoughts on HTML prototyping before design?

10 Mar 2010 - 5:07am
3 years ago
18 replies
2656 reads
josef
2010

I am currently working on an HTML prototype using IxEdit (New window) (by the way it's a great tool) to add interactions. Thoughts on the process of:

  1. User flow-maps (Work flows)
  2. Sketching wire-frames of website on paper and reviewing
  3. Building HTML prototype with live interactions and actual content, to show how things will functions
  4. HTML prototype given to designer to make pretty as they see fit
  5. HTML prototype given to programmers to tie in the back-end.


I find that this prototype is essential, since all that are part of the process, managers, project managers, content writers, designers, programmers, developers all get a chance to play with and edit it, yet can actually interact with it too.

Of course things still change, but the fully interactive HTML prototype acts as a specification for designer and back-end algorithm minded folk :) it practically defines everything as a "draft 1" visual/interactive spec say.

Thoughts?

---

http://twitter.com/josef
http://josef.gr

Comments

10 Mar 2010 - 12:03pm
Mike Myles
2009

I believe prototyping is essential, but there is a pitfall with prototypes that evolve into the end product. Prototypes are generally not architected in a way to be robust and extensible - they are (and should be) quick & dirty implementations that let the team try out ideas. The cost is low, so there is minimal resistance to trashing a prototype when it doesn't meet expectations.

If the prototype is going to become the released product one of two things will happen...

  • Lots of time will be invested on making a robust prototype, which means it will take a long time to build relative to a throwaway prototype, and there will be serious resistance to starting from scratch if the prototype tests poorly. Instead the team will be motivated to tweak the prototype to fix issues, when the best solution may be a totally different approach.
  • The prototype will not be robust, the team will iterate through changes as quickly as possible with little regard for writing maintainable code - as they should (IMO). Then the time will come to "productize" that mess of a prototype... good luck with that.

 

Additionally, I don't see the role of the interaction / UX designer to make the product pretty. A designer should be directly involved in the creation of prototypes - from simple wireframes to interactive code. Design should be driving system architecture and implementation decisions, not the other way around. Making the UI look nice after the fact is the "lipstick on the pig" school of design. Visual design is important, but too often it's seen as the sum total of design's role in software development.

26 Mar 2010 - 5:20pm
Mike Wean
2009

I agree. Front end prototyping should be rapid and disposable, an overlapping part of the process that leads up to a final spec doc and / or style guide that is handed off to Web application developers rather than a stage all its own. "Skinning" by interaction designers should begin once the first results from any focus groups and usability tests are in so that they and the front end developers can work in tandem up until handoff to dev.

Mike Wean
Principal
Melonwater Consulting
bigdaddy@melonwater.com
847-858-8533
http://www.melonwater.com

--- On Wed, 3/10/10, Mike Myles <contact@ixda.org> wrote:


From: Mike Myles <contact@ixda.org>
Subject: Re: [IxDA] Thoughts on HTML prototyping before design?
To: bigdaddy@melonwater.com
Date: Wednesday, March 10, 2010, 2:41 PM

I believe prototyping is essential, but there is a pitfall with prototypes that evolve into the end product. Prototypes are generally not architected in a way to be robust and extensible - they are (and should be) quick & dirty implementations that let the team try out ideas. The cost is low, so there is minimal resistance to trashing a prototype when it doesn't meet expectations.

If the prototype is going to become the released product one of two things will happen...

* Lots of time will be invested on making a robust prototype, which means it
  will take a long time to build relative to a throwaway prototype, and
  there will be serious resistance to starting from scratch if the prototype
  tests poorly. Instead the team will be motivated to tweak the prototype to
  fix issues, when the best solution may be a totally different approach.
* The prototype will not be robust, the team will iterate through changes as
  quickly as possible with little regard for writing maintainable code - as
  they should (IMO). Then the time will come to "productize" that mess of a
  prototype... good luck with that.

 

Additionally, I don't see the role of the interaction / UX designer to make the product pretty. A designer should be directly involved in the creation of prototypes - from simple wireframes to interactive code. Design should be driving system architecture and implementation decisions, not the other way around. Making the UI look nice after the fact is the /"lipstick on the pig"/ school of design. Visual design is important, but too often it's seen as the sum total of design's role in software development.

26 Mar 2010 - 5:20pm
nixkuroi
2010

I agree with this line of thinking.  What's the general consensus on Microsoft's take on prototyping with sketchflow where you essentially craft the interaction first with very sketchy (black and white lines/boxes) placeholders for controls, get the general application flow approved, and then style after the fact. 

  This isn't to say that the designer can't have a design in his back pocket, but essentially  stakeholders get a black and white workflow version until you get the desired interaction model in place.  I think the theory here is that once you start showing stakeholders a design, their opinions of the entire workflow are influenced by their affinity for the design and they start redesigning the app for you before they see all the moving parts.

  I've tried this process out and it's seems hard to get the stakeholders to get excited about anything (they start getting restless immediately, because they can't show their bosses screenshots of things getting done and find it hard to justify a designer/UX architect who is turning in nothing but crappy looking interfaces).  This can be an educational issue where you have to make your stakeholders evangelists of the approach until implementing the actual design, but adds a little stress.  On the other hand, you have what Mr. Myles mentions where you start designing a prototype and the more real it gets, the less likely you can go back and do any real Architecture and the entire thing is build on crap.

  Is there a happy medium?
  On Wed, Mar 10, 2010 at 2:52 PM, Mike Myles <contact@ixda.org> wrote:

I believe prototyping is essential, but there is a pitfall with prototypes that evolve into the end product. Prototypes are generally not architected in a way to be robust and extensible - they are (and should be) quick & dirty implementations that let the team try out ideas. The cost is low, so there is minimal resistance to trashing a prototype when it doesn't meet expectations.

If the prototype is going to become the released product one of two things will happen...

* Lots of time will be invested on making a robust prototype, which means it
 will take a long time to build relative to a throwaway prototype, and
 there will be serious resistance to starting from scratch if the prototype
 tests poorly. Instead the team will be motivated to tweak the prototype to
 fix issues, when the best solution may be a totally different approach.
* The prototype will not be robust, the team will iterate through changes as
 quickly as possible with little regard for writing maintainable code - as
 they should (IMO). Then the time will come to "productize" that mess of a
 prototype... good luck with that.

 

Additionally, I don't see the role of the interaction / UX designer to make the product pretty. A designer should be directly involved in the creation of prototypes - from simple wireframes to interactive code. Design should be driving system architecture and implementation decisions, not the other way around. Making the UI look nice after the fact is the /"lipstick on the pig"/ school of design. Visual design is important, but too often it's seen as the sum total of design's role in software development.

(((Please leave all
10 Mar 2010 - 6:43pm
Stephen Holmes
2009

Beware of HTML prototyping moving into production. A project I worked on once had so much commented out cruft from the prototype that it was a nightmare to maintain as different developers tried to shoe-horn their xhtml code into some really ugly templates! And they left a lot of my very badly written Javascipt is as well. Not pretty!

I'd also say beware of making the prototype look too smart as it is harder to change a visual design once a client is used to the prototype; they see it as "finished" and so any changes in interaction caused by later unforeseen issues can be a problem later if they have to go through a rigid change process.

26 Mar 2010 - 5:20pm
Thai Lam
2007

I've also found client expectations to be one of the biggest issues when doing too robust a prototype. Even if it looks like a bunch of boxes straight out of a wireframe, most of the time clients have a tendency to assume the functionality is ready to go. Client management when presenting a prototype is a definite must.

The other issue to be aware of is how clean your prototype code is. If you're going to use it for final production you'll need to invest in any code validation or guidelines. An example, it would take more time to go back and recode a generated HTML prototype to make it 508 compliant.

I'm of the belief that an HTML prototype should just showcase functionality or the flow of a scenario. It should be something that can be quickly whipped up, quickly modified, and can be completely tossed out when concepts are approved.

On Wed, Mar 10, 2010 at 7:22 PM, Stephen Holmes <contact@ixda.org> wrote:

Beware of HTML prototyping moving into production. A project I worked on once had so much commented out cruft from the prototype that it was a nightmare to maintain as different developers tried to shoe-horn their xhtml code into some really ugly templates! And they left a lot of my very badly written Javascipt is as well. Not pretty!

I'd also say beware of making the prototype look too smart as it is harder to change a visual design once a client is used to the prototype; they see it as "finished" and so any changes in interaction caused by later unforeseen issues can be a problem later if they have to go through a rigid change process.

10 Mar 2010 - 11:50pm
John Yuda
2009

I abandoned the wireframe deliverable for clients years ago in favor of HTML prototypes -- as websites get more and more interactive, I think it's really important to get a handle on the behavior early on.

That said, I try very hard to keep these prototypes from looking like a finished product at all. They're highly clickable, and a great tool, but I keep them black & white and don't even use clients' real logos, that sort of thing. The visual designer would then be encouraged to go to Photoshop or whatever.

One of the keys, I find, is that I write a lot of sloppy code in these prototypes; I don't need them to be cross-browser compliant, degrade gracefully, etc, and I think this is important. As Mike and Stephen said, it's really useful to be able to iterate quickly and throw away directions that don't work.

11 Mar 2010 - 4:10am
josef
2010

Thanks for the comments guys, I wanted to open up the discussion of this topic. I take on board what has been said here. I plan to use the prototype I am creating as a visual/interactive spec rather than progressing it to full product, the HTML prototype I am creating is visually unacttractive, just black and white and simple with basic JS interactions. I guess I find that using HTML/CSS/JS (IxEdit New window) is quick for me, since it is what I know best.

I have tried playing with other tools such as Balsamiq and Axure Trial but find that pen and paper are great for sketching wireframes, and then I just construct my own HTML prototype from that. That is my process at the moment, but things can change depending on what other options are out there. I would really love to try other tools.

26 Mar 2010 - 5:21pm
John Loy
2009

I'm a big fan of HTML prototypes versus static wireframes. I wear two hats in a small firm, however, as both a UX designer and front-end engineer. This fact makes HTML prototypes a natural choice for my personal workflow, as I can entirely oversee and control the evolution of the prototyped HTML, CSS, and Javascript from "quick and dirty" to refined production-ready code. So far I've found that even the quality of code that emerges from prototypes is a better starting point than no code at all. Having the markup already in hand, in particular, is a great bridge and speed boost when working with designers and developers. It serves as both a usable code asset and a design schematic that communicates on several levels, hinting at content divisions, UI controls -- a class of .datePicker on a form text input, for instance -- UI states in cases where Ajax is used, and even database/domain modeling to some extent. And of course the greatest virtue of HTML and hypertext is its natural ability to indicate flow.

Cheers,

John Loy User Experience Designer, Intalgent http://intalgent.com (434) 981-7529 twitter: johnloy skype: johnmloy

On Thu, Mar 11, 2010 at 8:51 AM, josef wrote: > Thanks for the comments guys, I wanted to open up the discussion of this > topic. I take on board what has been said here. I plan to use the prototype > I am creating as a visual/interactive spec rather than progressing it to > full product, the HTML prototype I am creating is visually unacttractive, > just black and white and simple with basic JS interactions. I guess I find > that using HTML/CSS/JS (IxEdit [1] New window) is quick for me, since it is > what I know best. > > I have tried playing with other tools such as Balsamiq and Axure Trial but > find that pen and paper are great for sketching wireframes, and then I just > construct my own HTML prototype from that. That is my process at the moment, > but things can change depending on what other options are out there. I would > really love to try other tools. > >

9 Dec 2010 - 5:05am
Mathew Sanders
2009

IxEdit looks amazing - I just wish I'd known about it a couple of weeks ago - already started prototyping in Flash, argh!

On 12 March 2010 02:41, josef <contact@ixda.org> wrote:

Thanks for the comments guys, I wanted to open up the discussion of this topic. I take on board what has been said here. I plan to use the prototype I am creating as a visual/interactive spec rather than progressing it to full product, the HTML prototype I am creating is visually unacttractive, just black and white and simple with basic JS interactions. I guess I find that using HTML/CSS/JS (IxEdit [1] New window) is quick for me, since it is what I know best.

I have tried playing with other tools such as Balsamiq and Axure Trial but find that pen and paper are great for sketching wireframes, and then I just construct my own HTML prototype from that. That is my process at the moment, but things can change depending on what other options are out there. I would really love to try other tools.

11 Mar 2010 - 11:19am
nmwiggins
2010

Every method of prototyping has some pro and con. HTML is interactive and is very easy to test users with but it can take quite a bit longer than static comps. The use of Flash for prototyping has become popular over the last year because it is easier to add intricate interactions but the learning curve is steep. When time is an issue you can't beat the speed of static wireframes. I really believe the deliverables should depend on the job.

That said, I use wireframes and/or comps when the architecture isn't clear otherwise go straight to high fidelity HTML as much as possible to make sure I am ready for user testing if deadlines shrink.

11 Mar 2010 - 12:30pm
aronoff
2010

I just got out of a two day workshop at MAYA Design about human centered design, and we did rapid paper prototyping. To me, I think that getting the tactileness of HTML is good, but sometimes it may get in the way of starting the testing. For example, we learned quite a bit in the two days, designing a radio interface with multiple screens, did user testing, complete with feedback both audibly and visually without having to write one line of code.

I'm starting to realize that restraints are good, as always, defining your problem.... but that sometimes you shouldn't start using a technology if it impedes on the flow of the project or interface.

Just my two cents, for what it's worth.

P.S.

I will probably write a review on my blog sometime soon.

11 Mar 2010 - 4:29pm
nixkuroi
2010

I agree with Mike's line of thinking.  What's the general consensus on Microsoft's take on prototyping with sketchflow where you essentially craft the interaction first with very sketchy (black and white lines/boxes) placeholders for controls, get the general application flow approved, and then style after the fact. 
 
This isn't to say that the designer can't have a design in his back pocket, but essentially  stakeholders get a black and white workflow version until you get the desired interaction model in place.  I think the theory here is that once you start showing stakeholders a design, their opinions of the entire workflow are influenced by their affinity for the design and they start redesigning the app for you before they see all the moving parts.
 
I've tried this process out and it's seems hard to get the stakeholders to get excited about anything (they start getting restless immediately, because they can't show their bosses screenshots of things getting done and find it hard to justify a designer/UX architect who is turning in nothing but crappy looking interfaces).  This can be an educational issue where you have to make your stakeholders evangelists of the approach until implementing the actual design, but adds a little stress.  On the other hand, you have what Mr. Myles mentions where you start designing a prototype and the more real it gets, the less likely you can go back and do any real Architecture and the entire thing is build on crap.

12 Mar 2010 - 12:07pm
Bender
2009

I recently worked on a project for which I used an html prototype for the mockups. 

I used the excellent Fluid 960 grid system for those: http://www.designinfluences.com/fluid960gs/

But I had mixed feelings when it came to creating the hi-fi html/css mockup. One of the reasons I had chosen to go with html prototypes was that I thought I could easily style that mockup htmls and convert them to final designs (based on my hi-fi photoshop designs for the final look).

In reality, I found the original html mockups not flexible enough to directly convert into final designs, and I had to re-do the html/css from scratch for the final designs. 

So while the interaction the prototype html mockups provided were great for the client, overall it greatly increased the amount of work I had to do, and this particular  client would have probably been just as happy with simple images for the lo-fi prototypes.

Here are the links to the lo-fi and hi-fo html mockups for those interested:

http://legofishlabs.com/clients/wwqi/16/fixed/ 

http://legofishlabs.com/clients/wwqi/production/

15 Mar 2010 - 10:32am
Dasbender
2009

I often find myself in an internal catch-22 debate regarding hi-fi vs lo-fi prototyping.  On one hand I want to do lo-fi for all the reasons stated (sloppy is faster, people are more open to changing a lo-fi prototype, etc), but on the other hand, I often find that hi-fidelity design is the only way to prove out a design.  The devil's in the details after all.

If I try to convince my clients of a solution using black & white blocks to chunk up the screen space, they'll say things like "it's too cluttered" or "it's not intuitive."  I can respond with "trust me -- I'll resolve that later on when I get to hi-fi" but that rarely works.  Instead they'll start brainstorming ways to *fix* the design by adding extra labels, extra pop-up dialogs, and extra steps.  The only way I can prove out the elegance of a design is to show them an elegant looking UI.  They can't imagine what they don't see in front of them.

Low fidelity prototypes only work when communicating to other UI designers.

Actually, lo-fi is also appropriate you're mocking up a change to something existing, or extending an existing template.  Then clients can *imagine* by looking at the existing UI, and my lo-fi prototype can simply have a big box that says "detail from existing application goes here."

My choice of HTML (vs Visio, Photosho, iRise, paper, or whatever) totally depends on the skill & speed of the prototyper, as well as the complexity of the UI we're prototyping.  For example, a static brochure-ware website never needs more than static mock-ups.  But a drag-and-drop UI that relies on keyboard commands will almost require a prototype built in the final development environment to truly test out its usability.

26 Mar 2010 - 5:31pm
philipbrook
2008

Surely protoype fidelity depends on the type of issues one is attempting to drive out and the phase of project, so isn't the HTML debate largely a red herring. Especially if one considers that HTML is simply a language that can (literally) markup lo- mid- or hi fidelity interfaces, journeys, interactions, animation sequences, etc. You can do the same task with many other tools, from the filthy PowerPoint and beyond (yes even powerpoint). A bigger debate is why HTML given that, for most people who aren't specialist developers, the time it takes to crank out pages of the stuff that doesn't break, is a prohibitive craft-based overhead to getting a prototype out.


From: Dasbender <contact@ixda.org>
To: p_brook@yahoo.co.uk
Sent: Mon, 15 March, 2010 15:45:50
Subject: Re: [IxDA] Thoughts on HTML prototyping before design?

I often find myself in an internal catch-22 debate regarding hi-fi vs lo-fi prototyping.  On one hand I want to do lo-fi for all the reasons stated (sloppy is faster, people are more open to changing a lo-fi prototype, etc), but on the other hand, I often find that hi-fidelity design is the only way to prove out a design.  The devil's in the details after all.

If I try to convince my clients of a solution using black & white blocks to chunk up the screen space, they'll say things like "it's too cluttered" or "it's not intuitive."  I can respond with "trust me -- I'll resolve that later on when I get to hi-fi" but that rarely works.  Instead they'll start brainstorming ways to fix the design by adding extra labels, extra pop-up dialogs, and extra steps.  The only way I can prove out the elegance of a design is to show them an elegant looking UI.  They can't imagine what they don't see in front of them.

Low fidelity prototypes only work when communicating to other UI designers.

Actually, lo-fi is also appropriate you're mocking up a change to something existing, or extending an existing template.  Then clients can imagine by looking at the existing UI, and my lo-fi prototype can simply have a big box that says "detail from existing application goes here."

My choice of HTML (vs Visio, Photosho, iRise, paper, or whatever) totally depends on the skill & speed of the prototyper, as well as the complexity of the UI we're prototyping.  For example, a static brochure-ware website never needs more than static mock-ups.  But a drag-and-drop UI that relies on keyboard commands will almost require a prototype built in the final development environment to truly test out its usability.

15 Mar 2010 - 11:20am
stephengay
2010

Dasbender,

 

There is no magical guide to selecting the right fidelity for wireframes or prototypes. From my experience each client can require a different presentation solution based on the scope and project complexity  

 

But from my experience:

  1. Sketching wireframes using a whiteboard or a pencil and paper is exceptionally useful for collaboration and complex design problems. (*Take pictures with a digital camera for records)
  2. Lo-fidelity prototypes (B&W wireframes) are useful for complex interaction solutions (i.e. forms and portals). Customers will focus on the interaction details instead of the visual design.
  3. Hybrid prototypes (B&W wireframes with visual elements) are very useful for template interaction solutions. Customers typically like to see visual elements in context of forms. This method kicks off early visual design concepts
  4. Hi-fidelity prototypes are useful for simple interaction solutions (i.e. content pages) or revisions / updates.  I use hi-fidelity prototypes when existing visual design standards have already been established. The new prototypes are created to communicate a change or enhancement to an existing project. IMHO; Hi-fidelity prototypes are risky early in the process as interaction decisions can be confused with visual design decisions.

 

22 Jul 2010 - 6:32am
bente
2010

I am torn in this discussion. 
I hate wireframes, really.
I love to build html and css. I love paper and whiteboards.

But I have also experienced making a full-colour sketch in illustrator, with dummy images, and the client saying "great! Why doesn't it work!?" And you know that is a couple of months down the line...

I hate the outline wireframes. I can visualize the general idea, the wonderful interaction and graphic design plan behind it, but seemingly; few people can. Besides, for me they are too often too conceptual; idealized. It is a difficult balance between keeping client engaged and enthusiastic, and they  - as mentioned above - starting to "fix" the design.

I am happiest with arcitecture, interaction design and graphic design. I imagine that the method for building a prototype rests on the creators preferences and abillites. I would be delighted to go head first into architecture, interaction and graphics all at the same time; to represent the magic when they work together. That means testing a little in various ways, and keeping a minimum of three thoughts in your head at the same time. I go through a good deal of notebooks, with storyboards and sketches the client will never see.

Having clearly done mistakes in presenting pdf's that the client think should work; I am going back to pencil, paper and storyboards for the initials, and simple greyscale html dummies.  I see the danger of garbage code sneaking its way into the product/prototype, but I try to work under the idea of "design by removal".

I appreciate Stephen Gays list above, and his point that it depends on who you are working for. I would add: and it depends on what sort of data/information is being handled.

9 Dec 2010 - 1:26am
scott.allerdice
2010

appreciated your concern on it but at the same point it also depends on the situation, environment, tools and technology you are working with.

Scott Allerdice
Software Engineer
mobile application development

Syndicate content Get the feed