Earlier this week I went to Ryan Singer’s workshop on Designing Web Application User Interfaces. Ryan is a designer at 37 Signals, the company behind the massively popular Basecamp project management software (which I use myself all the time) and several other useful web apps. Here are some thoughts on the workshop.
Clean UI Design
Ryan has a real ability to simplify and re-structure a UI so that it communicates as clearly and effectively as possible. The basics of his approach are available in a paper on UI Design Patterns he wrote a few years ago. He argues that most of the important work in UI design actually consists of writing copy, rather than creating graphics or layouts. Cleanly written labels and headings are the key to improving ‘scanability’ and therefore a clear UI. Sort of reminds me of Oliver Reichenstein’s observation that 95% of web design is typography. And seeing Ryan in action working on a UI was definitely useful for me, even though I already know much of the ‘theory’ and have done it many times myself. It gave me a bit of a fresh perspective.
Designing for Yourself
37 Signals seem to follow a sort ‘expert-led’ design philosophy. They don’t really do user research. And I suspect they can get away with this partly because they are designing for themselves and for people just like them – other web geeks. It’s a pretty liberating way to work and it’s clear that they’re good at what they do, but I wonder if they would be quite so successful if they were designing web apps a completely different demographic. Basecamp is great but I wonder sometimes if non-geeks really ‘get it’. For example, at work when we ask non-techy clients to use it, they often seem to prefer email and telephone calls.
I was also a little bit shocked by Ryan’s admission that he ‘doesn’t really think about accessibility’. Perhaps that also says something about the target audience for their apps. But it wasn’t an entirely helpful stance to take in a workshop teaching a general audience in the UK about web app design.
Ryan told us quite a lot about how the team works at 37 Signals. One clear advantage of using an MVC framework like Rails is that, because of the strict separation of markup from program logic, the designer can continue to ‘own’ the front-end CSS and HTML right through the life-cycle of the product. This sounds really ideal and I’m sure it makes a huge difference to the final quality of the interface. It can be really frustrating as a designer to hand over a carefully constructed HTML template, only to see it gradually erroded and degraded as it is integrated into the back-end and new functionality added.
Another key aspect of the 37 Signals workflow is the practice of designing directly in HTML. I think this kind of an interesting idea and has some upsides. Clearly it can work well and it results in designs that work with, rather than fight against, the medium of implementation. But it occurs to me that all of 37 Signals’ applications are very much purely functional ‘tools’. For some web apps imagery and ‘visual design’ are more important and in those cases where you need ‘more graphic design’, working directly in HTML is going to be very inefficient.
Overall it was valuable to see Ryan in action and to get first-hand exposure to the way he thinks about and analyses UI problems. I’ve already found myself thinking in a slightly different way when designing a complex page. It has also led to some useful discussions about how to allow designers to keep ‘ownership’ of HTML markup right through the life-cycle of a web application. I think that is something 37 Signals have got exactly right. I think Ryan could make his workshops even better by doing a bit of extra research about the general environments people have to work in today, and considering some of the issues we face. For example, accessibility is quite an important issue and can’t just be brushed aside, and designing directly in HTML is not going to work for every kind of web application.