Tue

Apr 26
2005

Tim O'Reilly

Tim O'Reilly

Designing from the outside in

I was talking with Jason Fried of web design firm 37Signals recently. He believes that contrary to the normal expectation that applications are built on top of frameworks, applications should always be designed "from the outside in." That is, at 37signals, they try to design the usability and function of the application first, and that drives the implementation. And if they can then extract a re-usable framework, all the better. For example, basecamp wasn't built on top of Ruby on Rails. Rather, Ruby on Rails was extracted from basecamp. This approach seems obvious and commonsense -- but hardly common in this era of heavy web services standards-ware designed by technical committees far in advance of actual implementation.

Jason related this approach to the oft-cited design pattern for landscape architecture, codified by Christopher Alexander in A Pattern Language as pattern 120, Paths and Goals: ""To lay out paths, first place goals at natural points of interest. Then connect the goals to one another to form the paths." The best way to lay out paths is to put in lawn and then see where people actually walk, and add paving only later. (Larry Wall also cites this pattern as a key driver in the design of Perl, which, like the Camel he requested as its O'Reilly animal, is thought ugly by many but is nonetheless curiously well adapted to its environment.)

But this conversation also set off another train of thought: isn't it curious how many of the applications and ideas getting the most buzz right now are coming from fertile collaborations between designers and developers? In addition to basecamp, there's Flickr, conceived by designers Stewart Butterfield and Caterina Fake. And who put their finger on AJAX, the meme of the moment, but web design firm Adaptive Path.

Are designers the new heroes of the computer industry?


tags:   | comments: 19   | Sphere It
submit:

 
Previous  |  Next

0 TrackBacks

TrackBack URL for this entry: http://blogs.oreilly.com/cgi-bin/mt/mt-t.cgi/4006

Comments: 19

  julian [04.26.05 06:59 PM]

Pretty much everyone who's trained in Design, HCI, and/or Usability is taught that outside -> in is just The Way Things Should Be.

Designing from the outside -> in is not a new philosophy at all, especially when you take the architecture analogies relating building software to building, well, buildings, a little bit further.

It's just been unfortunate that most of the software industry has been driven by inside -> out construction, when the best construction happens from the outside -> in.

I certainly believe that as more and more technical problems are finally solved to a reasonable degree, Designers will save us from ourselves by helping us to create software that's beautiful, usable, and technically advanced.

Google stumbled upon beautiful/simple Design by accident and has fully embraced it to great success. I expect others will take their lead.

  John Zeratsky [04.26.05 07:06 PM]

Hey, you stole my headline!

But seriously, designers are driving innovation because they are creating user experiences. And experience is what people care about. I think technologies like Ajax and Rails are growing out of designers' demands for better experience.

Good thinking...

  Adam Michela [04.26.05 07:49 PM]

Great post Tim.

"Are designers the new heroes of the computer industry?"

I think so. That's why I said It's designers that are making Ajax hot.

  Justin Mason [04.26.05 11:48 PM]

'Isn't it curious how many of the applications and ideas getting the most buzz right now are coming from fertile collaborations between designers and developers?'

Playing devils advocate for a minute -- Flickr (Ludicorp) and AJAX (Adaptive Path) both had some well-connected bloggers behind them; perhaps that helps generate a bit of buzz, too. ;)

  Brent Ashley [04.27.05 12:52 AM]

Three identifiable layers of successful software are engine, user interface, and marketing.

As a scripter who provides plumbing and glue to designers, I often find that the things I build are all whiz and no bang until there's a well-designed face on them. Even then, any product or idea is going nowhere without someone sufficiently well connected to raise its profile.

It's a rare person who can succeed at all three parts alone. Ludicorp's team, for instance, runs the entire spectrum with 8 people. Adaptive Path's team appears more heavily weighted towards providing design and marketing services to those who build engines. In my consulting and contracting, I provide engine and glue to organizations that already have the other two layers.

Much of the time, while it may look from a high level that a product was designed inside-out or outside-in, it may be that the end-to-end process brought together a number of partially formed parts that got stitched together symbiotically to make a whole larger than the sum of the parts.

  Carl [04.27.05 06:31 AM]

37signals (the folks behind Basecamp, Tada, and the upcoming Backpack) is a 5 person shop. And, as I learned when I recently attended the Building of Basecamp workshop, their product team is 3-4 people. They don't even use all 5. They're all about embracing constraints, looking for what sounds like a negative and making it a positive. They build simple because there's no choice, and starting from the interface is the best way to do that.

  Tom Hoffman [04.27.05 08:21 AM]

I think the question of how Rails separated itself from other grassroots frameworks implemented in scripting languages is more interesting than the question of how it is different than top-heavy standards-ware. There are dozens of frameworks written in Python, Perl, PHP, Smalltalk, etc., floating around the web, a few of which are comparable to Rails in quality, most of which were probably extracted from or created for a specific application. What set Rails apart from them?

  Douglas [04.27.05 12:48 PM]

> What set Rails apart from them?

Ruby.

Someone might be able to pull it off in Python, but I've just not seen another langauge which can match Ruby for its expressiveness.

Douglas

  Ugo Cei [04.27.05 10:51 PM]

I commented on this post on my weblog and tried to do a trackback, but it didn't work.

Anyway, I think there's something to be said for using a well-known framework even if it can be sub-optimal at times: "I guess this approach fits better the “from the outside in” moniker, after all. We start from the outside (function and framework) and move towards the center (implementation), whereas I would say that starting from the functionality and deriving a framework from it can be better described as “top-down” design."

  Mark Andrews [04.28.05 09:40 AM]

