is a blog about design, technology and culture written by Khoi Vinh, and has been more or less continuously published since December 2000 in New York City. Khoi is currently Principal Designer at Adobe. Previously, Khoi was co-founder and CEO of Mixel (acquired in 2013), Design Director of The New York Times Online, and co-founder of the design studio Behavior, LLC. He is the author of “How They Got There: Interviews with Digital Designers About Their Careers”and “Ordering Disorder: Grid Principles for Web Design,” and was named one of Fast Company’s “fifty most influential designers in America.” Khoi lives in Crown Heights, Brooklyn with his wife and three children.
Jason Fried made some waves at this year’s South by Southwest Interactive conference with a talk he gave entitled “How to Make Big Things Happen with Small Teams.” It’s a little uncomfortable for me to talk about a competitor in a weblog post, even (or especially) one I respect as much as Fried, a principal at the justly lauded 37signals — but he raised some excellent and also controversial points that bear further discussion. Equal parts advertisement for his company’s hit Basecamp product and a proposal for a new way to look at Web development, his presentation might be grossly summed up thusly: set aside almost all of the time-consuming, preparatory measures of user-centered design and start designing the final customer experience — the interface — as soon as possible. You might call it something like “iterative design.” Fried published some initial thoughts on this approach in this weblog post, and if/when I can find a copy of his slide deck, I’ll link to it here.
Products v. Services
In my first quick report from South by Southwest, I very briefly made some reactionary remarks on this talk. Mostly, my complaints were about the mixed message that some of Fried’s talking points sent, how he somewhat freely alternated between, on the one hand, a design methodology for teams focused on building a product and, on the other hand, a process for teams providing consultative design services to clients. For the former, I had no issue with what he described, but for the latter, I found it an unrealistic proposal.
That distinction between a product team and a services team makes all the difference, in my view. In many instances, process is key to overcoming the obstacles of an intransigent corporate culture when a design studio is faced with helping a large client create a Web product with enterprise-wide ramifications.
All Politics
Take feature specifications, for instance, those exhaustive and admittedly abstract documents that define what will be built for a site. Fried suggests that teams might forgo those altogether, dismissing them as “political.” He’s absolutely right to label them so, but that doesn’t necessarily render them inherently obstructionist. For any designer working in an enterprise environment, politics is a huge portion of the challenge for which clients engage us. The ability to navigate between multiple operating constituencies, and to achieve buy-in across groups often accustomed to working at odds with one another, is a crucial part of seeing a successful design realized. Given two equally capable design studios, I can guarantee that the one that has the greater capacity to balance a client’s internal politics will win the day in any design effort.
To be fair, I would doubt that Fried would advocate this approach for every instance — in a very brief discussion with him about the issue, he said clearly that different approaches apply for different circumstances. As another tool in the belt of Web developers, it’s a viable alternative to the comparatively monolithic approach of user-centered design. The line between gospel and dogma is as thin and impermanent as chalk, and it’s reasonable to say that the trappings of user-centered design methodology — extensive research, personae, user scenarios, branding exercises, mood boards, etc. — have attained some dogmatic qualities over the course of the past several years.
Designers Start Designing
In fact, I must admit that I was being a curmudgeon when I was listening to Fried’s talk, stubbornly resisting my first, jarring exposure to a new methodology. I do that from time to time, especially when I have as much invested in a way of doing things as I have in user-centered design. It helped me open up a bit when the ideas that Fried discussed were echoed by several other speakers I heard at the conference — it was, you could say, definitely one of the show’s stronger memes.
What really converted me, though, was the realization that there was at least one thing about this approach that I like a lot. That is, this is a method that returns designers to that core notion of visceral creativity. For many of us — for me — what got me really excited about working in this medium was that I could have an idea and execute it immediately, that I could translate my ideas into code and experience it in very little time, without first clearing a series of procedural obstacles. As designers, what we should really be busying ourselves with at the earliest possible juncture is designing. The shorter the time span between conceiving the initial idea for a solution and the execution of that solution, the less risk of smothering creativity.
Of course, there’s a caveat to this: to get to a position where a designer can begin almost immediate work on the final design — and to be successful at it — it helps to have deep experience doing things the long way. It takes someone who has been through the process of political deliverables, who has watched the pain of user testing, and who has accumulated a history of design successes and failures to be able to make instinctive decisions in short order — someone like Fried, not coincidentally. In a sense, iterative design is strongly predicated on user-centered design. You need to walk before you can run.
I think you are right when you say this approach works better for product development than client work, but in my experience, the distinction is not even as clear as that. With client work, I can jump into designing interface prototypes a lot sooner when I am building a web application than a public-facing site.
For whatever reason, clients don’t like to see a site with obviously incomplete content or a rough design, but they don’t mind seeing an application with a bare bones interface and only half the features intended for the final release. Why is this? I am not sure. Do you have any thoughts?
Andrew
Keep in mind also that in this rare case, they were truly building the product for themselves first. That’s obviously not often the case with client-driven work. The fact that they did no user research, market analysis, or strategic planning makes Basecamp quite an anomaly. It will be interesting to see if thier next project “Honey” is also something they themselves needed, or if it’s more of a market-driven product.
John’s point above is crucial: this method seems to work *only* for application development, clearly it would be terrible for advertising or other more “graphic design” sorts of jobs.
Andrew said:
“Keep in mind also that in this rare case, they were truly building the product for themselves first. That’s obviously not often the case with client-driven work. The fact that they did no user research, market analysis, or strategic planning makes Basecamp quite an anomaly. ”
– I think that if they were really building it for themselves, then they had probably done *years* of user research and market analysis, leading to them solving their own problem.
Exactly. You can’t ever skip learning about users. They were the client and had done the ‘research’ in that sense. And since they were building a product for themselves, there’s no need to produce documentation, that at it’s core, is to communicate an idea. They simply create the idea as a prototype and talk about it.
What you want to do is get the method most close to real that can communicate your idea. For some larger teams I think they choose to accomplish this with functional specs, and are stuck in that rut. For smaller teams, or teams not stuck in that rut, going straight to a prototype *is* the cheapest and quickest way to communicate the idea.
I think to sum up the concept for me, interface *is* the way to determine the product. Not functional specs or other highly abstract documents. If you can show/communicate the user’s interface then anyone can understand and agree what it’s going to do. This is a lot more efficient at developing a realistic product and meeting date and budget constraints.
I think the politics are in what clients are *used* to doing or are expecting. If you can manage the politics of the client, and turn their expectations towards focusing on interface, then you certainly can put this into practice on a day-to-day basis.
Like you said, a lot of clients have gotten used to doing things the wrong way. But if you can find good clients, _or_ educate your clients to appreciate this method, the benefits are great for everyone involved.
I am working with a great client right now that is very involved and open as we develop a content management system for them. We started by creating a minimal useful system (interface first), showing them that prototype, then adding features one or two at a time and sharing with them. At each stage, they have good ideas for us — some big, which we keep track of, and some small, which we can implement almost immediately.
A nice side-effect (or maybe it’s a central effect) of working this way is that you are truly engaged in a dialog with your client. Clients like to be a part of the design process, but are often unqualified. This way, they are engaged in the project and have a great deal of ownership in the end result.
I think what makes Basecamp such a successful endeavor is that are building it BECAUSE they needed it themselves. That mentality is going to help you build something so much better and understand it much more deeply than if you were building an abstract idea for a client.
The fact that what they needed is also needed by thousands of other businesses worldwide is what makes it profitable.
I think it would be much harder to succeed if you saw a need and wanted to capitalize on it, but really had no use for it yourself. In that scenario you would need documentation, and probably a LOT.
Jason Fried
Exactly. You can’t ever skip learning about users.
We certainly don’t advocate skipping learning about your customers. What we advocate is taking what you’ve discovered and then building off of it instead of writing off it it.
The sooner you have something that people can actually use, the sooner you’ll find out even better information from your customers.
Ward Andrews
The sooner you have something that people can actually use, the sooner you’ll find out even better information from your customers
Jason, at what point is the interface experience mature enough that the designer won’t lose users’ interest and commitment in a ‘beta’ application? Or do you suggest that users, seeing a lack of functionality and usability, will become passionate contributors to the final product through suggestions to the designer? It seems there needs to be enough of a hook and a certain amount of ‘greatness’ built in to the interface to promote that type of response without losing the early user base.
The sooner you have something that people can actually use, the sooner you’ll find out even better information from your customers.
This is what I’ve seen in the project mentioned above. Every time we share our progress with the people who will be using the tool, we got lots of “even better information” back from them.
I’ve been wanting to participate here, but have been swamped the past day or so. Anyway, looking over these comments, my main thought is: so can we all pretty much agree that what we’re talking about here is the development of a tool or an application?
That seems to be what this method is best suited for — and I’m by no means trying to disparage it. I’m just wondering to myself, how would this work when designing a site like, say, Travelocity, which is part Web application and part marketing, with both being rather intertwined.
It could work, but it’s not as clear to me how — I can see running into lots of problems running too far ahead of both marketing and engineering when iterating the user interface.
I’ve used prototypes the same way for IA. In all my current ‘brochure ware’ projects I’ve had some good sucess by building a text only version of the site first. It really helped to work on things like navigation and contextual links. It also, like John mentioned, really helped draw better content out of the client and get more information from them about their needs.
*Seeing* the site so soon was a big help, and much easier to test an architecture than paper site maps have been in the past. In the same way an interaction can *feel* wrong when you are clicking through an application prototype, I found problems with my architecture by playing with text and links ‘in the real’.
Later designing these prototypes, things got moved around ect. But it was great having so much worked out ahead of time before sitting down with photoshop. A lot of ideas came out too because I was so intimately familiar with the content. A wee bit of a side benefit.
Ryan: is that the same as the method that Jason is advocating? I think what he’s saying is that, as soon as possible, start designing the final user experience — including real code. What you’re describing, though it’s iterative, might still be classified as preparatory. Because until your prototype stage has finished, people are still waiting around; the designer is not designing in Photoshop or Fireworks etc., the design technologist (builder) isn’t generating HTML, and the programmer isn’t writing source code.
It’s what he does best. In fact, it’s his mission. from which he rarely strays.
“Given two equally capable design studios, I can guarantee that the one that has the greater capacity to balance a client’s internal politics will win the day in any design effort.”
What, Khoi, is your definition of “win the day”? The politically adept designer will assuredly get the job. There is no doubt. Yet, given equal capability as you posit, the same politically adept designer will assuredly deliver the most universally acceptable (read: mediocre) solution. Absolutely. Is that the “win”?
“this is a method that returns designers to that core notion of visceral creativity…”
Thank you a thousand times for writing this on the wall. Paul Rand, in his last living interview affirmed the notion. He was proud to say that the best of his works were based on intuition first – gut instinct. Rationalization, required only by his client, was something that followed to meet requirements.
“You need to walk before you can run”
Unless you’ve done it all the wrong ways, your pitch for the new way will fall on deaf ears.
It is from what I understand. The basic premise is don’t do things when you don’t know if they work. In other words functional specs are really unrealistic and you can’t know if something is really going to ‘work’ or not, in all senses of the word.
“The goal here is to get as close to the real customer experience as possible”
I’m just saying that in an informational site, the real experience is the pages and content in HTML. So going there asap proves just as useful with IA as it does Interaction Design. To me, the visual design should be interwoven all throughout and alongside that entire process. Iterating back and forth, but always close to the real HTML build-out.
You have to sit down with the copy, the links, the pages, and read and use it like a visitor does. Doing so brings out real ideas, ideas you can’t get in an abstract document. It’s more about working on the actual product, in the actual medium, as much and as often as possible.
JF: “We certainly don’t advocate skipping learning about your customers. What we advocate is taking what you’ve discovered and then building off of it instead of writing off of it.”
Wait a minute, doesn’t tossing functional specs aside conflict with their “using patterns in web design” idea? The post encouraged me to do quite a bit of writing before designing in a recent project and I have to admit it helped a lot, to brainstorm with a list of features first before grouping them and then trying to visualize it.
Brandon
Wait a minute, doesn’t tossing functional specs aside conflict with their “using patterns in web design” idea?
I don’t think I’d look at it like that. The writing they advocate in that article is very minimal. It’s just a quick list of things to gather your thoughts. It’s not a functional spec by any means. They say it’s not about features, just ideas about what the product might need to do. There are no details, only big picture ideas. Then they design.
Jason Fried made some waves at this year’s South by Southwest Interactive conference with a talk he gave entitled “
I think you are right when you say this approach works better for product development than client work, but in my experience, the distinction is not even as clear as that. With client work, I can jump into designing interface prototypes a lot sooner when I am building a web application than a public-facing site.
For whatever reason, clients don’t like to see a site with obviously incomplete content or a rough design, but they don’t mind seeing an application with a bare bones interface and only half the features intended for the final release. Why is this? I am not sure. Do you have any thoughts?
Keep in mind also that in this rare case, they were truly building the product for themselves first. That’s obviously not often the case with client-driven work. The fact that they did no user research, market analysis, or strategic planning makes Basecamp quite an anomaly. It will be interesting to see if thier next project “Honey” is also something they themselves needed, or if it’s more of a market-driven product.
John’s point above is crucial: this method seems to work *only* for application development, clearly it would be terrible for advertising or other more “graphic design” sorts of jobs.
Great piece. Thanks for your thoughts. Hopefully we’ll have a chance to continue our discussion in person again soon.
FYI, I’ve posted the slides.
Andrew said:
“Keep in mind also that in this rare case, they were truly building the product for themselves first. That’s obviously not often the case with client-driven work. The fact that they did no user research, market analysis, or strategic planning makes Basecamp quite an anomaly. ”
– I think that if they were really building it for themselves, then they had probably done *years* of user research and market analysis, leading to them solving their own problem.
Exactly. You can’t ever skip learning about users. They were the client and had done the ‘research’ in that sense. And since they were building a product for themselves, there’s no need to produce documentation, that at it’s core, is to communicate an idea. They simply create the idea as a prototype and talk about it.
What you want to do is get the method most close to real that can communicate your idea. For some larger teams I think they choose to accomplish this with functional specs, and are stuck in that rut. For smaller teams, or teams not stuck in that rut, going straight to a prototype *is* the cheapest and quickest way to communicate the idea.
I think to sum up the concept for me, interface *is* the way to determine the product. Not functional specs or other highly abstract documents. If you can show/communicate the user’s interface then anyone can understand and agree what it’s going to do. This is a lot more efficient at developing a realistic product and meeting date and budget constraints.
I think the politics are in what clients are *used* to doing or are expecting. If you can manage the politics of the client, and turn their expectations towards focusing on interface, then you certainly can put this into practice on a day-to-day basis.
Good thinking, Ryan. (Nice site, by the way.)
Like you said, a lot of clients have gotten used to doing things the wrong way. But if you can find good clients, _or_ educate your clients to appreciate this method, the benefits are great for everyone involved.
I am working with a great client right now that is very involved and open as we develop a content management system for them. We started by creating a minimal useful system (interface first), showing them that prototype, then adding features one or two at a time and sharing with them. At each stage, they have good ideas for us — some big, which we keep track of, and some small, which we can implement almost immediately.
A nice side-effect (or maybe it’s a central effect) of working this way is that you are truly engaged in a dialog with your client. Clients like to be a part of the design process, but are often unqualified. This way, they are engaged in the project and have a great deal of ownership in the end result.
I think what makes Basecamp such a successful endeavor is that are building it BECAUSE they needed it themselves. That mentality is going to help you build something so much better and understand it much more deeply than if you were building an abstract idea for a client.
The fact that what they needed is also needed by thousands of other businesses worldwide is what makes it profitable.
I think it would be much harder to succeed if you saw a need and wanted to capitalize on it, but really had no use for it yourself. In that scenario you would need documentation, and probably a LOT.
Exactly. You can’t ever skip learning about users.
We certainly don’t advocate skipping learning about your customers. What we advocate is taking what you’ve discovered and then building off of it instead of writing off it it.
The sooner you have something that people can actually use, the sooner you’ll find out even better information from your customers.
The sooner you have something that people can actually use, the sooner you’ll find out even better information from your customers
Jason, at what point is the interface experience mature enough that the designer won’t lose users’ interest and commitment in a ‘beta’ application? Or do you suggest that users, seeing a lack of functionality and usability, will become passionate contributors to the final product through suggestions to the designer? It seems there needs to be enough of a hook and a certain amount of ‘greatness’ built in to the interface to promote that type of response without losing the early user base.
The sooner you have something that people can actually use, the sooner you’ll find out even better information from your customers.
This is what I’ve seen in the project mentioned above. Every time we share our progress with the people who will be using the tool, we got lots of “even better information” back from them.
I’ve been wanting to participate here, but have been swamped the past day or so. Anyway, looking over these comments, my main thought is: so can we all pretty much agree that what we’re talking about here is the development of a tool or an application?
That seems to be what this method is best suited for — and I’m by no means trying to disparage it. I’m just wondering to myself, how would this work when designing a site like, say, Travelocity, which is part Web application and part marketing, with both being rather intertwined.
It could work, but it’s not as clear to me how — I can see running into lots of problems running too far ahead of both marketing and engineering when iterating the user interface.
I’m not so sure.
I’ve used prototypes the same way for IA. In all my current ‘brochure ware’ projects I’ve had some good sucess by building a text only version of the site first. It really helped to work on things like navigation and contextual links. It also, like John mentioned, really helped draw better content out of the client and get more information from them about their needs.
*Seeing* the site so soon was a big help, and much easier to test an architecture than paper site maps have been in the past. In the same way an interaction can *feel* wrong when you are clicking through an application prototype, I found problems with my architecture by playing with text and links ‘in the real’.
Later designing these prototypes, things got moved around ect. But it was great having so much worked out ahead of time before sitting down with photoshop. A lot of ideas came out too because I was so intimately familiar with the content. A wee bit of a side benefit.
Ryan: is that the same as the method that Jason is advocating? I think what he’s saying is that, as soon as possible, start designing the final user experience — including real code. What you’re describing, though it’s iterative, might still be classified as preparatory. Because until your prototype stage has finished, people are still waiting around; the designer is not designing in Photoshop or Fireworks etc., the design technologist (builder) isn’t generating HTML, and the programmer isn’t writing source code.
“Jason Fried made some waves…”
It’s what he does best. In fact, it’s his mission. from which he rarely strays.
“Given two equally capable design studios, I can guarantee that the one that has the greater capacity to balance a client’s internal politics will win the day in any design effort.”
What, Khoi, is your definition of “win the day”? The politically adept designer will assuredly get the job. There is no doubt. Yet, given equal capability as you posit, the same politically adept designer will assuredly deliver the most universally acceptable (read: mediocre) solution. Absolutely. Is that the “win”?
“this is a method that returns designers to that core notion of visceral creativity…”
Thank you a thousand times for writing this on the wall. Paul Rand, in his last living interview affirmed the notion. He was proud to say that the best of his works were based on intuition first – gut instinct. Rationalization, required only by his client, was something that followed to meet requirements.
“You need to walk before you can run”
Unless you’ve done it all the wrong ways, your pitch for the new way will fall on deaf ears.
–
Khoi: Great commentary. The best I’ve read.
It is from what I understand. The basic premise is don’t do things when you don’t know if they work. In other words functional specs are really unrealistic and you can’t know if something is really going to ‘work’ or not, in all senses of the word.
“The goal here is to get as close to the real customer experience as possible”
I’m just saying that in an informational site, the real experience is the pages and content in HTML. So going there asap proves just as useful with IA as it does Interaction Design. To me, the visual design should be interwoven all throughout and alongside that entire process. Iterating back and forth, but always close to the real HTML build-out.
You have to sit down with the copy, the links, the pages, and read and use it like a visitor does. Doing so brings out real ideas, ideas you can’t get in an abstract document. It’s more about working on the actual product, in the actual medium, as much and as often as possible.
JF: “We certainly don’t advocate skipping learning about your customers. What we advocate is taking what you’ve discovered and then building off of it instead of writing off of it.”
Wait a minute, doesn’t tossing functional specs aside conflict with their “using patterns in web design” idea? The post encouraged me to do quite a bit of writing before designing in a recent project and I have to admit it helped a lot, to brainstorm with a list of features first before grouping them and then trying to visualize it.
Wait a minute, doesn’t tossing functional specs aside conflict with their “using patterns in web design” idea?
I don’t think I’d look at it like that. The writing they advocate in that article is very minimal. It’s just a quick list of things to gather your thoughts. It’s not a functional spec by any means. They say it’s not about features, just ideas about what the product might need to do. There are no details, only big picture ideas. Then they design.