The product development process is, among other things, the method by which the creative tensions between designers, developers, and business people are resolved into a coherent product. It's similar to a political process, which is a way to resolve the tensions in society into a coherent form of government. Well-functioning organizations funnel those tensions into a commonly accepted process, and make decisions using an established process that everyone supports.
Dysfunctional organizations work more like countries in transition, the ones that end up tearing themselves apart over how they should be governed religious autocracy? Monarchy? Democracy? Value judgments aside, those are simply different ways of resolving the tensions in society: you can vote on them, you can submit them to a body of religious elders, or you can just shoot everyone you don't agree with. If you all agree on which process to use, then you have a functional country. If ten percent of the country wants a totalitarian monarchy, and the rest wants a democracy, then you're probably not going to get much governing done until that tension is resolved.
The product development process defines how you make decisions, who is involved in making those decisions, how you deal with decisions you don't agree with, and how those decisions are implemented. Within the process, you discuss and compromise and negotiate, but everyone has to agree on what the process is and abide by it even when they don't entirely agree with the outcome.
The magazine approach versus the art book approach
As someone who works primarily with news and content organizations, I often see problems when two starkly different product development processes as different as monarchies and democracies collide. The opposing models are what I call the "magazine" approach, which assumes rapid and frequent deadlines and a "doesn't have to be perfect, does have to be finished" attitude, and an "art book" approach, which focuses on one distant deadline, with everyone focused on perfection. While there are many flavors of each, just as some democracies have kings and some dictatorships have parliaments, product development processes ultimately fall into one or the other of those camps.
The "magazine" approach roughly corresponds with rapid or agile development; it's a single-stream process in which everyone works together, on a schedule of frequent deadlines. People tend to move fluidly within roles, rather than working through an established hierarchy, and decisions are made quickly with the understanding that they can be adjusted or revised in the next release. This is how a newsroom works.
The "art book" approach, on the other hand, is closer to what's known in the software world as "waterfall development." You have a far-off publication date for an expensive, beautiful book that needs to be as close to perfect as possible. Every page will be examined in detail. There are separate and often sequential work streams: the book's design will be completed before the typesetters start work; the photographers will probably not know how their photos will be used. Essentially, the product is designed, and then turned over to the people who will actually produce it. There is much less interaction between the teams, and everyone tends to stick to their assigned roles. Decisions are made in a hierarchical manner, and are seldom open to question afterwards.
Hardware is almost always developed this way. Apple designers in Cupertino work for weeks or months on how the new iPhone will look. Then they send it off to China where it is actually built. The manufacturer evaluates the design, prices it out, plans suppliers and staffing, and schedules the work. But the manufacturer has no influence over the design decisions, and the designers are largely disconnected from the technical implications of their designs (for instance, the health issues involved in polishing iPhone backs to a mirror finish).
Traditional packaged software is developed similarly. The next version of Windows or iOS takes months if not years to develop, and is released with a big announcement. There are hundreds or thousands of people working on the project, each with fairly well-defined roles, very strict deadlines, and little control over anything outside their immediate area of responsibility. The goals are long term, and when they are achieved everyone kicks back for a while and takes a breather before the next release.
Neither approach is "right"
Both methods of development are equally valid, depending on the goal. You cannot be constantly changing a phone, or software that's going to be installed on millions of computers in the factory. This kind of approach is often used to build static web sites, but it's not really appropriate to dynamic sites. Agile methodology was developed, in fact, to encapsulate and formalize the way successful dynamic web sites were built.
On the other hand, product and marketing web sites tend to work differently, especially the big splashy one-off sites. They change less often after they launch, and which are often replaced by another redesign in a few years, rather than evolving continuously over time. Web sites for the release of a new album by a major artist are good examples they need to be ready on an exact date, you have months to prepare for that day, and once they're launched they aren't going to change very much. And when the next album comes out, the site will be thrown away and redesigned from scratch.
The process of developing a site like that is completely different from the process of developing a constantly changing content-oriented site. While those sites usually start with wireframes, the difference begins in the transition from design and IA to development. In the static approach, developers are usually handed a design and told to implement it. It's similar to classical music, where a designer or information architect composes a score and the musicians play from it. The musicians are highly skilled, and have some interpretive freedom, but they are expected to play what's written, or to improvise only when told to.
My approach is closer to jazz. The leader does not hand out sheet music, but sets the tempo, the key or the mode, and provides the basic melodic theme, and the group as a whole takes it from there. In both cases there is a single defining vision, but in the first, the vision is defined before it is handed to those who will realize it. In my approach, the vision is defined, developed and modified by the group as it is realized. And rather than writing instructions for the musicians, the leader is one of the musicians, playing alongside everyone else.
When approaches collide
Therefore, I frequently find myself in opposition to designers or developers whose background is in developing large static web sites. The designers want to draw beautiful pictures of every page, which the developers must match pixel-by-pixel. Once a page is approved, they expect it not to change. The developers don't want to think or interpret, they just want to build. But that's not how I work, or want to work. I work on dynamic sites that are never finished, that change constantly, and where it is dangerous to tie the content or the technology too tightly to the look and feel of the product. There is no time for a designer to review or approve every page on the site.
These sites are built from components, so full-page Photoshop comps are much less important than specifications for the components, and flexible rules for how they work together. (Designing full pages can, in fact, be dangerous, because it leads you to think only about the combinations of components that are presented, and not the many other possible combinations that will arise in the real world.) Designers may produce page comps during the design process, but the final deliverables should be component designs, style rules and specifications with which pages can be created. Also in this process, many "designers" are also "developers" in that they don't deliver pictures, but working code and CSS.
There are still, of course, creative tensions: the designer may want a header design that the developer thinks is too heavy, or the designer may want to prevent the editors from changing some things while the editors want to do anything they like. Those tensions are often resolved by direct conversation, or by actual development. Here's what I think, does that work? No, but how about this. And so on. Creative tension is good: It drives us all to work better, knocks us out of our ruts, produces work that none of us could have done on our own.
Is your tension "creative"?
The key question to ask about your organization is whether the tension is creative. If designers think they are composers, writing sheet music, and the developers are jazz musicians, who will look at written music only long enough to figure out a basis for their improvisations, then you're not going to have creative tension. You're going to have wasted effort (unread sheet music), lousy music, and general unhappiness.
This question must be resolved. I've seen far too many organizations that say they want to be agile, but then try to impose strict checkpoints, or try to involve people in the process who don't understand it or don't have time to be involved fully in it. Or hotshot startups that say they want to be "agile" but actually mean they want to run around in circles really fast.
You must decide what product development model your organization will use, and then everyone must use it, fully. You cannot have some people pulling one way and some pulling the other: you will waste time and money and energy, and your product and company will suffer as a result.
The projects I want to work on are dynamic, content driven, and structured in a way that will outlast the next redesign and the one after that. They won't make assumptions about how its content is displayed or how it will be used. It will take maximum advantage of the intelligence of the editors or journalists who work on it, and it will be able to support product ideas we have not had yet. It will grow and evolve and it will never be "finished."
- Ken's blog
- Login to post comments