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.
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!
Leave a reply