Alright, so. I’m biased. Most of my projects have been more development-heavy than design, and I have worked with developers more.
But I also feel that I have given designers a fair shake – on various occasions, in various contexts – and I just keep seeing the same issues pop up. Things that I very rarely see with developers because, so it seems, developers work with a different set of fundamental bylaws.
Using the work of those before you rather than reinventing the wheel.
It’s a very rare circumstance that a developer inherits a body of code and immediately insists on a complete overhaul. (In fact, in the rare situations where the developer feels that doing so is unavoidable in order to meet the project objectives, he first consults with about half a dozen other developers to confirm this position, and then approaches the client with an almost apologetic air.)
Developers will almost always err on the side of using the foundation laid by those before them. That’s not to say that they won’t trash-talk the code, find fault in the code, refactor the code, or otherwise think it could be better, because they definitely do. But they do it all with a degree of respect for the craft of coding and creating good code, not because they feel compelled to code it all themselves.
I have found that the opposite is true with designers, many of whom insist on starting from scratch. (I’m being conservative here with “many” – all of the designers I myself have worked with have done this.) They come in, you give them a stack of Photoshop files and Powerpoints completed by designers before them, and they’ll instead spend time re-documenting a lot of it. Almost like they have to go through the exercise themselves in order to do the work. (And, if that’s the case – if research artifacts are valuable mostly to the designer who made them – then maybe that’s who should absorb the cost.)
Actually talking to people.
And show your work.
Many clients’ number one complaint about designers is that they meet with the designer once and then don’t hear from them for weeks, during which they seem to be “off in a corner art’ing.”
Nobody likes this. Everybody wants to know what’s going on, especially when they’re eager to see if your interpretation of what you heard is what they meant.
This is a lot easier, of course, if you’re working closely with the extended team.
Two concepts: open source and pair programming.
The beautiful thing about open source is that anybody – anybody – can play. No single person consistently has the best ideas, and even those who do are even better at hearing out others. Everyone works together to progress the program. Even if they’re not contributing to open source, devs are pulling from it, using pieces of code as solutions in other places, still acting as active participants in the hive.
And then there’s pair programming. While not all development is done with pair programming – I’m not even sure all developers have done it at all – that doesn’t change the fact that it’s a real thing.
Designers do, of course, talk to each other. And probably even collaborate on their designs. But I’m not sure they collaborate with the intensity that devs do.
“Egolessness” is upheld as one of the highest virtues in managing open source, and developers – particularly those running the program – take more pride in the ecosystem overall than they do in their individual contributions.
I’m almost positive that no designers have earned the “egoless” badge.
Most developers don’t really like to create documentation. Designers, on the other hand, seem to live for it.
Both development and design are a creative process. So how come they define “doing” so differently?
I think some of this has to do with insecurity over the finished product that each feels he or she can “sign their name to.” The developer can easily point to the software and say “I built this.” The designer, on the other hand, is perhaps at risk of feeling as though he can’t.
There are two primary audiences for the designer’s project work: either a.) upper management (their sign-off and/or our show-off) or b.) the development team, who only need enough to have or recall a dialogue.
More often than not, designers create artifacts better suited to the first objective when they’re actually supposed to be doing the second. It’s the rare occasion when we’re doing formal presentations, and a designer’s primary job on lean teams is not to create pretty psds, but to create the Minimum Viable Visual – enough to a.) start a discussion (hint: whiteboard) or b.) keep it going afterwards.
The goal here is to assure the designer that his work is every bit the software. And the process of building it…
Iterations. Early releases. Frequent releases.
My teams run lean.
We value dialogue over documentation and people over process. We do not pride ourselves on persnickety project plans or detailed scopes, and we create diagrams only to the extent that they are needed as conversation tools. Nothing is done simply for the sake of doing it.
I set the same expectations with designers on my team.
If it takes a designer longer to propose or iterate a design than it would take the developer to just mock it, we’ve got a problem.
Lean teams are collaborative, iterative, and dialogue-driven. Nothing is final until it’s shipped, and nothing should be treated as such. Everything until then is part of the dialogue. All of it is one on-going trajectory, not a series of steps and gates, and the work should neither be formalized prematurely nor drawn out over time.
Being realistic. (It has to actually work.)
The only thing that frustrates a developer more than being blocked on designs is getting designs that aren’t actionable. There is a special place in hell for those who hand over designs that are little more than sparkle garbage, where the flow comes out of nowhere and developing against them would necessitate breaking the existing architecture – or the entire known universe of architecture overall. (“What? Can’t you do that?”)
Development is fundamentally tethered to reality. Devs can’t just type monkey jibber-jabber into the source code, commit it, and expect it to run successfully. They have to play by the rules to make it actually work in the real world.
Designers aren’t automatically held to the same standards. They could, in theory, put whatever they want on paper and hand it off as their final product. They can dream up fantasy lands where anything’s possible. Everything’s made up and the points don’t matter.
But developers know that anything’s not, and while most developers love making cool stuff, they also know that doing so depends on a strong line of communication (and a check) between designs and dev. Without it, there ends up being an awkward gap in perspective.
Throwing work away.
I don’t know any developers who think their code is “one and done,” who believe that they can commit once and then never have to touch it again. They don’t release code and then sit on it, marveling and in awe of their own expertise. On the contrary, many, many developers often trip upon their own code years – even months – later and find themselves aghast at it, eager to dig into some rework. And to throw the original away. (Or comment it out. Just in case. Whatever.)
The world of development is built on a flow of knowledge and encourages rework. Code is seen as a living and breathing thing, worthy of evolution, even if only ad hoc.
Of course designers do rework, too. They definitely update their ideas and I’m sure many go through several drafts of each design. But I still think that each draft is done with some pain; they’re always yearning to call it final and tuck it into some curio cabinet, proudly labeled “My Designs!”
Part of the problem with designers’ reluctance to relinquish their work is probably really an anxiety of losing control. Unlike development, designs are readily accessible to anybody interested in looking, and probably invite a lot of “noise” in terms of feedback. It wouldn’t be at all unsurprising if a designer adopted an air of “protectiveness” in response to this.
The real solution, however, rather than shielding and safeguarding the work, is to build a skill in having these conversations…
Being good at your craft isn’t enough.
Just because you’re good with users doesn’t mean you’re good with people.
And if you want more meaningful work, you should aim to build more meaningful relationships with people. That’s not to say that designers are all bad collaborators, but I’ve met a lot of them who think doing design work for clients just involves knowing how to design.
Rapport and relationships are the most important part of working with others, and the foundation of all partnerships, which themselves are the foundation of most meaningful work. Partnerships foster cool programs.
And if you’re looking for meaningful partnerships, it’s not appropriate to go into them with “because I’m the expert, that’s why!” or “because this is just how it’s done!” stances. Months – years even – are invested in building enough trust with clients to convince them to try things (that benefit their product.)
I once spent six months building rapport and trust with a client before they felt comfortable bringing in a UXer (who then promptly compromised that rapport by refusing to honor the dynamic the team had established.) I know another guy who invested over a year. And a developer who waited two for a chance to implement some of his ideas.
Feeling secure in the fact that other know you’re better at your craft than we are.
We work with designers because they are the experts, not us. And when it comes to design and all of the magic that comes with it when it’s done well, they’re the ones who can make it happen.
We know that. And rest assured: we still love you.