Consider this a great, lost interview about a very specific arcane piece of IA lore. ;-) The questioner is Dan Brown. The answerer is Bryce Glass. This was intended for submission to Boxes and Arrows, but… um, life, work, books and babies somehow intervened. This interview took place in or around 2007. Shared here to scratch an itch for Livia Labate.

Two years ago, Bryce Glass uploaded a series of images to Flickr that are, in a sense, meta-images. They attempt to describe Flickr using a technique variously called "concept mapping" or "concept modeling". The idea behind a concept model is simple: show the relationships between different concepts. The nodes in the model are usually nouns and the lines connecting them are verbs. It was originally developed by Joseph Novak at Cornell as a tool for science teachers, and likely a variation of "mind-mapping."

A year ago, Bryce agreed to let me use his Flickr concept model in my book on documentation, Communicating Design. Of all the deliverables described in the book, the concept model is by far the one that generates the most questions. To get some answers, I turned to Bryce to help explain how he created the concept model for Flickr and how it might apply to real-world web design.

Take us back to the beginning. What inspired the Flickr concept model? What prompted you to do it in the first place?

There were a couple of different factors that put me in the right frame of mind to do it, and one specific conversation that finally prompted me to action.

I'd been doing some modeling for work (at the time, I was a UI Designer for Sun Microsystems.) Working with a cross-discipline team -- UI folks, developers, technical writers and product architects -- on modeling a shared user-model ("shared" across a suite of integrated products) and it had been a rewarding collaborative process. It resulted in a series of diagrams that I was rather happy with.

I was really having fun with the design aspects of the models: communicating concepts and hierarchies of importance by varying type-sizes and line-weights; playing around with graphical representations to really 'sell' key concepts. (You touch on all these methods in your chapter on concept modeling in Communicating Design.) Based on response from the team, and our subsequent success in getting organizational acceptance for some of the ideas we were trying to sell, I think others thought that the models worked well, too.

Unfortunately, I couldn't share any of this work with my community of peers outside Sun. These particular products aren't slated to ship for several more months, so I couldn't exactly publish these formative design documents. I did share a couple of them with friends on Flickr, after 'randomizing' the concepts, creating absurd versions. (See Gobbledy-Gook 1 and 2) But I was really wanted to design a model that I could share, with content and presentation working in concert to really "sell" a set of ideas.

It was a conversation with my friend Lance Nishihira that finally gave me my subject matter. Lance is an Interaction Designer for Yahoo, and we were chatting on IM about their (couple-months-old, at that time) acquisition of Flickr. Lance is, and always has been a big Flickr fan, and our conversation ranged from tagging to 'Interestingness' to Flickr's social aspects.

That brief chat with Lance got me thinking, and made me realize that I really didn't know exactly what my attraction to Flickr was. How did it all 'fit' together? How do the community aspects enhance the photo experience, and where do tags fit into that relationship? Answering these questions for my own gratification sounded like the perfect excuse for a concept diagram! And a really fun one, at that, about an application that many people know and love. So I jumped on it.

Describe your process for developing the Flickr concept model. Did you start with pencil sketches? How many versions did you do prior to posting it publicly?

The process for this diagram was somewhat uninteresting, I'm afraid. I started right in Illustrator, no sketches and not a whole lot of thought upfront about what final format I wanted it to take.

As I recall, the very first version that I posted to Flickr was on a Monday night, and I'd mostly worked on it the day before. Most of Sunday evening. So the three posted versions really do represent the evolution of the diagram, from start to finish. I started with the central concept.. 'A Flicker User takes Photos of a Subject.' and then all of the smaller associations kind of hung off of that relationship...

I had a small library of people-figures to begin with (and had some fun developing new ones along the way. See the purely-gratuitous guy playing a double-neck Stratocaster that I added to version 3.) And I had a small library of arrow-type shapes from past diagrams I'd done. But mostly it's draw-and-tweak Illustrator lines, done by hand and moved around a lot to get the composition and readability that I wanted.

You mention the "central concept", which is the piece of the model that forms the backbone of the diagram. During the Web 2.0 panel at the IA Summit, someone referred to this sentence -- "A Flickr User takes Photos of a Subject" -- as Flickr's value proposition, which I thought was a nice way of putting it. How did you come up with this sentence, and did you always see it as the backbone for the diagram? Do your other concept models use a similar format?

