A couple weeks ago I gave a talk at the MFA in Interaction Design program at the School of Visual Arts in NYC. The video for the talk and Q&A session is online now. When Liz Danzico invited me to speak at the SVA, I thought it would fit the university setting to share some theory behind our design process at 37signals.
One book that heavily influenced my approach to design is Christopher Alexander’s Notes on the Synthesis of Form. Many designers cite the book as an influence, but few really explain what it’s about or teach how to apply the ideas in everyday work. So I took the opportunity to explain the key points of the book and show how we use Alexander’s model to do design at 37signals.
Here’s the video of the talk:
Some of the screenshots are hard to see around 38:30. Check the images below if you’d like to see those screens more clearly.
 |
 |
 |
 |
| Highrise history | Options behind a link | A new link to notify | Embedded notification form |
The talk was followed by a Q&A session. The Q&A touches on customer feedback, design vs. evolutionary selection and trusting your intuition.
Here are some things to check out if you liked the talk.
- Notes on the Synthesis of Form – The book by Christopher Alexander.
- An Introduction to Using Patterns in Web Design – An early article I wrote on Alexander’s technique when I first ran into it in 2004.
- Domain-Driven Design by Eric Evans – Mentioned at the end of the talk.
- UI Fundamentals for Programmers – A talk I gave at WindyCityRails in Chicago.
I’d love to know if people are interested in this material. Post a comment here or write me at ryan at 37signals dot com with your thoughts.
Matt Wright
on 21 Apr 10I haven’t watched the Q&A yet, but I loved the talk. Found it really inspiring, and found myself writing down ideas for my own projects throughout. I also hunted down more info on the Alexander and design patterns afterwards. As someone who’s just getting started in UI design, this stuff is totally helpful and exciting. Please keep it up. I’d buy a book of it!
Lucas
on 22 Apr 10Great work! It’s funny to see Eric Evans book on a design talk, reminds me that design is (more) important as coding or software architecture, and it should aim for the real world needs and not some requirements document.
How does the inside-out approach affects the general layout definitions ?? (positions and navigation, for instance)
Christopher Wright
on 22 Apr 10I’ve been finding these talks fascinating, like Matt it’s also inspired me to read up on Eric Evans and Christopher Alexander. This sort of content is great, Ryan!
Georges Duverger
on 22 Apr 10Great talk Ryan! Calm, very informative, and simple.
nathan
on 22 Apr 10I am ALWAYS interested in hearing more Christopher Alexander/ Pattern Language conversation. My wife has tired of me prattling on about unfolding sequences. Thank you for posting this and keep it coming.
Daniel
on 22 Apr 10You could have saved me a few years of college had you done this video earlier!
I’m kidding, but it’s always nice to see stuff really boiled down. I’m a design engineer, so much of my education was focused on specs, requirements and planning – pretty much all of the stuff you guys warn people about. My thesis was also attempt at getting away from those things and into how one defines contexts – not forms – in a usable way. But even so, I made the same “mistake” as Alexander in the sense that it became a too unnecessarily formal on its own. At least for small, agile teams since the thesis’ own context was the “larger design team” at large-scale corporations, so there were forces at work there too. (And now I’m getting a headache by thinking backwards through the layers upon layers of contexts that affect stuff.)
Point is: Great talk!
Phil McClure
on 22 Apr 10Great article. Thanks for sharing.
Thomas Maas
on 22 Apr 10Ryan, very nice talk.
Reminded me of my graduation project where in order to design a mobility product that should make sense 10 years into the future, we first distilled/imagined/designed the future context and it’s forces. We then designed new forms that made sense within this context.
Finally, to top it off we did some concept testing by first immersing respondents into our conceived future context and then letting them evaluate the product from within that context.
The project really made me sensible to see design as something that is derived from the context it exists in and has to be in perfect balance with it, in order to make sense.
Thanks again.
Henrique Carvalho Alves
on 22 Apr 10Great talk!
As someone without a formal education in design (I’m a software developer), I had a particular interest on Alexander’s work since I found some articles mentioning it in the past, specifically the “The Nature of Order” books. Now I’m even more interested in how the foundational ideas of the first books were applied on practical UI design.
Really summed up it my previous experience with systems analysis, leading to a more holistic view of problem solving and producing patterns.
Very well done! Keep posting stuff like that on SVN.
Scott
on 22 Apr 10Great job Ryan. You’d be a great college professor.
David Ham
on 22 Apr 10I found this very useful, and I also liked your essay about this, which put me on “Notes on the Synthesis of Form” for the first time. I liked the book but found it academic, and when I tried applying his system the first time it seemed a little unwieldy—e.g. group 1 consists of related forces A, B, F, I, Q, P, S, Y, Z, and Z1. Your way seems much more 37Signals-like.
Ryan, is your process at 37S any more structured than what you depict in your slides? Or do you just write down some forces (“I hate doing data entry”, “I forget to send notifications until after I’ve created the note”), take a few that seem related, and design to solve them?
Thanks for posting this, I got a lot out of it.
Randy Cox
on 22 Apr 10The comment about diving right in with lists of product requirements vs. taking the time to first explore the environmental constraints, limitations, and requirements about 18 minutes in is a fantastic, critical insight. Please keep this kind of thing coming.
Paul Groves
on 22 Apr 10Throughly enjoyed this refreshing look at approaching and defining design and design issues.
Are the slides available? Sort of want to print “Designing from scratch and evaluating to improve” (46:50) and stick on the wall :)
Serguei Panfilov
on 22 Apr 10Ryan, great talk. Thanks for sharing.
Alisey Lebedev
on 22 Apr 10Definitely interested in this material. Valuable and fresh (or timeless should I say) ideas. Thanks, Ryan.
JF
on 22 Apr 10Ryan, is your process at 37S any more structured than what you depict in your slides? Or do you just write down some forces (“I hate doing data entry”, “I forget to send notifications until after I’ve created the note”), take a few that seem related, and design to solve them?
It’s less structured. We don’t write this stuff down. We talk it out loud (or keep it in our heads) and then start designing it. It was written down for the slide for this presentation, but it’s not written down for the actual work.
RS
on 22 Apr 10Here’s a PDF of the slide you mentioned.
RS
on 22 Apr 10With navigation, it’s good to check why you are using a certain form. It’s easy to put tabs on the top of every layout, or a list of links in the sidebar, without thinking about it.
Tabs themselves are a pattern; you can look at each case to see if there is a system of underlying forces calling for that specific pattern. Sometimes you don’t need any navigation at all. I’d suggest starting with the problem (“I need to get from here to there and back”) and then weigh out the best ways to handle that. Then if you need tabs or a list of links or whatever else, you can find a way to put them above, beside, to the left of whatever existing design elements you have. That way the design is growing out from the inside.
Martial
on 23 Apr 10I’d love to know if people are interested in this material.
HELL Yeah!
DL
on 23 Apr 10Great talk! Like @HCA I’m a developer trying wrap my head around design too. I’d seen some stuff on form vs context before but didn’t quite get it in a real world way. You managed to articulate that concept very well and in a relatively short amount of time. Well done. Thanks to you I’m going to spend the rest of my day asking myself is that form or context.
Juanra Núñez
on 24 Apr 10Hi Ryan, thanks for sharing your presentation. It’ s really amazing how you design simple things that solve complex problems in real life. I was wondering how you made the sketches on your presentation, and I would really appreciate if you share this info too.
Thanks again,
Juanra
Joel Spiro
on 25 Apr 10Very interesting talk. You guys are doing a great job ushering in a new era of user interaction and more human software.
Aneesh Karve
on 25 Apr 10Pleasant and intellectually juicy talk, but a large part of “designing with forces” is just a re-branding of standard user-centric design. You state that, in Alexander’s view, requirements are not the right way to specify a product. Instead, we should look at the facts on the ground, the forces that condition the use of the product. But does it have to be that fancy? Take a look at the “forces” you provide. Many, if not all of the forces, are simply user goals. User goals are standard fare in user-centric design. Cooper process is one example.
Perhaps the real value in designing with forces is that it engenders a new perspective on old problems. New perspectives can lead to new insights. For instance, I note that many of your forces are negative goals. When developing personas, there is a natural tendency to focus on positive goals of the form “I want to do X.” Furthermore, the form/context perspective encourages us to look beyond the person to the environment and its constraints.
In conclusion, what’s missing from the talk is how “designing with forces” fits with the existing theory and practice of design. As a community, we benefit from knowing when new terms are wholly new, and when they are nuances of existing terms. Designing with forces is an interesting perspective. But let’s not drink so much Kool-Aid that we forget what we’re looking at: user goals and environmental constraints, both of which are well-established design factors.
What are your thoughts on how “designing with forces” relates to existing methods?
Craig Fratrik
on 25 Apr 10Can you link to that post about the iPad mentioned in the last comment?
RS
on 26 Apr 10They’re just sharpie marker on paper, scanned and black/white inverted.
@Aneesh,
Alexander’s book was first published in 1964, so it isn’t accurate to frame it as the new kool-aid in contrast to “existing terms.” Different systems exist in parallel, and you can choose whichever one speaks to you the most.
Aneesh Karve
on 27 Apr 10To be fair, there’s no Kool-Aid at this stage. The point is not to let any idea become Kool-Aid by neglecting to examine it and compare it to other ideas. In this respect, it makes no difference when Alexander’s ideas were introduced.
You’ve done a nice job of bringing Design with Forces ideas to a wider audience. The work will flourish through discussion, comparison, contrast, and integration with existing methods.
Just as there are different usability testing methods, suited to different circumstances, there are different design methods and perspectives. The community will benefit from an understanding of how they relate, when they are most effective, etc. I’m happy to collaborate in this regard. I understand that it can’t all be done in one talk :)
RS
on 27 Apr 10@Aneesh
Maybe you’d like to write a post comparing some key similarities and differences among the practices? It sounds like you may know more about the subject than I do. I’d be interested to see it. Shoot me an email if you do.
Tiago Sá
on 28 Apr 10Thank you Ryan. You just helped me to figure out why I’m not using Highrise yet - even though I tested and loved it’s design and concept - Ironically my main issue can be defined as design problem.
I see the origin of the problem on an important fact that was ignored on the context used to design the product: The fact that people from all over the world could use the software.
It turns out that the lack of a multilingual interface is a friction point that make the design weak by your own definition. At least it can be seen this way by me and certainly by thousands of other overseas users.
I can take from myself: I would love to use Highrise in my company, but I can’t. I do have a fair level of English. However I can not assume the same for all my collaborators. And I’m sure that they will either be calling me for support when they forget how to do something simple, or they will just be resilient in adopting the system and its features.
I’m sure that very soon you guys will realize how many opportunities are being left behind, especially among the B.R.I.C. where there are so many small business in need for this kind of software. I think you’ll be rewarded then… I’ll be watching.
BTW, thank you for the presentation, and the great software.
This discussion is closed.