While I can see the point he was trying to make, it's not quite as simple as that. When we are talking about a user interface as the outside, it is worth bearing in mind that it could also be called an API. Or more appropriately an AUI, application user interface.

But either way it is a method to get two different parts of the system to talk to each other, in this case the user and the application.

Although I often break this "rule" myself, designing all A?Is first, whether they be low level APIs (and thus ideal for a framework) or high level as an AUI, is a better approach then inside out or vice versa.

It helps the programmer to develop modular software with a good user interface and the ability to utilise existing framework, or build new framework parts as appropriate.

To use the building analogy, it lets us know exactly what bricks we have so we can mix the right mortar to hold them together.

  Chris Smith [04.28.05 10:13 AM]

I remember as a child asking one of those annoying shut-up-kid questions about rock 'n' roll: do they write the lyrics first, or the music?
The answer is yes.

  Paddy [04.28.05 01:24 PM]

So functionality is on the outside now?!
Used to be, that when speaking of form and function, Function was on the inside. (Us 'nix guys where heavy on the function).
I still think that you should:
1) Make it right
2) Make it usable
30 Make it re-usable
- In that order, and possibly becoming less strict as you move down the list.
- Pad.

  daily [04.28.05 04:35 PM]

Thanks!!!

  Christopher Fowler [04.29.05 07:57 AM]

Of course the designers are the heroes. They make it (what ever IT is) usable. Intelligence does not create a great UI, creativity does. The (web development) industry is heavy on functionality, framework, and architecture right now. It's now time for the design "heroes" to make use of all this crap by wrapping it and bundling and documenting it so that people can use it to its full potential.

When designers start to become less innovative, or start stressing the architecture - the engineers will have to start solving problems, and you'll see a shift again towards new languages, new frameworks, new APIs, and new protocols.

When you look at software development as a whole (as in the whole industry), no matter which design theory you subscribe to (inside-out, outside-in, top-down, bottom-up, waterfall, spiral,...) it's iterative.

-CF

  Kyle Cooney [04.30.05 08:56 PM]

I've been thinking about this a bit lately. In as far as designers are the new heroes of the computer(I'd personally point to the web) industry, it's mostly due to the hard work of a lot of I/T folks.




In my opinion, we've finally reached a certain point of maturity in web development, where things just make a lot more sense than they did in the past. I'm specifically pointing to the use of CSS/XHTML/XML and MVC frameworks such as Struts and Rails coupled with strong OOP concepts.




All of these implementations/concepts allow for less time(read: money) on technical implementations and allow firms to spend more time on crafting a better user experience. Of course, I'm not stating anything new, all this was predicted and been available for quite some time, but I think it's just starting to get into the hands of people who can use it in a creative manner.

  James [05.02.05 12:29 PM]

I believe this methodology is already being well used by dynamic language programmers who value simplicity over large often monolothic frameworks. Most of the frameworks for dynamic languages are thin and don't take over the whole application design. They are often loosely coupled so that they may be added and dropped freely. I think it is a well observed fact that dynamic language development is way faster than classical approaches and easier to maintain.

  Anonymous [09.20.06 06:31 AM]

Yeah, I'm confused about using the phrase 'designing from the outside in' to describe this philosophy. If you are talking about 'first design the interface, then get to the code', then I understand it. Thinking of the interface as 'outside' the code makes sense.

But here you're talking about first design a specific application (or several), then design the general purpose framework to support it/them. It confuses me. How is an instance application 'outside' a general purpose framework which is 'inside'? To me, the framework is the outside (isn't that part of the thing about a framework vs. a library? A library is used by your application, so is kind of something that is used 'inside' your application. But a framework---what makes a framework is that your application is _used_ by _it_, your application is enveloped by the framework! Right?)

So I dunno, I think I get your point. But I'm wondering about this "Design from the outside in" phrase and it's applicability to what we're talking about here. Sometimes I get frustrated by these 'memes' that people just use to mean whatever they want, pretending there's something in common to all the uses---when if there is something in common, it in fact hasn't been discovered yet. The discovering of what's in common is the trick to abstraction, of course. Just using a hip phrase can be a shortcut which avoids the actual trick.

  uxdesign.com [11.28.07 11:54 AM]

In sum: Yes. :-)



But then when shouldn't design be the point of focus when consumer success is desired? On the other hand, when did technology-centered product development define the success of a car, home, soda bottle, desk... anything? When we are learning a new technology, only, is when. Web '1.0' certainly made that point, no?



So should it surprise that user-centric design and a more matured process should drive 'web 2.0' (a term that can't die too soon) success? Or as one former employer put it, "the better part of design is empathy." And this doesn't require usability testing, and resulting documentation, unless you work in a non-empathetic organization, so that a lot of left brain work is required to convince the left-brainers (a.k.a. engineers) that "serving users is a good idea."



But what remains hard for the general business community to do: empathize with others ('users'). More so for over inflated ego's accustomed to top-down management.



I've said for many years now that there is a kind of organizational conflict between commercial enterprises structured as pyramids, CEO tipped, and webs, which are mass-top, and democratic in nature. We're just seeing the results of this play out, I'd say.



Basically, context is king. For webs--for content and, or, function delivery--that means:

1) User goals, limitations

2) Business objectives

3) Scope/time/budget/tech limitations

Well known and understood users should always be at the fulcrum. If these tip out of balance your project will roll off of one end or the other, instead of staying on top, at user-center.

Post A Comment:

 (please be patient, comments may take awhile to post)






Type the characters you see in the picture above.

RECENT COMMENTS