IMHO, hybrids are extremely important to Sustainable Virtual Design. The typical web design process uses rapid, iterative design, which means that the site is built by creating a series of prototypes, each closer to the final site. In the early stages, these sites will always be build by hybrids at smaller shops. Since they know the “whole” site soup to nuts, they will tend to apply their optimization knowledge to their design – giving us the holy grail of optimization: FEEDBACK FROM PROGRAMMING ONTO EFFECTIVE DESIGN.
Larger shops with rigid divisions between “designer”, “art director”, “front end coder” and “site engineer” will tend to do the “waterfall” approach. The art director will create art in a fixed screen size, “rigid” grid tool like Illustrator or InDesign. The front-end developer will struggle to make all the pixels go into the web page, and make the rigid grid flex. A few pixels will be out of place. There will be a struggle between the two groups. One or the other gets the final word. The Art Director may end up “lording it over” the coders because they are “creatives” and should run everything, or the coders may stop the designers cold by sprouting tech jargon at them to shut them up.
Sheesh. I’ll take the generalist. Hybrid designer/developers (via the biomimicry aspect of sustainability thinking) are like crows, rats, and dogs – able to eat anything, adapt anywhere, and take advantage of new situations. They’ll tend to make sites optimized, flexible, adaptable, loosely coupled…all the stuff that sustainable products have. They may even be less likely to create “artist centric design” instead of “customer centric design”. They enable sustainability better than any other group.
Some nice posts by hybrid designer-developers (they are legion)
A sustainable framework will operate best if we use hybrids. In an organization, we want to find the most “hybrid” person on the project, and assign them sustainability. Most likely this will be:
- Designers with some front-end development ability
- Front-end developers that can design
- UX person who is a recovered designer/programmer (these are the best)
The people who will resist are the most specialized, probably the usual suspects:
- Back-end programmer
- Art Director
Here’s a great post describing how splitting everyone up into departments, especially at a smaller “lean startup”, is a disaster.
As the meeting progressed, the temperature kept rising. At first, I couldn’t even follow the recriminations back-and-forth. Eventually, though, I realized what was at issue: the art team was insisting that the UI for this feature have rounded corners. Incredibly, they were willing to bring the company to a standstill to protest that this was an absolutely essential feature. Even more surprisingly, the engineering team was equally vocal about their contention that adding rounded corners would add weeks of development time to the project, which would have pushed it out way past its hard deadline, effectively killing it. On the surface, this was a ludicrous dispute – both sides were willing to kill the project rather than proceed with (or without) a minor UI tweak. Were they just crazy?
Another great quote, illustrating how to fix the problem, by forcing the Cowboy and the Farmer to be Friends:
The solution to this problem is actually really simple. Just create an art path team, composed of some artists and engineers. Force them to live and work in the same physical space, force the engineers to actually do some art production, and force the artists to actually learn what the technical limits of the tools are. As the team gets traction, simply rotate members from both departments through this team, so that the knowledge they gain is eventually diffused through both organizations. And hold the leaders of that team – artists and engineers alike – accountable for a set of clear goals for the tools that are important to the company.
And this “Conway’s Law” post makes it clear what happens when you set things up with people in silos and a waterfall-style development: The structure of the software you produce will be reflection of your internal team structure. Design images the structure of the design group. Building websites in silos results in “silo” websites – lacking usability, durability, with poor connection between components. Unsustainable team structure results in unsustainable design. A great paper from the late 1960s with very modern conclusions.