Your design review is going along swimmingly, you think things are going well. Everyone’s nodding and smiling, perhaps chiming in with the occasional improvement, and then suddenly—you see your developer frowning.
Next thing you know, seemingly at random, some part of your design is declared good but not workable, not impossible but not something that can be done, just basically not something that is going to fly.
Why?
“Because that would be a hack.”
Boom. You’re dead in the water, left guessing at, well, what isn’t a hack then? And does that matter? I mean, that would be bad right? But what about the user?
Should you care if something is a hack?
So let’s me just say, I officially don’t give a shit.
There. That felt good, didn’t it. Say it out loud with me.
It will help. I don’t give a shit!
OK, let’s take a step back now and admit that that’s not entirely true. I actually do care about maintainable code, software quality, good architecture, and the like.
But I only care about those things in service of one thing: the user.
(And by extension, the business that serves those users.)
If the code is maintainable, but doesn’t do anything useful, who gives a shit?
(No one.)
If you’ve made a quality piece of software that noone runs, how much difference does it make?
(None. If a tree falls in the forest…. Who cares.)
If your perfect, impeccable architecture doesn’t support what the business needs, is it really perfect or impeccable?
(No, it’s a failure.)
I also want to point out that I definitely want to work with smart, ambitious people that take pride in their craftsmanship. But let me ask you, does a chair have value if no one can sit in it? If it doesn’t hold weight?
To me, in this case, the answer is no. It may hold aesthetic value, or make an artistic statement. It holds educational value in that you may have learned something for the next chair. But is it well-crafted? By a professional? My answer would be no. If someone is employing you to build them a piece of software (or a chair) that helps people in the world and generates enough money for that business to continue to exist and employ people? Well, then you’ve signed on for a very specific purpose that is neither purely artistic or educational. It’s practical. It’s engineering.
“Perfect” software that doesn’t not meet user or business needs does not answer to this purpose. And therefore, it is not perfect.
Should I hold my horses?
Am I just a designer ranting at the development machine, not understanding? Not comprehending the technical world that is software engineering?
Let’s look at the first principle behind the Agile Manifesto:
“Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.”
HIGHEST priority. Customer. Valuable.
This is not about designers versus developers, heaven forbid. This is about being a considerate, self-aware human being that can see beyond our expertise and understand how it fits into the context of the world.
Excellent software is both elegant AND useful to people.
(There is no such thing as perfect software. Or perhaps anything for that matter.
Working with this type
When working with this type, you may want to more nicely make my argument above. You may want to dig in and have a technical argument with them, if you’re comfortable, about whether their ideas meet requirements or what quality attributes they’re really optimizing for.
Get them observing users and seeing how the software flies in front of them. If that’s not an option, you may need to make them endure long, dramatic stories on your part to try to dramatize the real world effects. Try establishing some red routes for your software, or building shared understanding of the user context through videos, personas, site visits, and any other techniques you have for building empathy with your customers and clients.
You may simply find yourself throwing up your hands, or pounding on the table. This situation enters directly into conflict more often than others. It’s one of the hardest situations for a designer to deal with, because the point of contention is within the developer’s sphere of control—a place most designers can not easily discuss or influence. In this case, you can consider involving people above you in the organization—other architects, product people, visionaries—or simply other developers they respect.
If you meet a solid, uncompromising wall too often, sometimes the only answer is to get out. Of the team, the division, the organization. The quality of the work will be affected, your work will be worse. If you aren’t proud of your work, or you can’t show the software to others as an example of your skill, then what exactly are you getting out of this, beyond a paycheck? Don’t let people waste your time or expertise. Don’t waste it yourself. Find the (many) people in the world who want and need your advice and will listen to it, and architect based on it. (Obviously, you may have other reasons to stay in a position. You may like the people, need the money, want to give them another chance. But don’t let inertia keep you in a position where you aren’t growing and aren’t being listened to. Don’t be a mascot or a rubber stamp, or something people can point to and say, “You’re wrong, it’s not hard to use. We talked to a DESIGNER.”)
Other common pitfalls
Tradeoffs are a part of making software. In spite of my diatribe above, sometimes we all have to make compromises. That’s part of working together as a team.
Sometimes a design is so counter to the thinking behind the architecture that it adds enormous cost to developing it. The best way to avoid this is to collaborate–at every step, early and often. Think you don’t care about that architecture meeting? Think again. Think you just want to get one more thing figured out before you show it to anyone? Might want to reconsider that….
Of course, sometimes we learn. We discover after the architecture is mostly done, that what we thought would be good actually isn’t. Sometimes we roll a 1. In this case, we as designers do have to accept that it may take time to rearchitect—time that the team might not have. Another, almost as good solution might be right around the corner, with similar cost. Or sometimes we have to accept an 80% solution, and get a plan in place to improve it.
Other times, it seems as though the architecture has been developed with strong assumptions completely counter to what was needed. Maybe people didn’t want to collaborate with you, or didn’t involve you in their decisions despite your congenial requests. Maybe noone told them what was needed, they didn’t ask, or it was reasonably misunderstood. These situations basically suck.
Don’t take the blame. Be clear on the business case, target user, and how the software should be serving them. Don’t let the sudden problem be pointed at only “your design” if the problem is actually the architecture, or most of the time more accurately, the unfortunate way the two things combine.
Watch out for bugs. In my experience, if you push hard and they do try to go forward with your design, it may go a bit sideways more often than not. Find ‘em and file ‘em, if you can.
Fight for the user. Don’t drop your flag. This may mean pushing for your design or for refactoring. It may mean getting creative to find something good that works within the insanity. Be careful that way, because while it’s important to compromise, it can get murky and unclear. How much compromise is too much? When does an 80% solution start to look like a 70% solution… and do you know when it goes from being tolerable, to just not good enough? It’s not a black and white line. But just from a practical perspective, sometimes you will go here. Using red routes as a framework can help to add clarity, but it’s hard road to walk.
Beware of false dichotomies. Sometimes good-for-the-user and good-for-the-code totally oppose each other. Sometimes we just imagine that they do.
People say Good, fast, cheap–pick two. Eric Reis points out in Lean Startup that this is not really true. Sometimes people get so caught up on this that product people don’t bother asking the developers if they good thing could possibly be fast and cheap too. One way that this happens is frameworks. Sometimes the commonly popular UIs for something are freely available for reuse. Or sometimes, simple experiences are also simpler to develop. In this case, you rolled high. Jackpot!
Do you have other advice for working with this type? Share your ideas in the comments!
