While I might use some different language today, this technique I posted in 2004 (inspired by Alexander) is still a major help when I’m designing a UI with many elements to juggle. The reason I come back to it is that it helps me design with language first instead of empty templates. Too often a design starts top-down with empty content areas (maybe a main column and a sidebar) and then we fill those boxes in until its “done.” Filling in the boxes would work fine, except having a bunch of stuff on the page doesn’t mean we served the design goals.
Here’s a refresher:
- List all the things a screen should do. What should the customer be able to accomplish? What information are you sure should be displayed? Which affordances are necessary for customers to start a process or reach a goal? Label these things with numbers.
- Look for any numbered items that relate to each other, conceptually or spatially. Label these groups of numbers with a letter.
- Sketch a design (or multiple designs) for each number or letter group.
- Combine the individually sketched blocks into a unified design. Let the pieces fall together into a whole.
And don’t forget, the next step isn’t a polished wireframe. It’s code you can click on!
charly
on 19 Apr 09nice description, I was wondering how to make a site mockup per hand. this is just the answer.
EH
on 19 Apr 09Thanks for the nice article, I’m a big fan of sketch design and this breaks it down to an elemental level…but “affordances?” Really, there isn’t a thesaurus at 37S?
RS
on 19 Apr 09EH: “Affordance” has a specific technical meaning thanks to J.J. Gibson. I’m generally skeptical of academic work in relation to UI, but Gibson’s books on perceptual psychology are amazing and full of insight. Here’s a good definition:
The word got picked up in UI circles to refer to the specific parts of the screen that invite you to click on them, push them, drag them, etc.
While I’m on the tangent, J. J. Gibson is generally awesome and I highly recommend his Ecological Approach to Visual Perception as brain candy and a source of insight for interface designers.
Tim
on 19 Apr 09What about government usability work?
http://www.usability.gov/
Matthew Ford
on 19 Apr 09The term affordance lends itself nicely to UI/UX as users on the web have expectations based their experiences on other sites.
Mark
on 19 Apr 09@RS: “I’m generally skeptical of academic work…”
I will add that SVN has referred to the work of Edward Tufte (an academic) a number of times (your Google search function indicates 101 occasions). Remember, it’s not the label we choose to give something/someone that matters, but, in the end, the usefulness we can wring from it.
Alok jain
on 19 Apr 09Interesting, I wish we could look at more detailed example. In my thinking I do sketching but for most part it’s tied less to break up things to that detailed level and define spaces as the specific details would change over a period of time.
I think of it in a fashion like one was to go to a mall – there is an entrance, and inside there would be ways to move across floors and so on.. now entrance could be a sliding door, revolving door, no door altogether, automatic/manual etc.. similarly moving across floors could be escalator, stairs, elevators etc.. a well design mall would have well designed spaces to provide solutions to these consumer needs in a good fashion. Users/Customer/People would really remember at a more abstracted level and anytime they want to try something new they’ll go to a space before the specific action within that space.
If the design can start with that level of abstraction, it would be better aligned to user’s thought process. The next level solution requires going deeper and adding specific solutions within this space.
An example would be to say in word the main space is for content – that the killer feature. Then comes most commonly used functions – toolbar and then deeper functions which are menus. When the user comes to work on a document they are thinking of something like a paper where they can start putting their thoughts – so the main space of document takes prominence, then they need formatting and other such tools and they reach out to toolbar. So as designer we define these spaces first and then thinking about what specific elements go where. For instance header and footer are available within the main space in word while formatting functions are not.
Am curious to hear if you see this approach aligned with what you do or different.
RS
on 20 Apr 09@Mark You’re right. We’re big fans of Tufte, and also the Christopher Alexander book I linked to in the post is academic. It’s worth noting that Alexander and Gibson both represent unpopular views and they have both been rejected by the vast majority of practitioners in their respective fields. Douglas Hofstadter is another against-the-grain academic. He refused to even write papers and published books instead. These are the kinds of academics I’d be happy to be associated with!
@Alok I like your analogy. I’d push a little bit on what unit you use when you talk about a “space”. Is a space a screen? A content area on one screen? An input field?
Like consider a UI for managing deadlines and associated dependencies. The “content” there isn’t one contiguous thing as in your Word example. The content in this case would be more of like an object model, where a deadline is an instance of some class with different attributes that are settable via the UI. In a case like this, it’s harder to define what the “spaces” would be beyond some general ideas like “the screen for managing deadlines” or “the screen to see dependencies for a certain deadline” etc. Once we get into this territory, I find a lot of value in the object-oriented and resource-oriented understanding over the architectural analogy.
Dean
on 20 Apr 09Thanks for this!
I just finished the little black Alexander book myself, and I’ve been thinking a lot about how his methods have already been (roughly) applied on the web — much more often, of course, via the gang of four book, or The Design of Sites, than from Alexander himself.
Naturally, I understand that your older entry presents a method “inspired” by Alexander — and even Alexander gave up on some aspects of his early system — but it seems that his focus on design misfits, rather than design elements, is one of the most valuable parts of the book.
Having now had some more experience with what works and doesn’t work on the web, we can do a lot more good by also including the ways things can break: does this interface element introduce too much novelty or cognitive load; does this work for a user with accessibility problem X; can this element be reused easily, and does this layout support expansion in certain ways… things like that.
All this definitely introduces some extra thinking into the early phase — if only because it forces the designer to articulate things he or she might already be thinking about — but it also gets us closer to the real point of working with patterns: making a usable design come out of what the design community already knows works and doesn’t work instead of evaluating it after we’ve put the parts together.
Listing the elements, like your example shows, is absolutely necessary, but only seems to be the start if we really want to get some good out of Alexander. Otherwise it seems like too much work (or method) for not enough benefit — which, I think, is why so many developers feel iffy about the whole patterns business.
-Dean
Jimmy Chan
on 20 Apr 09Any good-recommended-software to do this?
Ali
on 20 Apr 09It’s very nice and simple UI designing. It’s give me a new idea to ordered working web design’s.Because I’m very sloppy!
Matt Lincoln Russell
on 20 Apr 09Nice timing; I just had a refresher look at that white paper 2 weeks ago while starting a new project.
JiPé
on 21 Apr 09@Jimmy, you may want to have a look at Balsamiq Mockups (http://www.balsamiq.com/), but in the end a pencil and paper or a black board and a stick (my preference) is all you need to begin sketching your next interface.
Jimmy Chan
on 21 Apr 09@JiPe,
Thanks. What a cool product..
Ari Rochmann
on 21 Apr 09Great post about designing a new UI. I will certainly keep this in mind as I delve deeper into this kind of work in my career.
Rich Apodaca
on 22 Apr 09Ryan, thanks for sharing this again – I hadn’t seen it when you first posted.
Quite true.
I tried your technique out on a project I’m working on and was delighted to find that it uncovered things that my initial top-down approach completely missed.
The way this technique forces you first to think about the user and their problems and the way the design emerges from that process in a bottom-up fashion remind me of test-driven development.
Does your technique have a name?
Roy
on 22 Apr 09“Does your technique have a name?”
Common sense.
iddaa
on 22 Apr 09Any good-recommended-software to do this?
Stu Collett
on 22 Apr 09Great little article. I agree that it’s still really important to use pen and paper as you’ve got a truly blank canvas, (instead of a predetermined shell).
Thanks Ryan.
Stu.
Alok jain
on 25 Apr 09@Ryan Here are my thoughts on managing deadlines.
The core value of this is for the user to be able to review the deadlines effectively so that take maximum importance. Second aspect of this is utility of adding/editing, deleting etc – this is required because of the limitations of the computers that they need users to enter and manage this info manually. The users have learn’t to do this but is a supporting task. Third component is portability of this info – alerts, printing, rss, pdf etc..In terms of spaces I see two spaces – First: view and manage deadlines and Second: portability. reason I merge view and manage into a single space as manage (edit/delete) etc is a means to an end (view). In other words user’s mind is thinking about final output so the process of creation/editing should be integrated with that. Possibly similar to the to-do creation model
Now within this space we can think of how users would want to review deadlines – past due, current, upcoming – so time plays an important role – might be the precise date is important , might be the distance from now plays important role. In case of time machine interface in OSX they have a timeline on the right side which focussed on distance as primary model and has the lines spaced out based on that. (not elaborating as I know 37S team uses OSX), current basecamp proj management uses a specific date model. It could also truly be a user “preference” and in that case both models could be provided for user to choose from/switch between.
Coming to visual design from here, I would try to keep 70-80% space for view/manage deadlines and rest for exports and some header nav elements etc.
This discussion is closed.