I totally agree with Andy that it makes a lot of sense to show clients HTML/CSS/JS prototypes rather than static visuals, but I’m not sure how to reconcile this with the needs of our clients, as well as our resources at Blue Flavor. For us, the trouble with interactive prototypes is twofold:

  1. Clients tend to want to see constant updates along the way. If we don’t show them anything until we’ve got an interactive prototype, they’re not going to be very happy.
  2. Getting all the way to an interactive prototype is a lot of work. If we get there, show it to clients, and it turns out they’re not happy with the direction, we have to re-do a ton of work. This is one of the main reasons we like to show a lot of progress along the way. If at any point the client isn’t satisfied, we can’t quickly change course without redoing a whole lot of work.

In short: I totally agree with Andy, but saying “we should do interactive prototypes instead of static design visuals,” is the easy part. Figuring out how to actually make that work within your business model is harder. If you can pull it off, awesome.

Visit site:

http://forabeautifulweb.com/blog/about/time_to_stop_showing_clients_static_design_visuals/

Comments

  1. 001 // Justin Lilly // 09.26.2008 // 10 PM

    Hey Jeff, Maybe 37Signal’s skipping photoshop has some teeth in this? If you didn’t go through your photoshop step, would it still be a lot of work? Having not worked in an agency, I’d imagine the process is discovery, mockups, clickable mockups, delivery. If you skipped step #2 and went right to #3… perhaps it would work? There are a host of issues related to moving to clickable mockups (the biggest of which is the client’s inability to see past placeholder text / images).

    PS. You should check the half rounded corner’d boxes in google chrome. There seems to be an odd black background (inable to do screenshots at the moment)

  2. 002 // Keith // 09.27.2008 // 9:37 AM

    I read this much the same way as you did. Sounds like a great idea, but I don’t know how we could actually work this into our process for the reasons you bring up.

    I would love to try this, but… I really don’t know how that would work.

  3. 003 // Jeff Croft // 09.27.2008 // 12:18 PM

    If you skipped step #2 and went right to #3… perhaps it would work?

    Perhaps, but skipping the Photoshop step bring new issues of its own. For us, it’s like this: Photoshop is great for getting the “broad strokes” of a design direction nailed down (visual aesthetic, basic layout, imagery, etc.). At this stage, it’s much easier to move things around, try new things, and trash everything and start over without losing too much work, compared to using HTML and CSS. At some point (which is, admittedly, a bit hard to define), you get to a stage where HTML and CSS becomes the simpler tool for the sort of tweaks and changes you need to make in the design.

    Put simply: HTML and CSS is great for the web part of “web design”. Photoshop is great for the design part. Maybe one day a tool will exist that handles both equally well.

  4. 004 // Muhammad Haris // 09.28.2008 // 3:58 PM

    A great designer who is experienced enough to think that his designs don’t suck and might simply require few design changes instead of a completely new concept from the scratch then getting quickly from design part to xhtml/css part will be easier, less time-wasting and more pleasing.

    I’m not that kind and it will simply take a long time for me to adopt Andy’s design habits.

  5. 005 // Kyle Weems // 09.28.2008 // 11:30 PM

    At Mindfly we’ve been talking a lot about the idea of showing HTML/CSS prototypes instead of static visuals, particularly whether we can make it work inside the business model.

    Since experience is the best teacher, we’ve decided to give the technique a try on a single client’s site to see what kind of problems or advantages it might present us in a billable environment.

    So far, it looks like it’s at the very least not detrimental on a time/cost basis. We saw more time in lead up to showing the client the first proof, but we also were able to absorb all that time in the time saved during the post-approval development.

    I agree the real risk is if the client dislikes the proposed proof altogether. Andy implies, though, that with practice the technique’s time used isn’t any greater than that used in a Photoshop mockup.

    I’ll need to see more than a few of trials with going straight to CSS/HTML before I can say whether it’s a notable improvement, but based on what I’ve seen so far we won’t at least be suffering any for switching.

  6. 006 // Jeff Croft // 09.28.2008 // 11:44 PM

    Andy implies, though, that with practice the technique’s time used isn’t any greater than that used in a Photoshop mockup.

    Right, but I’m not really convinced. I’m actually way better at HTML and CSS than I am at Photoshop, and I still find Photoshop faster for many tasks.

    I’ll need to see more than a few of trials with going straight to CSS/HTML before I can say whether it’s a notable improvement, but based on what I’ve seen so far we won’t at least be suffering any for switching.

    Good to hear — and I definitely think you’re doing the right thing by giving it the ol’ college try. :)

  7. 007 // Justin Lilly // 09.29.2008 // 6:16 AM

    Out of curiosity, which things specifically do you find photoshop useful for in terms of layout? I understand the gradient/color benefits of using photoshop. If an enterprising person should come around and see this post and he wanted to build a tool to help you(us) bridge the gap, could you tell him which features you would need to be able to leave (or greatly lessen the usage of) photoshop in your initial client work?

  8. 008 // Jeff Croft // 09.29.2008 // 11:05 AM

    Out of curiosity, which things specifically do you find photoshop useful for in terms of layout?

    Mostly the ability to draw guidelines, and then draw boxes and shapes and click and drag to move them around, snapping to the guidelines.

    But, certainly, the biggest advantages of Photoshop are in the imagery department. I simply can’t do all the blending and effects I usually need to do in CSS — and even where I can (for example, text-shadow), it’s less efficient to do the whole adjust css/refresh browser/preview/rinse/repeat thing than it is to simply check the “preview” box in Photoshop.

  9. 009 // Justin Lilly // 09.30.2008 // 1:56 PM

    Welcome to ImageReady ;)

  10. 010 // Martin Bavio // 10.01.2008 // 1:03 AM

    @Jeff: I completely agree with you. Andy´s idea is really cool, but is not easy to make it work in an per-hour freelance job. But of course, he does not have that problem, because he´s a fucking web design rockstar. Well, I´m far from that, so I don´t see how to implement it without throwing some job to the trash.

    @Justin: you mean Fireworks? ImageReady is dead, dude.

Post your comment

Sorry, the time to post comments to this entry has expired.