Over at Signal vs Noise Jason posted a reply to someone’s comments. I’ll post it here:
I used to do all that stuff (wireframes, personas, sitemaps, etc), but discovered they’re about process, not productivity. In the past few years I’ve come around to being productive and working on what’s real, not working on process and abstractions. That’s what Getting Real is all about. And once you get it, you’ll wonder how you ever did it the other way before.
I would only suggest people do what works for them. Wireframes, personas, sitemaps don’t work for me and never have. I was blinded by process thinking that if I did that stuff then the rest would just fall into place. What I discovered was the only thing that really matters is what’s real — not representations of real, not diagrams describing real, not charts that simulate real, not fake personas that represent real people.
Has 37 Signals determined that these steps are no longer necessary?
For us they are no longer necessary. I think those steps are a complete waste of time. Your mileage may vary, but I’d challenge you to try to do without them. Once you do you’ll realize how insignificant they really are.
I had to comment on this since a significant part of our business at Tornado is spent building wireframes for the various types of sites we build.
I do think the wireframe process is valuable most of the time. I’ve been involved in projects where everyone involved had built so many sites that with a short discussion, a few minutes at the whiteboard, and bam we had a great idea of what we were going to build. And we could get to work immediately.
I think wireframes come in handy in three ways:
- Client communication — Simplifies communicating web site structure and page elements between client and design team.
- Collaboration among teams — I don’t care what you say, a wireframe is really handy in communicating page level functionality. Especially if teams don’t work together every day (outsourced or distance working).
- Forcing me to think about it — Putting it on paper forces me to think about it before I waste time designing and coding.
For example, Tornado recently assisted a company in the specification of a web application and the customer had never built a web application before. We didn’t have the development resources in house to build this application and so we built wireframes and site maps to help him communicate his project to development firms and to his investors.
We met with about eight development firms (all who responded that were of the right size) and I can wholeheartedly say that having a completed site map with dozens of wireframes made this a significantly easier project to discuss.
The best part was that all of the development firms that chose to put a proposal together were working from the same blueprints. That was amazingly valuable and reduced the potential confusion.
Do user personas and all kinds of use-cases make sense? They don’t to me. I muddled my way through hundreds of use cases back in 2001 and it was horrible. Looking back it was exactly what Jason wrote above. A huge muddled process where you think you are making progress however nobody is productive — they’re just busy.
It’s a good wakeup call and I’m glad for his post.
5 responses to “Are wireframes and site maps a waste of time?”
I understand Jason’s point, but I personally believe that productivity without process behind it is a waste of time…otherwise you are just ‘doing’ for the sake of getting things done, not for what is in the best interest of the project/client/challenge/etc.
I’m not saying every client deserves a branded wireframe and sitemap, with detailed case studies/user profiles. But, what I am saying is that at some point, for a project to be successful, the thought processes that drive these deliverables NEED to happen in order for success to be achieved.
I can’t figure out if Jason is saying we need to do away with the process of thought, or simply the process of creating the representations of the thought(site map, wireframe, etc), but IMO, by iliminating the thought, you eliminate a crucial factor in the success of your site/application.
Good feedback Jeff, I agree with you. The process is good for the reasons you outlined. I’m sure Jason isn’t arguing for throwing out the thought process. I would argue however that since he’s so in favor of iterations that it could drive developers mad with endless changes. No doubt 37s has a process they run behind the scenes that allows them to communicate and do the thinking.
I know from personal experience and experience working with you that I never have the best idea first. If I make a wireframe it will often be revised multiple times before everyone agrees it’s a go.
In the specific case study that 37 Signals presented, “getting real” was a completely logical thing to do. What allowed the case study to work was the following:
1. The designer was doing the development
2. It was a redesign of existing functionality
3. The scope was limited to a single “page”
As mentioned above it would be wise to create a better prototype than scratched on paper if someone else is responsible for implementation. Communication and getting buy-in is a large reason personas, use cases, etc… exist. If the functionality did not already exist and was any more complicated than the functionality described, diagrams and more thought can go a long ways.
Getting Real needs to be done more, and taught more to those in school. The practices of Personas, Use Cases, and Wireframes have been developed and should be used where they are most effective. 37 Signals recognizes this, and I imagine most experienced designers do as well.
To respond to Jason’s quote:
“Wireframes, personas, sitemaps don’t work for me and never have.”
How do you even go about a project without *some* type of documented planning? Maybe the UI and work flow magically appear in your head, you have a perfect visual memory, and no organizational buy-in, or negotiation, or sharing of ideas is necessary until you get a highly dynamic PROTOTYPE (to you probably known as the application-in-progress). Or you just get buy-in after your new application is developed, and everyone agrees with your vision and no revision is ever necessary. Must be nice.
I, for one, have used every type of prototyping imaginable depending on the particular situation.
Sometimes I’ve found it absolutely critical to do a paper prototype for myself, or to show a developer, and other times I dive right into HTML (for web-based apps) when I’m doing a slight redesign of an existing page or process.
Othertimes I’ve created excruciatingly detailed Bitmaps to spark the imaginations of people who matter; and god help me, yes, Powerpoint has saved me a a number of times when I needed to do some quick and dirty user testing and development on the new feature started yesterday.
So, please, please, please, always second guess yourself when you’re thinking in absolutes, especially when it comes to design. We can’t all sit around with Ruby on Rails working directly with our client, pleasing him/her as our ideas take the form of a working app, and expect the users to be happy every time.
I wonder if the lack of specs works for 37 because of the way the company is wired. (1) They develop their own internal stuff and (2) have a really smart internal staff that includes (3) leadership at the top from a designer. They let the design and interface lead the process. The interface design is the spec.
I think when you roll in the client or clients, a contract developer or designer, a web development shop, a consultant or ‘friend in the industry’…you need a gameplan, otherwise expectations of each party can be different. Everyone wants a say, everyone wants their ideas ‘on the homepage’, etc. You need a plan and documentation.
I once worked at a firm that had owners, AEs, PMs, developers, clients, the client’s bosses, client’s ad agency, etc all in the mix talking about features and technology. There were also designers in the room. Until we got a documentation process down, and let the designers lead it, we couldn’t get good work out. The IA thinking on a whiteboard and wireframes were a way for the designers to lock in good functionality and fend off poor choices. I think wireframes are more for protection of the product in a less than ideal development situation.
I am working on another project with a team of 4..I’m the designer, 2 developers and 1 who floats between the two roles and handles business aspects. We go straight from sketch, to screen design, to development with no specs (the design is the spec). It works perfectly in this arrangement.