Take the 2-minute tour ×
User Experience Stack Exchange is a question and answer site for user experience researchers and experts. It's 100% free, no registration required.

I've read some articles (this one and this one) recently that are opening my eyes to HTML mockups as opposed to the usual PSD mockups.

In the article they cite certain pros:

  • Changes are a lot faster (including changes to colors, and to some extent to fonts).
  • When you're laying the page out as HTML, you're showing the client something a lot closer to what the final product will look like.
  • They can see the effects of a liquid layout by changing the size of the window.

Cons:

  • Not all visual designers can create a mockup in HTML. It will have to be a two person task. An HTML person and a Photoshop person.

What do you guys see as pros/cons to either approach?

share|improve this question
2  
What are you mocking up? An application? A poster? A website? Sounds like the latter, but please clarify. –  Glen Lipka Sep 10 '10 at 19:44

7 Answers 7

It's not the visual designer's job to prepare interactive mockups, but rather that of the UI / UX designer. True - often they are one and the same, mainly due to budget reasons, but their jobs are very different.

Your question could in fact be rephrased as Static vs. Dynamic mockups.

In my opinion dynamic mockups are almost always superior to static ones:

The main reason in my opinion is that they can be used for accurate usability testing - imagining you're doing something is very different from actually doing it, realizing the time it takes, the amount of clicks, movement, etc. Thus it provides a real feel of the flow in the system.

However, nothing is without a price - creating a dynamic mockup usually requires considerably more time. Moreover, it creates higher expectations with the customer - if you press one button and it does something in the system, you'd expect all the buttons to performs the same (and some might be less relevant to the main scenario).

With a static mockup it might also be easier to guide the customers and developers through the use cases - you simply show the screens one by one in the "correct" order, making sure all the use cases are covered as you intended. While using a dynamic one might give the users "too much" freedom, making them miss key use cases, etc.

BTW - you don't have to be a programmer to create html mockups. There are plenty of tools (for example Axure, Balsamic, Flair Builder and many others) that allow creation of such mockups by non-programmers.

share|improve this answer
    
Disagree about mockups taking more time in HTML. It completely depends on the person; I work much faster in HTML/CSS than Photoshop, for instance. Static vs dynamic usually boils down to tool A vs tool B, and in that case it's question of proficiency. –  Rahul Sep 11 '10 at 11:20
1  
I make a clear distinction between HTML mockups and Axure/Balsamic/etc HTML mockups. Axure, IMHO, is great for dynamic paper prototyping. It's not a tool for mocking up detailed interactions, however, as it lacks the fine details that one gets with proper HTML, CSS and Javascript. –  DA01 Sep 20 '10 at 20:19

One potential drawback of using HTML mockups are that the client could think that you've finished the application - even if you've told them what it is.

Seriously, I've known people - both clients and managers - who on seeing a mockup using the tools you normally use to build the actual product think that you've done most of the work and are surprised when you say it will take another 6 weeks (or however long) to actually do the work.

Having the mockups one step removed might help dispel this misunderstanding.

However, having said that a dynamic mockup will allow you and the client to have a better understanding of how the system works and how you navigate through the application.

share|improve this answer
1  
I have experienced this. Something that has helped to get around this a bit is by adding Javascript click handlers that throw alert('this is not implemented'); and other similar tactics. - On the flip-side, there is some truth to the fact that HTML mockups (if done well) get you closer to the finished product. –  jessegavin Sep 10 '10 at 20:22
    
That's not a drawback of HTML mockups, that's a drawback of not setting client expectations and communicating about what you're doing. –  Rahul Sep 11 '10 at 10:21
4  
@Rahul - it surprising how many people don't listen when you tell them though. –  ChrisF Sep 11 '10 at 11:43
    
I don't think it's about listening, I think it's about understanding. Telling them once might not be enough to communicate what the differences are. Educate, educate, educate! –  Rahul Sep 13 '10 at 19:21
1  
Trust me @Rahul -- it's about listening :-) –  Josh Sep 26 '10 at 13:56

If i'm right, I believe VB was initially written as a way of quickly knocking up some mockups... With that in mind, I'd say that the "right" answer is probably to go down the road of HTML mockups.

However, I am in the process of creating mockups for a new product as I type, and frankly, I don't believe the effort involved in creating html mockups that look as good as they do in PSD format, is worthwhile. Getting a bit of text, or an image, or etc, to appear exactly where you want it, with complex layout design is going to take a web developer longer to do than it would a photoshop artist with similar levels of skill.

Also, if you're going to do more than text and basic designs, you're probably going to be using Photoshop (or similar graphics packages) to do that design work - why bother complicating the matter?

Granted, if there is real justification for using interactive mockups (for example, a big user group to demonstrate how you think some particular interactive display will work), then the extra effort is worth it.

