At the UIE Web App Masters Tour in Seattle WA, Ryan Singer described how 37signals solves design problems and collaborates by walking through the early stages of a new project in his talk Backstage with 37signals.
- An interface is the boundary between people and databases. If you are only thinking about people, that’s only half of the equation. Start out by thinking about the database first.
- When you think about the database, you can develop a model of the data that is required in an application. You can then work from this model object to determine how data will flow in and out (the app’s interactions).
- There are some general patterns you can apply to most projects. 37signals uses index and show views in most apps. An index view provides an overview of content. Show views are detailed looks at individual items.
- All projects at 37signals start with a low level of fidelity. They sketch out screens that represent an application’s data model. These sketches are very rough and don’t have much detail.
- From these basic lightweight sketches, 37signals moves to HTML code. They don’t create diagrams, wireframes, or detailed visual designs. Just rough sketches to HTML.
- It’s appropriate to jump into Photoshop for quick looks at how things might layout (if the markup would take too long) but it’s best to throw these files out when you are done since there is no direct connection between Photoshop comps and running code. Photoshop is for quick explorations not for deliverables. Only bring it up to do what’s to hard to quickly design in HTML & CSS.
- There is one developer and one designer on each 37signals project.
- The views folder in 37signals development environments is the responsibility of the designer. This is where markup files have embedded Ruby commands to access backend systems. This puts real data in the HTML designs.
- Model, sketch, HTML, and build everything.
- Sketches help express a problem, moving to HTML with embeddable code allows real data to be in the designs right away.
- Higher fidelity items tend not to result in actual running code. It’s better to put all your energy into lightweight sketches and running code. These two parts of the process provide the most value.
- Design step by step: do small things at a time, get them working, then move on to the next item. Take bits of functionality that are needed and build them out one at a time until you have what the application needs.
- Design from the inside out: start with the epicenter of a product and build outward. Keep your focus on the epicenter of the product you are designing.
- Need to get feedback on use as soon as possible. Seeing customers use your product is secondary feedback. Primary feedback is using it yourself.