There’s a phase we go through in our maturity as designers. At first we don’t have a lot of confidence in our process, so we hide while we work. We take feedback from directors, programmers, customers, and say “Ok let me go away and work on that and I’ll get back to you.” Then we go away for a few days or a week and monkey around with our mysterious process until we feel good enough to show something again. We don’t like to show things that are still in progress. If somebody checks in we say “I’m still experimenting with a few things.” We design in secret.
When we get more confident a new phase opens up. We believe more in our process and we know that things are never perfect. So we start showing work earlier and start talking about our rationale at a given step. We’re excited for feedback on a clumsy design because we know feedback will steer us to a better one. We might even be unafraid to open our tools and do some real work in real time in front of people. This is designing in the open.
Is there anything we can do to speed the transition from designing in secret to designing in the open? My experience is yes, it can happen with a little help from the outside. Whoever is managing the project or directing it can ask for smaller, more frequent steps.
Instead of asking for 10 changes and waiting a week, you can ask for 1 change and wait 15 minutes. Evaluate the change, praise it or identify weaknesses, and suggest the next change. By asking for small changes, you take the pressure off the designer because you aren’t asking for miracles. You also take the pressure off the review process because the set of constraints and motivating concerns is smaller. The design is easier to talk about because there are a fewer factors involved.
By working hand in hand, reviewing small changes as they are made, designers gain confidence and learn to expose their process. And this technique is no training wheel. The better a designer is, the more open they are to discussing small changes and getting feedback. It’s a virtuous cycle leading out of secrecy and into productive openness.
Update: Pixar President Ed Catmull makes the same point in this quote on getting over embarrassment:
In the process of making the film [Toy Story], we reviewed the material every day. Now this is counter-intuitive for a lot of people. Most people—imagine this: you can’t draw very well, but even if you can draw very well, suppose you come in and you’ve got to put together animation or drawings and show it to a world-class, famous animator. Well, you don’t want to show something that is weak, or poor, so you want to hold off until you get it right. And the trick is to actually stop that behavior. We show it every day, when it’s incomplete. If everybody does it, every day, then you get over the embarrassment. And when you get over the embarrassment, you’re more creative.
As I say, that’s not obvious to people, but starting down that path helped everything we did. Show it in its incomplete form. There’s another advantage and that is, when you’re done, you’re done. That might seem silly, except a lot of people work on something and they want to hold it and want to show it, say two weeks later, to get done. Only it’s never right. So they’re not done. So you need to go through this iterative process, and the trick was to do it more frequently to change the dynamics.
Thank to Ben for pointing me to the Catmull quote.
Lee
on 25 May 11Interesting thought. But at some point doesn’t this almost turn into micromanagement?
Paul
on 25 May 11On the article: Yes, yes, a thousand times yes.
I wouldn’t say this is micromanagement. It’s in the spirit of iterative design.
Morten Hjerde
on 25 May 11You could take it a step further. Do both design and development in the open and invite people to co-create with you. It is not for everything, and it requires some clear boundaries, but for a certain type of projects it can be very powerful.
Garth Braithwaite
on 25 May 11Personally I think this is more about the designer’s attitude than the manager’s. Designers should be open about their process. Perfectionism can be paralyzing especially when there is only one designer on a project.
Arnþór Snær
on 25 May 11This approach also supports reviewing (testing) features in isolation, which focuses the feedback.
Steve
on 25 May 11Sounds like micromanagement to me. I realize it works for some people, but for me, that sort of thing will only end in tears.
RS
on 25 May 11Re: micromanagement, the question is whether or not you want to learn.
If you see design as a learning process, then you will want steady feedback to tell you how you are doing.
If you don’t appreciate steady feedback, then short iterations aren’t for you.
Mark
on 25 May 11I don’t see this as micro managing, but as tearing down the wall between design and the rest of the company. It forces the designer to defend a design and it also gives them a chance to educate the team on design and usability principles.
Dave Bloom
on 25 May 11Pros and cons. You state the pros very well, but the micromanaging argument is valid.
Sometimes, what may look like a poor design decision in isolation (when a project is cut into tiny pieces and reviewed on a linear basis) may end up supporting a functional/aesthetic ‘whole.’ We wouldn’t have Google if their founders had ‘perform spell check on company name’ as one of their inital process steps, which is in most cases a wise idea. We’d have Googol. DB
Steve R.
on 25 May 11There is another moving piece here – the audience. I work in consulting, and some (smart, wonderful) clients love to see rapid progress and provide fast feedback and are willing to tolerate the natural ebb and flow of test failures, function placeholders and roughness of a work in process. Others look at a project that is missing a logo or where the colors are off, or a dropdown doesn’t populate correctly yet and think they hired a moron and your product is garbage – even if it works flawlessly and looks great when done, they have to overcome their earlier perception. One day, I hope to be able to fire such clients, but until then…
Natalia Ventre
on 25 May 11I like very much the idea of designing in the browser and be able to show early stages of the site/app, get feedback, make quick changes, etc. but I hate having people watching me working over my shoulder. I don’t need weeks or days, it’s not my intention to be mysterious, I just need 5 minutes alone to focus.
unknown road
on 25 May 11If you go down this route of designing in the open your going to experience design by committee or worst someone shadowing you. Someone telling you to ”...move this here, add this screen, make the icon like Apple, we need more pop-ups, it’s not web 2.0 enough…” If you had listen to this every 15 minutes forget it. Your not progressing by designing in the open.
I think designing in the open with other designers and key stakeholders is fine when the team is small, the decisions are small and the meetings are short. Having a prototype / mock up is a must.
Al Abut
on 26 May 11@RS that’s one axis to consider, how receptive the designer is to feedback.
But there’s another important one too – the design training of the person giving it. As a designer, if Ryan’s giving me feedback as a fellow designer and I trust his eye, then I’d be more willing to show incremental work.
Showing too much of your in-progress work and constantly asking for feedback can go too far, like the kitchen contractor on Seinfeld that never got anything done because he asked too many questions:
http://www.youtube.com/watch?v=OEidJj45h-M
Alex Humphrey
on 26 May 11Very interesting indeed. I like this idea a lot, but I wonder if it’s unrealistic.
I suppose it would work really well for smaller organizations, but for bigger organizations it just doesn’t seem very scalable. Maybe if you start small, do this one employee at a time, and continue your work.
As a small business owner and a trainer I agree with a lot that is here, I just don’t see how it will scale.
Spencer Caldwell
on 26 May 11Love this approach!
Jussi Pasanen
on 26 May 11I reckon finding the ideal duration for the “design window” is crucial and depends on the people, the part of the project and the organisation. To me 15 minutes sounds awfully short, especially considering that best design and development takes place “in the zone”. Is it possible to get to that state if you have a chat every quarter of an hour?
I am all for openness but the risk of micromanagement and subjective off-the-cuff feedback is real, too. We don’t want this: Hovering Art Directors.
It’s all about the balance.
RS
on 26 May 11When we’re really in the flow here at 37signals, we exchange screenshots in Campfire every 5 minutes or less. Quick ideas and directions are flying back and forth and the designer drops screenshot after screenshot into the chat log. The best days have fast back and forth sessions like that.
There are times when you have to chew on a design alone for a few hours, but that’s never as fun.
About the whole micromanaging / hovering director thing, we don’t think of it like that. It’s more like two friends sitting together working something out. Or when you are learning from a teacher and they keep helping you and adjusting your technique. Those are really positive experiences.
Anonymous
on 26 May 11While I like the idea in theory…and I think depends a lot on having the right people giving feedback (and the designer’s attitude as has been stated)...I’ve also recently experience the negative side of this: Everyone has a vote (or so they think). Everyone has a vision (and some of them contradict one another). Everyone “knows” how the user will view this (despite telling me exactly the opposite of what actual users told me.)
Needless to say it was quite frustrating.
Jussi Pasanen
on 26 May 11Thanks for your reply Ryan, that sounds awesome and something to strive for. I hope I get to work like that one day :)
izidor
on 26 May 11So you say getting requests like “move this button up and make it green” is a good thing?
Spending an hour explaining why you can’t “Make this text red” is a good thing?
Making client feel his wishes are not respected by refusing to do the above requests is a good thing?
You work in an exceptional small design-oriented environment.
Claiming that “open” is good for everybody is a terrible advice for designers in general environment, which is not design-oriented and is the norm.
Neil
on 26 May 11It works when you have someone to rebound off that think’s alike. Personally, I’m all for that process but when you have managers that don’t know what they’re talking about then it turns into a disaster!
Sketches, wireframes and then final design. Perfect.
David Smith
on 26 May 11This works when the person reviewing the design is as skilled and competent as the designer. It doesn’t work when there’s an imbalance – either way.
In the worst case, you get this: http://blogshank.com/2008/06/160608/
Ragnar Freyr
on 26 May 11– It’s more like two friends sitting together working something out. –
This sentence should have been in the article. I love this approach and I love the flow you can get into when it just works. But that’s admittedly rare.
It’s all about mutual trust and competence. Designing in the open with people you trust can be quite euphoric. You trust them to make good decisions and do great work and they equally trust you. You become as one and do work faster, better and stronger. And both of you learn a helluva lot from it.
Although I do believe in showing work early and often I’m of the opinion that if you don’t trust in your coworker’s competence, this approach can result in suboptimal work.
Dennis Eusebio
on 26 May 11I think for gradual changes to the an interface this makes the most. But, the key here is that you have to be able to sell things at any moment regardless if it’s a sketch or a full blown html prototype. Not everyone can and not every client has the ability to see beyond what’s in front of them.
Having great clients allows this process to work. Bad clients or committees would make this process terrible. But then again, they’d kill any design project in general.
Tim Wright
on 26 May 11I could see this getting really annoying after a certain point, but that may just be my design mindset.
I do think it would be great designing in pairs as a sort of checks and balances, like coding in pairs to get another eye on your work and having that connection constantly open for feedback. 2 people would definitely be enough for me, too many cooks in the kitchen is a comment problem and do get really frustrating.
Brad Colbow
on 26 May 11As a designer I can say that the process laid out here is my idea of hell. I don’t want changes piecemealed out to me. Design (especially interface design) has to be looked at holistically. If one thing changes it effects how the elements around it are perceived. Even a simple tweak can draw to much attention or not enough.
I think it’s better to present the problem not changes to the designer and work with them to figure out a solution so all involved can understand what the goals are and what is being worked towards.
Simon Foust
on 26 May 11Ryan, others have already made some good points in the comments here. I would just add that the assumption you began with seems to be that the goal of the “designer” in this context is to make you happy.
But shouldn’t the goal be to solve the problems for the project? What is he supposed to be designing? Sounds like he’s supposed to be making something that meets your subjective style preferences. That’s decoration, not design.
David Smith – damn, that comic strip is great, and perfect for this topic.
Ryan Heath
on 26 May 11Brad Colbow: Spot on, I agree completely.
Avangelist
on 26 May 11In most jobs I have been the sole design resource, I occassionally have worked with people in the team who have been inspirational in their feedback.
But there is something wonderful that you can gain when working with someone who you gel with, I’ve had partners that I’ve wondered on how they ever got the position they were in and some who I wake up excited to hit the html with.
That is where true agility comes from, but I think we regularly think of agile design as being the ability to deviate from your end vision – the blueprint when a programmer finds it is too time consuming to meet your requirements.
James
on 26 May 11I can see how this sort of quick, iterative approach might work at 37 Signals where you’re effectively your own client and can set your own working practice but I can’t really see how someone leaning over your shoulder “working with you” can possibly be helpful to anyone.
All you’re doing is making potentially wasteful, rush judgements and then mocking them up “to see if they’re better” rather than addressing potentially bigger issues.
I’d also have to agree with Brad Colbow in that this sort of process in most cases sounds like it would be nothing short of client directed madness and I have had to work like this on occasion with a client just dishing out “suggestions” on a rapid fire basis.
It’s wasteful and never ever improves the final work.
J.
Josh Walsh
on 26 May 11Iterative design and great, but feedback can actually be harmful if your design isn’t at a spot where you are ready to show it.
Forcing someone to show unfinished work in order to get feedback on it is pretty uncomfortable and not very efficient.
Dave Giunta
on 26 May 11I think some people are getting hung up on their impression of how this type of interaction would go. I think some people are assuming that because Ryan said “manager of the project” and “request changes in smaller increments”, that this was a “directive” approach, rather than a cooperative approach. I think that might be why so many people are characterizing it as “micromanagement”.
When I was a rather young designer, I had a fantastic Creative Director who taught me quite a lot about design in general. He did it by being open about his misgivings of his own talent. He treated me like a creative equal. Often times we would have working sessions where both of us would be standing next to the same computer taking turns sitting down and “futzing” with the ball of clay in front of us. We would each sit down whenever we felt like we had an idea of how to solve the problem at hand… the other would watch, sometimes make suggestions or hold onto their thoughts until the person sitting in the seat had worked through their immediate thought.
I guess in some ways you could say this was “design by committee”, but I like to think of it as a couple of skilled individuals (one quite a bit more skilled than the other in this particular case, but still), putting their heads together to solve the problem at hand better than either of them would’ve solved it on their own.
My favorite part about that project is that at the end of the day, my Creative Director and I both “owned” the design, in the sense that both of us felt like we had put our stamp on it, and yet neither of us could necessarily point to one thing in the design and say it was uniquely ours.
I think this sort of thing is incredibly important. If for no other reason than it makes going to work pretty fun, and creates a bond between co-workers that wouldn’t exist otherwise.
As for how to shorten that gap between the closed designer and the open designer… I would say the best way is to lead by example. Surely a closed designer will feel a lot more willing to try being an open designer if they see (and participate with) their open-designer-type co-workers.
Mark
on 26 May 11http://andyrutledge.com/the-designer-designs.php
Matt
on 26 May 11I love making change in real time, but I’ve found this requires two things. 1. you need to be really good with your tools. 2. you can only do this with changes that you can fix fast. hopefully the software architecture allows you do this, but that is not always the case. this is where design tradeoff can kill you or a really good OO design shines.
RS
on 26 May 11Now I’m starting to see that I didn’t explain something clearly in the original article.
At 37signals, the people who lead/direct projects are designers. They aren’t clients or “project managers” or whatnot. So when I said that the one managing the project can ask for smaller steps, over here that means a designer who is leading the project.
Of course I agree that we shouldn’t be taking microdirection from clients or non-designers on how we do our design work.
Andrew
on 26 May 11Ryan: The article seems to suggest that you’re a heavy-handed manager saying ‘come back in 15 mins and don’t be late! It’d better be good’.
Whereas your last comment says what you’re really meaning which is to designers…’share lots, share very often’ to create the collaborative environment that you love.
JZ
on 26 May 11@Dennis RE: “But, the key here is that you have to be able to sell things at any moment regardless if it’s a sketch or a full blown html prototype.”
Isn’t “selling” in this case just being able to explain the rationale behind the decisions you made? If you’re not able to do that, you’re probably making arbitrary decisions anyway – and that’s something that this process process helps us avoid. Small, focused iterations mean that we’re staying on target and not following tangents, which I think is an easy temptation for any designer.
Stephen Parker
on 26 May 11For me, overall heavy focus on small iterations like the process described in this article and subsequent comments – even among designers – tends to result in pieced out design that is never really greater than the sum of its parts or holistically beautiful.
Kori Roys
on 27 May 11I’m not a designer per se, but rather an engineer. However, your post reminded me of something I had forgotten: don’t worry about getting it perfect the first try, you probably won’t.
So today I quit trying to be perfect and just charged through three iterations of a part layout design before lunch. As a result of the quick back and forth between my boss, the machine operator, and me, questions were raised that led us to take a closer look at the process itself.
After some investigation, we realized we could move some work and avoid purchasing a $140,000 piece of machinery. About $40,000 worth was already ordered or in the works (oops!), but it’s a much smaller oops now than it could have been, thanks to small changes and quick feedback.
Oh, and the design itself? Now on revision 5 and completely changed, since we’ll be shifting work around. Nice to find that out now, rather than after it goes into production and change becomes much more expensive.
Dennis
on 27 May 11@JZ
Agreed. Personally im used to selling my concepts early and often. Just wanted people to understand that there’s that second component to their design; the ability to communicate why its a better solution. It might not always be apparent, especially in early rough stages to particular clients.
(another) Bob
on 27 May 11I’m glad Ryan clarified that his client environment is designer-to-designer; however, the number of “agreeing-to-disagree threads” here is testament that even design colleagues can’t always agree on the process of design.
In my (corporate captive) environment I have to satisfy business clients, each of whom becomes a designer on each and every project. It’s no wonder we adopt analogy-speak, comparing our designs to houses and desk tops. When I show incomplete, iterative work to non-designer clients they either believe we are almost done or they’re really let down because some pieces are missing and it’s not polished.
Recently, I used a red herring design as the starting point so that the clients would be motivated to make suggestions to fix it. It worked, and got them working to provide details about functionality not color schemes. Our approach is: the business gets to decide what and development gets to decide how.
Mark Richter
on 27 May 11Mike Monteiro and Katie Gillum of Mule Design Studio speak to the importance of selling your solutions, starting at 38:40 in this podcast http://5by5.tv/mistakes/6
I think it applies regardless of who you are speaking to, or how quickly or slowly the iterations are coming.
Masta
on 27 May 11You’re basically talking about self-esteem. When it’s low, people feel inadequate and prefer to hide their insecurities. When they develop more robust self-esteem, they don’t mind flaunting their chops in the open.
Simples.
Rosevita Warda
on 30 May 11I think the process works fantastic if the people hiring the designer have a clear vision of where they’re going.
Many companies and the professionals who hire designers don’t. They’re waiting for the designer to make it all happen magically.
I always make sure to quickly move into the smart zone with my creative team, screen sharing, asking to be part from the early sketches, being part of the evolution.
I find that if designers are not comfortable with this approach, even in a low-pressure context, they’re probably not the right people to work with, and I appreciate realizing this early on.
Aside from that, bouncing things around together from the start creates much better results. No matter how well you think you explain the project, what you say and what the designer hears may still be two different things. If you approach this more like playing ball, you have the quantum leaps happen before the time consuming details.
Designers tell me that most companies look at them as the people who “reveal the solution.” I never understood this concept, but you can see the effects all over the marketplace.
I had a designer tell me once that he creates what he thinks is the right approach and than two variations of that concept that look less good. And he grinned and said—“and people are happy to have the choice.” It’s an awful, expensive and time wasting practice that produces mediocre results, but that’s what most companies are used to.
This discussion is closed.