But if you're just showing a client how you think several windows of an application should look, I don't think the justification for the extra effort is there?

share|improve this answer
1  
One thing that I come across a lot is that sometimes there's a disconnect with what the visual designer thinks can be done in HTML. The PSD that they create may not be a true representation of what the final page may look like. I think that if there are some rules or conventions (like sticking to an agreed upon grid) which can mitigate this. Having said this, I don't think that there's a right or wrong here. One has to weigh the skills of the team and the amount of time available to create the mockup to determine which approach to take. –  milesmeow Sep 11 '10 at 4:24

Anecdotal Answer

I recently worked on a site where the main template was designed in Photoshop (which I'll refer to as "PS"), but the individual sections of the site still needed to be designed. I was working on several sections with some non-standard UI requirements and I had to decide whether I was going to mock them up in Photoshop or just do them with HTML/CSS. I chose the latter and was VERY thankful for it.

I actually started by marking up the page content and navigation elements in HTML. Once I had that, I just started playing with CSS and seeing what worked. I was able to very quickly create several totally different layouts and actually test them in a browser right away. There were several options that I knew wouldn't work almost instantly and was able to abandon them quickly (where I would normally have finished the design in PS). I was able to add interactive (show/hide/etc) elements too that wouldn't have been possible in Photoshop.

There some things that just go way faster in HTML vs PS, tables for instance. It takes some real effort to visually design tables in PS with variable text content inside the cells and headers. It is super fast in HTML and you actually see what it will really look like.

Of course this only gets you so far because you can't do everything with CSS. I would occasionally go back to Photoshop and create such and such an image for a particular part, but for the most part I was surprised to see how much I could do with CSS only.

My take

I am still going to take this on a case by case basis. But I am definitely going to lean towards HTML mockups in the future.

share|improve this answer

If you're building a web site or application, HTML mockups are far superior because you're designing the mockup in the format as close to the final product as possible. This allows you to set expectations much more easily, it constrains you to just what's possible in the final product, and it affords much greater flexibility.

This convention is gradually becoming known as "design in the browser". Designing in the browser circumvents the waterfall method by its very nature. Photoshop mockups introduce a barrier between the visual designer and the interaction/UX designer: the person working in Photoshop can be located far away, thinking completely in terms of visual fidelity, without considering the final product and accompanying constraints of the browser. Once the photoshop mockup is ready, it gets "tossed over" to the UX team to take to the next stage. This doesn't promote an iterative, feedback-oriented process.

I wrote a blog post a couple of months ago about this philosophy, which we've been using in building our prototyping tool. Here are some articles I referenced there that may be useful (including the one by Megan Fisher you linked to):

Other designers and developers agree with him:

  • 37signals’ Why we skip Photoshop explains their process: Photoshop mockups aren’t interactive; they don’t give you a feeling for the flow of the app; they encourage you to focus on details too early on.
  • Meagan Fisher’s 24ways.org article Make Your Mockup in Markup talks more about Clarke’s principles and explains how starting with the HTML structure allows designers to quickly iterate over multiple page layouts.
  • These 12 tips for designing in the browser over at Design Shack offer some good insights as well.

Finally, I have to plug our tool, Handcraft: it's built specifically for HTML prototyping and offers tons of advantages over the PSD mockup process. In fact, we're sort of picking a fight with that way of working and challenging assumptions. I don't want to get preachy in this answer, so if you want to learn more about the HTML mockup process as supported by a design and development tool built specifically for it, you should take a look at what we're working on.

share|improve this answer

It's a fidelity issue.

The catch is that either document can be higher fidelity than the other depending on what you are focusing on.

An HTML prototype is really the only way to truly mock up any interaction of even moderate complexity. There's simply no way to fully document interaction design within a PSD file.

Conversely, if you're in an environment where the visual design is being constantly tweaked/improved/iterated through, the PSD might be the better 'document of record' to handle the visual design elements.

In the end, I don't think it comes down to PSD vs. HTML. You need both in different amounts depending on the specifics of your needs on a project and team member basis.

share|improve this answer
    
Fidelity of your design/mockup/prototype also affects your clients' perception: higher fidelity mockups will invite less criticism, and will make your clients feel boxed in when they do offer feedback. A lower fidelity prototype makes it amply clear that this is a work in progress, and allows you to collaboratively explore other design directions without hesitation. –  jrharshath Jun 2 at 19:09

Good idea to revisit this topic.

With the increasing popularity of responsive design it makes even more sense to use a dynamic model (presumable HTML). When designing the initial rough layout I find myself constantly resizing browser to see how the layout works at many widths.

To try to specify a responsive design with a static image isn't possible, and to express it with multiple static images is time consuming and overly complex.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.