Once upon a time, a project (the making of, let’s call it, “The Product”) would go like this:

• Having finished discovery, the project lead, an information architect, and a content strategist would articulate the site’s purpose, structure, content strategy, and page requirements. This would take the form of a package of deliverables including spreadsheets, site maps, and wireframes – henceforth called “The Package”.
• Next, one or more visual designers – now invited into the project for the first time – would review the The Package, ask questions about The Package, reinvent parts of The Package, discard parts of The Package, and produce a proposed design based on the modified Package.
• Naturally, the designers’ renovations called for the re-entry of the information architect and content strategist, despite the fact that our process frequently made such re-entries inconvenient if not unfeasible.
• The project lead, information architect, content strategist, visual designer, and project manager would now enter into the cavernous stomach of a giant whale, where they would become like heat and ingots in a gigantic crucible, emerging only once uniformity of purpose and presentation had been achieved in the form of The Designs.
• Next, we would get approval from the client (for the sake of this story, let’s say it’s for an internal desktop + mobile app development effort) or, that lacking, get feedback based upon which to return to the belly of the whale and reform The Designs.
• Victorious and enthusiastic, the designer and project manager would present The Package & The Designs to the developers, who – now invited into the project for the first time – would review the The Package & The Designs, ask questions about The Package & The Designs, reinvent parts of The Package & The Designs, discard parts of The Package & The Designs, veto parts of The Package & The Designs, and propose a development direction based on The New Revised Package & Designs.
• The developers would inevitably encounter gotchas in what was called for by The New Revised Package & Designs, and to resolve such issues, asked the project manager for access to either the project lead or the information architect or the content strategist or the visual designer or some combination of the aforementioned team members, and some such combination would variously approach and/or enter the belly of the whale before emerging, with a little luck, enlightened.

And so it would go, each trip into the belly of the whale more fragmented than the one before; each new solution requiring greater compromise; each revision draining at least as much life from The Product as it could give in return; each diminution of the original vision deadening the souls of the very people who so loved that vision as to dedicate their imagination, will, discipline, and days to its creation.

This process is what we call “waterfall-ish” – the “-ish” an ostensible apologia of our extra-waterfall adaptations. But that -ish concedes more than waterfall’s inadequacies in our workflow. It betrays the increasing untenability of the separation of roles that has become the most pronounced, characteristic result of a complex web that favors a hyper-specialized workforce over a workforce of generalists. And while the move toward hyper-specialization may be inevitable, we allow our division of roles and responsibilities to mirror that at our peril.

This insight isn’t new, but it’s revolutionary, each and every time a person has it.

When I worked in software development, our process was so constantly collaborative, we practically sat on top of one another. Instant Messenger never slept. Irreverent commit messages were connective tissue. We crossed our disciplinary boundaries constantly in order to bring to life a shared, uncompromising vision. Why should website development be different? In today’s world, where the lines between web sites, mobile web sites, mobile apps, APIs, SMS, TiVO, etc are as blurred as they are, every project is a complex product.

Everyone I know who’s doing Responsive Design remarks that, in order to get it right, they essentially had to relearn collaboration as professional enmeshment. Right now, on a mobile-first app project we’re working on, I’m learning the same thing. I’m learning that, way more than being a set of techniques, Responsive Design is a mindset. For every design problem we solve on the desktop display, the solution only works if we can make it work just as well on tablets and phones.

The techniques of Responsive Design take us partway there. Adaptations and augmentations thereto take us further still. Our own innovations deliver us. More important than expanding our abilities, though, we’re expanding our minds.

The truth, that Responsive is a mindset, is that the more we practice it, the less doctrinal our concerns. Hunting a better user experience expands our schemas. We find that it is not our products that are Responsive; it is ourselves. The dedication to a website’s programmatic flexibility forces flexibility within our teams, our minds, and our hearts.

In my view, that’s what you feel in the best-designed mobile-first apps and responsively designed products. Yes, it’s gorgeous and fluid and accommodating and surprising and delightful. Of course it is, because that’s what it takes in us to craft such a user experience.

Anyway, there’s this awesome project calling my name over here. I’d better get back to it.