The new Handcraft is here!

How 37signals does HTML prototyping

No wireframes

A slide from Jason Fried's talk, "Backstage at 37signals"

Last month at UIE’s Web App Masters Tour conference in Philadelphia, Jason Fried gave a talk about 37signals‘ design process. It was a look backstage at a prominent web company and was fascinating because most of his talk went really in-depth in illustrating what a conversation between team members looks like during the design of a new screen or, in this case, redesign of something fundamental.

Jason talked about a couple of things they wanted to do with the Basecamp Overview screen and how they went about doing them. One of 37signals’ other products, the collaboration tool Campfire, took center stage: everyone works together remotely using it, and in the case of this design session, they were exchanging sketches and suggestions of user interface changes. One person would upload a picture of something, be it a sketch, Photoshop mockup or screenshot of a live change in HTML, and other people in the discussion would comment.

This back and forth went on for a few hours until Jason, Ryan and co. were happy with the change and decided to go for something. Unfortunately Jason didn’t share the chat log he was displaying during his presentation, so it’s hard to reproduce what they ended up deciding to do here, but the result made a lot of sense and seeing the process evolve that way.

All in all, seeing a combination of objective argumentation, gut feeling, quick iterations and a complete lack of ego-based decision-making lead to real improvements was valuable insight into another way of doing things.

Some things can’t be described in text

During the presentation, Jason commented often that the screenshots their designers were exchanging back and forth were usually quick mockups in HTML. Each designer can write basic code, and the best way to talk about ideas is to show them to one another the way you want them to look. Jason’s words: “Some things can’t be described in text”.

Here are some notes from his slides that were particularly apt, accompanied by my comments:

  • UI First. When deciding on a new feature or change, start with the UI, not something else like the graphic design.
  • No wireframes. Wireframes are like doing double work: first you make the wireframe, then you make the wireframe again in HTML. Why not just do it once?
  • No schematics/documents. Documentation about user interfaces make little sense, since while you can talk about how something works forever, you’ll never know how or whether it actually works until you write the code.
  • No programming first or Photoshop. Controversially, Jason noted that they don’t do work in Photoshop up front. They also don’t spend time making something work “for real” by programming it. What they do do is write the new UI in HTML and Rails templates and mock them up enough that you can get a feel for how something will work. The idea is to spend minimal time for maximum effectiveness.

Abstractions aren’t real

Jason’s and 37signals’ philosophy is this: get rid of abstractions, they aren’t real. Technical specifications and Photoshop files are abstractions because they’re not the real app. Wireframes are abstractions because they aren’t the real app. “They represent real, but aren’t,” says Jason.

A user interface sketch Jason did using Draft

A user interface sketch Jason did using Draft

At the same time, Jason mentioned a couple of tools they do use to convey designs to one another: sketches, sharpie markers, and an iPad app that at the time was under development and has since been released as Draft.

Sketches work because they allow you to jot down an idea in seconds and have it be understandable to others, although it should always be extended into a full design exploration afterwards using HTML.¬†Sharpie markers are Jason’s favorite because they prevent you from getting too detailed at an early stage; all you can do is make big thick lines. And Draft is designed intentionally to force you to create low fidelity mockups and share them quickly with other people.

How quplo fits into all this

I was really excited hearing about this at the conference because I knew that quplo mirrored much of what one of the UI design industry’s leading companies believes so strongly in: prototyping should happen in code, in the browser.

While we don’t believe wireframes are completely unnecessary, (in fact, we believe they have their place in various organisations and hierarchies where there are bureaucratic processes that designers can’t get around, for instance) we think prototyping your web app in the browser is something you need to get to as soon as possible. We think skipping technical specifications and showing your peers and clients what you’re talking about is better than talking about it. In that sense, we agree with 37signals’ fundamental arguments.

And that’s great, because if you jot down your UI ideas using a tool like Draft (or even on pen and paper), 37signals argues that your next step should be prototyping in HTML. That’s where quplo comes in.

If any of this sounds interesting, sign up for the quplo preview and find out how we’re filling the gap in prototyping tools. If you like 37signals and Draft, you might like quplo as well!

10 Comments

Ping RSS

  • [...] Signal’s recently reveal that they don’t do wireframing at all… they start prototyping in HTML right away. If you know your the difference between and class and and ID and are not afraid of writing code to [...]

    Pingback

    by Create a quick website mockup with the best wireframing tools - Technology advice from Freelance Advisor • Jul 22nd 2010 • 10:07

  • [...] from the website concept and high-level information architecture to visual comps and ultimately real HTML, CSS and interactive behaviour. Once the site is live, you never go back to the wireframes. Until [...]

    Pingback

    by Kodstok » Blog Archive » Wirify: The web as wireframes • Dec 21st 2010 • 13:12

  • I’ve come to the same conclusions. Now I’m looking to see if anyone has a code snippet library available of typical user interface “wireframe like” objects. There is jquery UI and YUI but there are more focused on a bunch of crap we don’t need like accordian boxes etc… We need typical navigations, typical form objects, search fields etc… I can assemble this myself, but was hoping you might know of a pre established code library.

    by Design coder • Feb 20th 2011 • 23:02

  • I’m developing a simple prototyping mechanism and one of it’s features is code reuse. It uses smarty and php and can be installed on local maschine. So what does these things give me? I can write powerful template snippets that I use over and over again. Output is compiled to html and saved to disk.

    So for example {partial tpl=img src=foo.gif} produces

    If I add alt – {partial tpl=img src=foo.gif alt=”yay, i’m the alternative text”} – output will be

    width and height are ofcourse read from the image by that small template file – img.tpl.

    So I have these small template files for form elements, tabs, lot of project based repetetive blocks etc.

    Because I’m using smarty I have all the power of it. For example if I need to fill up the page with 50 images, I just do
    {for $i=0;$i<50;$i++}
    {partial tpl=img src=foo.gif}
    {/for}

    There are layout templates (used for header, footer), page templates and partials (which I just talked about).

    In layout template I can for example add navigation. Navigation can be written so that it checks which page I'm and include selected class.

    Example

    Frontpage
    Text

    If somebody asks me to change navigation, I just change it one place and the whole prototype is updated.

    All in all: prototyping in php + smarty is fun!

    If anybody is interested, write me a letter. I’d happily share my code. I want to make it open source anyways.

    by Hannes • Apr 5th 2011 • 20:04

  • hkirsman@gmail.com

    by Hannes • Apr 5th 2011 • 20:04

  • and the html was cut off :(

    by Hannes • Apr 5th 2011 • 21:04

  • [...] can not only build prototype fast in paper but also build it fast with HTML. 37signals is known as building HTML prototype directly from idea. They also mentioned why HTML prototyping is better than Photoshop mockup. I [...]

    Pingback

    by How we hack and prototype our games before jumping into coding • Sep 19th 2011 • 22:09

  • [...] (not strictly prototyping but often used for it), balsamiq, omnigraffle, axure and HTML. Yes, html. More and more people are beginning to think prototypes should be done in code within a [...]

    Pingback

    by 10 tips: For Designing a Good Responsive Website | BaseNow • Dec 11th 2012 • 21:12

  • [...] [...]

    Pingback

    by Design-in-browser, are you ready? | Radical Blog • Feb 18th 2014 • 16:02

  • Leave a reply

    You must be logged in to post a comment.