[I'd really like to beg out of this question, Dan. I just spent 30 minutes on it, and came up with nothing very satisfying. ;-) ]

 What kind of research did you do to prepare the concept model?

Very little. Mostly, I kept Flickr open in the browser as I worked. Because this was such a self-motivated project, I really didn't have the opportunity to solicit too much feedback from others. (Although, once I had published something worth sharing, I did get comments and notes from the Flickr community that were very helpful in shaping next iterations.)

Probably the most time-demanding "research" element to the model was spending time surveying tags, and the ways in which they're actually used by real Flickr users. While I didn't want an exhaustive survey of all the ways that people use tags, I did want to make sure that my simple model (context-vs-content) holds up under scrutiny and I wanted to find good examples to illustrate different facets of context (Geography, Circumstances, etc) and content (People, Places, Actions.)

I started this research by monitoring new uploads to Flickr, and then quickly learned that.. (duh!) people don't seem to tag new photos as they're uploaded. (Of course, there are exceptions -- during batch uploads, you see a lot of generic-descriptor type tags -- 'beach' or 'cameraphone'.) Much better to monitor the Popular Tags page, in particular the call-outs for Hot Tags of the day, or the week, to get a decent survey of how the Flickr community is using tags. (The all-time most popular tags don't change often enough to give a really rounded impression of some of the edge-cases of tagging. They tend toward the old classics like 'moblog', 'wedding' or 'San Francisco.')

What do you think are the three most valuable things you learned from composing the Flickr concept model?

I suppose the first interesting thing that I learned is.. exactly what I'd hoped I'd learn from the diagram. How I feel about 'tags' as an interactive and informational device. How do they relate to the objects that they modify (photos) and the people that employ them? It's really a simple diagram, but it has helped me immensely as I consider tags and their applicability to different design problems in different applications. Concept modeling is, for me, a wonderful tool for thinking through an issue. I almost don't know what I think about an issue until I see how to think about it. Obviously, this one diagram doesn't entirely answer the question of 'What is Flickr?' or 'What can I do there?', but it's a pretty good conversation-starter for those things.

The second thing I learned, based on the feedback I've received and the interest that folks have expressed, is this: people will always appreciate clarification and, where possible, simplification. I might look at the Flickr User Model diagram, and think.. well, duh. Of course Flickr works like that. What does this thing really represent that isn't already evident from a visit to the site? But several people I've talked to specifically cite the simplicity of the diagram, and it's approachability, as a major reason for its appeal to them. So I think I've learned that it's okay to treat things with an element of fun. Even if it comes at the expense of 'intellectual rigor' or even if it means producing a less-ambitious but more-satisfying end result.

An interesting footnote to this observation? Several people have strongly expressed their preference for the very first, and simplest, version of the model that I published. Even though there's not as much information in there ("What? No Comments?! No Blogosphere, and no Public and Private Photos?" The complete-ist in me shudders!) there's certainly a clarity and conciseness that the subsequent versions lack. For what it's worth, I like the final version, although I think the design could be cleaned up some. I've mentally sketched out some ideas on how to do that, but sorely lack the time and interest to give it another go..

The third thing I learned, is something about the value of "pushbutton promotion." The Flickr User Model diagram is probably the thing that has opened more doors, created more new professional and personal associations (It's how we met, Dan!) and given me more of an ego-boost than anything else I've worked on in the past several months. And what did it take, in terms of real commitment, from me? I spent a couple nights doing a fun illustration, I published it to Flickr, and I really did almost nothing to call attention to it.

But through the beauty of tags and the discovery mechanisms baked into Flickr, a small number of like-minded folks have found the diagram and responded very warmly to it. I got some contract work out of it, it's appearing in a book. It's even spawned imitators! How cool is that? So this is definitely a model I will try to share in the future, and I'd encourage anyone else to try the same: do something out of personal motivation (be it intellectual curiosity, a desire to have fun, or whatever) and share it with your peers, in a public fashion. Only good things can come of it.

Describe your "set-up". What kind of hardware & software do you use?

Well, my setup has changed a bit since I did that diagram, but these days I use a work-issue MacBook Pro (the 15" one) with a reasonable amount (2GB) of RAM, but not maxed out. It drives a 24" Dell external display and I use a Wacom tablet quite a bit. (The Intuous 3. Strangely, I 'drive' it with the included mouse much more than the pen. So I suppose I could get away with a plain ol' mouse.)

As for software, this was entirely done in Illustrator CS, which I use for all my design documentation, from modeling to wireframes to sitemaps. I've gotten a lot of inquiries about software for this diagram (both in comments on the diagrams, and personal Flickr-mails.) But there's no super-seekrit cool-kids concept modeling package that I'm trying to keep from people! It's just Illustrator and my meager illustration abilities.

Oh, and my office-dog Polly is a constant companion at my feet.

Geeks love that kind of stuff. In our next interview, we'll talk guitars. Back to concept models... At what moment did you feel like the diagram came together? At what point could you step back and think that you'd created something interesting?

Because my motivations for doing it in the first place were so intrinsic, I guess I was pretty pleased just to sit back and look at it when it was done. I knew right away that I had done something that appealed to me. It was apparent within a couple of weeks that it also appealed to other folks as well. More people have 'Favorited' the diagram on Flickr than any of my photos (by orders of magnitude.) I got some favorable messages from folks, and continue to get them to this day.

It's funny, there have been 'waves of awareness' that wash up from time to time. The diagram went through a phase where it was being posted to a lot of User Experience websites, and that caused a spike in views. A couple weeks later, it was Digg'd (Dugg?) Just a really small number of Diggs, but enough to open it up to a different audience. Of course, after the IA Summit last Spring, there was a spike in attention payed to it. So I think this is when I really realized that the model spoke to people -- when they all spoke back! With page views, comments, messages to me, and the like.

How have you used concept models in your "real work?" Do you create several during a project? At what points during a project do you find concept models the most useful?

Well, this example, the Flickr User Model, is a little bit misleading on several counts.. Maybe 'misleading' is the wrong term here, but the way this diagram was designed, the audience it was intended for, and the ends to which is was directed are all very mis-representational of the normal circumstances that I might employ a concept model under.

First and foremost, this diagram documents an existing application. I would typically employ a concept diagram in an early phase for a new system or application. Around the time that a product team (or pitch team, or management) is asking "what could this thing be?" I find that doing some draft modeling, accompanied by quick conversations and revisions, help to get a team past the 'boil the ocean' thinking, and really start to question their values and focus on just the pieces that matter.

Of course, it's also for an application that I had no part in designing or working on -- so it's very much a post-facto illustration intended to explain the qualities of Flickr's user experience. In my experience, it's pretty rare to get a chance to go back and document a successful design, so this is somewhat atypical in that sense, too.

Another way that this diagram is outside the norm, for me, is that it represents a fairly concrete and bounded 'problem space.' An application and all its constituent elements. Often, I will employ concept modeling when the problem comes to me in a much.. fuzzier form. For instance.. "We want to build a commerce platform to sell stuff." That 'simple' business directive comes loaded with so many assumptions, and leads to so many questions, that it really does beg to be modeled. A quick series of conversations that tease out relationships, beg more questions, and results in something concrete. Something that all involved parties can look at and say 'Yes, this is what we mean.'

And finally, this diagram was designed and produced in isolation. Just me and a mouse. Which I don't recommend at all if your intent is to use concept models as a regular part of your design process. (In this context, I think it worked okay because, as stated above, Flickr already exists and the point of the diagram is just to explore that 'Flicka-flava.') But I would normally solicit a lot of information from collaborators -- engineers with some specific domain knowledge, or our business analyst, or the potential users of a system -- before calling a model 'good'.

These models work best, in my opinion, when they attempt to reflect the outcome of a conversation or an agreement. They're constructivist documents ("this is what we think of the world") not objectivist ones ("this is the way the world works.")

My new book Communicating Design has a whole chapter on concept modeling, but I'm sure you've got some tips for people who are creating these diagrams for the first time. What would you suggest to people who are working on concept models?

First and foremost, I would discourage anyone from doing what I did with this diagram: don't go it alone. Sure, you have to have a starting point, so draft something quick (pencil and sketchpad) but it won't really start to take on any weight until you show it to someone. Someone critical, and opinionated about the domain that you're trying to model.

The best pieces of advice that you'll hear during this process will all begin with "No, no, no. This is all wrong." So remember, you're modeling this problem because it is an abstract problem, to some degree. It's hard and it should be no blow to your ego to admit that your hastily-sketched-out understanding of the problem is wrong. In fact, that's why you've committed this model to paper or screen. To show your ignorance (at least in the first draft.)

Of course, subsequent versions of the model should get progressively 'smarter' and closer to the group's shared comprehension of the problem. (If you find that your versions aren't getting smarter, this could be a red flag. Perhaps this problem has no clear definition. Or perhaps the team that's assembled to tackle it doesn't have the right skill set or perspective. Perhaps you're the problem and you need to work harder to understand the space.)

And I would also say that your models should be way less elaborately designed than the Flickr User Model diagram. Note that I did that as a labor of love, on my own time. The whole point, for me, was to have fun with the design - something I rarely get to do. Most of my useful and everyday models may be less engaging to the eye, but they're much quicker to produce. Always keep in mind that the model is a means, not an end.

Get Real, 37signals' book on web design methods, says that "abstract documentation" is a waste of time. How would you respond to this claim? What good does concept modeling offer?

Did they really say that? In those words? I haven't read the book yet, but I do read their blog daily and I agree with some of that sentiment -- I'm no fan of producing artifacts with no audience, or artifacts that don't solve a problem. But for abstract problems sometimes the best solution is an abstract answer.

If you're already at the stage in defining a product where you can answer (heck, even ask) questions like 'Can a user edit someone else's comments?' or 'Are there any limits to how many photos you can put in an album?' then you're already at a pretty concrete stage of the design process. Conceptually, everyone's already bought into what this thing is going to be, what the managed objects are and what their rough relationships are.

So, sure - go ahead and start building the screens. Skip the wireframes, go straight to HTML. Get Real. As long as -- when it comes times to share them with your client -- you don't hear 'Photos?! This application is for sharing Music!". That would be bad. Early-stage concept-modeling can certainly avoid that level of miscommunication, as well as a host of lesser stumbling-points.

In my time as a working UI designer, problems ('assignments', 'projects' or 'simple requests') have come to me in all different states of.. formedness, if that's a word. Sometimes that simple request turns out to be the tiny tip of a huge looming iceberg. And sometimes it's the other way around -- a client may think that her problem is an insurmountable one when in reality, you've seen this problem before, or one like it. And you already have a fairly cogent and explainable model in mind for how you'll help solve the problem. Why not write that down, discuss it, correct it once or twice and then set it aside (or print it and hang it on the wall?) I see undeniable value in any tool that can quickly get your client's expectations closer to your own.

The Signals, of course, are their own clients. So I suspect that they do hit on many of these same points in their own design process: they just greatly 'shorthand' them. It's a lot easier to build consensus with yourself. So, for them, a conversation in Campfire, or a lunch together to discuss strategy probably fulfills much the same purpose. Some people might look at a practice like concept-modeling and deride it as 'cover your ass' documentation or busywork. (And in the wrong circumstances, maybe they'd be right.) I prefer to look at it as 'discover your ass' work. For some projects, it's the thing that helps me get my head straight, and start thinking about the design in the right way, before any 'Real' work has been done.

What's next? Are you working on any other concept models either inside of work or as personal projects? Are you taking suggestions?

Since the Flickr diagram, I've taken a job at Yahoo! working as an Interaction Designer in the Community Platforms group, and we've had some opportunity to model our technology platforms. Usually for purposes of getting management buy-in for this-or-that appeal: invest in this technology, here's what it does. That kinda thing. Another very common case it customer education: we build platforms that other teams build products on top of. A good concise, clear diagram can often 'sell' a team on using one of our platforms (rather than striking out to build it themselves.)

Unfortunately, I don't have anything I can share from these efforts. But I hope to clear some stuff in the coming months related to reputation systems (one of our platforms, obviously.) I have a great idea in mind—it's really less of a concepts-linked-to-form-propositions classic 'concept map.' It's more of a procedural step-by-step diagram: Design your Reputation System in 12 easy steps. But illustrated, footnoted.. fun, hopefully.

I should mention that another designer on my team, Matt Leacock, is a great concept modeler from way back. Check out his Understanding Internet Search from (the far-flung past of) 1999! Matt and I worked together at Netscape under Hugh Dubberly who is, of course, a leading light in concept mapping and a great influence on my desire to capture and externalize knowledge as part of the design process. (Hugh's got some great concept maps available on his site, too.)

For my last question, I want to solicit a little bit of help. In February, I'll be giving a talk at Interaction08 on using concept models as a planning tool for interaction design. What's the one can't-miss point I should make?

Hmm... that's a tough one. I guess I'd say... "Modeler—Know thyself." That is.. approach any concept model with a good understanding of what you hope to get out of the model. What problems do you hope to solve by exploring these relationships and mapping them out for others to read? What itch are you trying to scratch? As with any tool, once you learn it, the temptation is to use it, but I'd advocate against making concept-modeling a routine or rote part of your design process. Cause—let's face it—many times the problem-spaces that we inhabit aren't necessarily that new or novel.

But when you're faced with a design task that's wonderfully involved.. with a rich set of objects and actions and an array of possible inter-relationships between them.. ? Ah, then a good modeling exercise can really help you get your head straight. And when done as a group exercise it's all the better.