Ben Shoemate's Notebook

 Â

No man is an island entire of itself; every man is a piece of the continent, a part of the main…

– John Donne

If you’ve ever worked at a company of any size, you’ve experienced it. Isolation. That feeling of being utterly alone in what you do.

Some people love it: the determination that comes from being a lone ranger, boldly going where no one has gone before. Others hate it: the despair that comes from slaving over a design only to see it disappear down a black hole of development, whereupon it emerges onto a website months later, unrecognizable from the pixels you put on the page with such painful precision.

Image credit: Ibrahim Iujaz

These are the perils of working in siloed environments, and it’s where many of us find ourselves today. We’re either terribly alone or terribly frustrated, depending on the particular variety of silo we find ourselves in. In this two-part series, I’ll explore the consequences of working in isolated environments, and how we can solve this problem by encouraging more collaborative cultures.

What Exactly Are We Talking About Here?

Silos in work environments usually come in two flavors:

1. Lonely silos
   Lonely silos are made up of workers with no real connection to the outside world. This often happens at start-ups where the focus is more on getting something out the door than on doing it right. I mean, who has time for proper UX design when “we’re building [technology x] because [company y] hasn’t built it and [people z] need it?” (as Kyle Neath recently put it).
2. Functional silos
   Functional silos feature workers who may be part of fantastic design teams. They have great whiteboard sessions, help each other out, enjoy their pizza Fridays… And yet, they have no real seat at the table when it comes to business strategy. Design happens painfully slow because it has to be signed off by 10 different people. And even then, there’s no guarantee that anything will be implemented the way the designers envisioned it.

Working in lonely silos and functional silos have two main consequences, both devastating to software development:

1. No process
   This usually happens in lonely silos. It’s everyone for themselves. The company subscribes to the “release early, release often” approach, and so you won’t get bogged down with a formal development process, guidelines for functional specs or any of the stuff that big lame corporations busy themselves with.
2. Too much process
   This usually occurs when functional silos get out of control. Organizations resort to putting hierarchies and processes in place to stop the “cowboy coding” madness. The science:art ratio in design shifts way too much to one side or the other. Functional specifications move into Microsoft Word templates that are 20 pages long before a single word of content is written. And sure enough, the cowboy madness stops. But it gets replaced with a different kind of madness: stagnation.

The Consequences Of Not Following A Design Or Development Process

When you work in an environment where silos result in no clear design or development process, the following often happens.

1. MVP Madness

We all know the concept of “Minimum Viable Product,” but revisiting Eric Reis’ definition would be useful:

The minimum viable product is that product which has just those features (and no more) that allow you to ship a product that resonates with early adopters; some of whom will pay you money or give you feedback.

Problem is, that last section of the definition often gets ignored. You know, the part about people paying you money. So this MVP idea can be taken too far, and a product can be released before there is a minimum viable understanding of what the thing is supposed to do (or who it’s supposed to be useful for). You could argue that the Color app is an example of this MVP madness (“It’s a photo app!” “No, it’s a data-mining app!” “Actually, it’s a local group-messaging search/recommendations app!”)

Perhaps the best example of this culture is the Lifepath sign-up page, which Dustin Curtis recently put up in what I’d like to believe is a deliberate and very effective attempt at MVP irony:

Lifepath sign-up page

A lot of this problem would go away if we evolve MVP thinking into what Andrew Chen calls “Minimum Desirable Product”:

Minimum Desirable Product is the simplest experience necessary to prove out a high-value, satisfying product experience for users.

I think that definition would send a lot of MVPs back to the drawing board, and rightfully so.

2. No Significant Design Focus

The second consequence of a lack of process, particularly in start-ups, is that design is often the last thing on people’s minds. I recently heard an interview with a start-up founder who gave the following overview of their staff: “We have 13 employees: 9 software developers, 2 sales people, 1 operations manager and a social media conversationalist.”

The company hired a social media conversationalist before it hired a designer. In this type of no-process world, ideas go from vision to code (and users) in one easy step, bypassing the principles of user-centered design completely. As Erika Hall puts it:

The floor of Silicon Valley is littered with the crumbling husks of great ideas — useful products and services that died in the shell before they hatched out of their impenetrable engineering-specified interfaces.

3. Endless Cycles

A third consequence of no-process development is that you never really know when you’re done. Not to make this about methodology, but this is one area where the “definition of done” concept in Scrum is extremely useful. If you don’t know when you’re ready to push something live, then the problems of MVP madness and lack of design are exacerbated.

Google Wave is a case in point. Listen to Douwe Osinga as he gives two good examples of MVPs done right before moving on to the problem with Google Wave:

Thinking big sounds great, but most big ideas start small and go from there. Google itself started from the notion that it would be interesting to look at back links for pages. Twitter started out as hardly more than a group SMS product that also works online. Facebook explicitly restricted themselves at first to one university.

Wave is a case in point. Wave started with some fairly easy to understand ideas about online collaboration and communication. But in order to make it more general and universal, more ideas were added until the entire thing could only be explained in a 90 minute mind blowing demo that left people speechless but a little later wondering what the hell this was for.

The Consequences Of Having Too Much Design/Development Process

So that’s what can happen in a no-process environment. But what happens at the other end of the continuum, where process is king of the world?

1. Org-Structure Design

When you can sketch out an organization’s structure by looking at its home page, chances are it’s hopelessly lost in functional silos. I experienced this first-hand while working at eBay. I would sometimes run into the product manager for the home page in the morning, and he’d have no idea why his page looked the way it did on that particular day. Each day was an adventure to see what had changed on the page that he “owned.”

Don’t believe me? Below is an example of the eBay home page from about a year ago, with the teams responsible for each section of the page overlaid (they’ve since gone through a redesign that fixed this issue):

This is unfortunately one of the side effects of functional silos. You run the risk of losing any sense of holistic design direction on the website.

2. Design Monkeys

Another consequence of an over-reliance on process is that designers could become nothing more than monkeys, cranking out efficient, perfectly grid-aligned but completely uninspired designs on an assembly line. Wondering whether this is you? Here are some instructions you might recognize as a design monkey:

Don’t get me wrong: I believe in style guides, and I believe in design constraints. But when an organization becomes overly reliant on design rules, creativity is often the first thing out the door. Yes, design is much more than art (we’ll come back to this later), but it’s certainly not pure science either. Without the right injection of art and creativity, science gets boring and forgotten pretty quickly.

3. Tired Developers

Once process takes over an organization, the acronyms start. And arguably, the most feared of them all is PRD: the product requirements document. This usually takes the form of a Word template, with a two-page table of contents. It includes a solution to every single eventuality the software might ever encounter. It sucks the soul out of product managers and the life out of developers.

To use another example from eBay, we once had a 23-page PRD to make some changes to our SiteCatalyst JavaScript implementation. And then the project didn’t happen. I shudder to think about the hours and hours of lost productivity that went into creating this document that never got used. People could have created things during that time. Instead, they sat in Microsoft Word.

The result? Tired developers. Developers who don’t want to code anymore because coding becomes 70% deciphering Word documents, 20% going back and forth on things that aren’t clear, and 10% actually coding.

How do you know that your developers are tired? Charles Miller’s explanation of what it means when a developer tells you that something is “non-trivial” sums it up pretty well:

It means impossible. Since no engineer is going to admit something is impossible, they use this word instead. When an engineer says something is “non-trivial,” it’s the equivalent of an airline pilot calmly telling you that you might encounter “just a bit of turbulence” as he flies you into a cat 5 hurricane.

Tired developers use the word “non-trivial,” or some variation thereof, a lot more than energized developers.

4. Distrust Between Teams

When people don’t live and breathe each other’s workflows, understanding the decisions they make is hard. And if you don’t understand the reason for someone’s decisions, distrust can creep in.

Functional silos that rely on too much process serve as fertile ground for distrust in relationships. A reliance on process can instill a false sense of security and the mistaken assumption that conversation and understanding are less important than proper documentation. This is particularly true in the complicated relationship between designers and developers. As Don Norman recently put it:

Designers evoke great delight in their work. Engineers provide utilitarian value. My original training was that of an engineer and I, too, produce practical, usable things. The problem is that the very practical, functional things I produce are also boring and ugly. Good designers would never allow boring and ugly to describe their work: they strive to produce delight. But sometimes that delightful result is not very practical, difficult to use and not completely functional. Practical versus delightful: Which do you prefer?

So, when designers and developers are not in the same room from the moment a project kicks off, or when design becomes prescriptive before thorough discussion has taken place and everyone has sweated the details together, the stage is set for the two worlds to collide. Breaking down these silos is the only way to design solutions that are practical and delightful.

5. Design by Committee

Not everyone can code, so they don’t go to developers telling them that their HTML needs to be more semantic. But everyone thinks they’re a designer, or at least has a gut feeling about design. They like certain colors or certain styles, and some people just really hate yellow. Because everyone has an emotional response to design and believes “it’s just like art,” they think they know enough about design to turn those personal preferences into feedback.

One of the first things we need to do to solve this problem is to teach people how to give better design feedback. Mike Monteiro gets to the crux of the issue in “Giving Better Design Feedback”:

First rule of design feedback: what you’re looking at is not art. It’s not even close. It’s a business tool in the making and should be looked at objectively like any other business tool you work with. The right question is not, “Do I like it?” but “Does this meet our goals?” If it’s blue, don’t ask yourself whether you like blue. Ask yourself if blue is going to help you sell sprockets. Better yet: ask your design team. You just wrote your first feedback question.

And how do we respond practically to the problems of design by committee? Smashing Magazine’s own article sums it up best:

The sensible answer is to listen, absorb, discuss, be able to defend any design decision with clarity and reason, know when to pick your battles and know when to let go.

Here are four principles I use in my day-to-day work to make that statement a reality:

1. Respond to every piece of feedback.
   This is tiring, but essential. Regardless of how helpful it is, if someone took the time to give you feedback on a design, you need to respond to it.
2. Note what feedback is being incorporated.
   Be open to good feedback. Don’t let pride get in the way of a design improvement. And let the person know what feedback is being incorporated.
3. Explain why feedback is not being taken.
   If a particular piece of feedback is not being implemented, don’t just ignore it. Let the person know that you’ve thought about it, and explain the reason for not incorporating that feedback. They will be less likely to get upset at you if you explain clearly why you’re taking the direction you’re taking. And if you’re not sure how to defend the decision…
4. Use the user experience validation stack.
   Read the post “Winning a User Experience Debate” for more detail. But in short, first try to defend a decision based on user evidence — actual user testing on the product. If that’s not available, go to Google and find user research that backs up the decision. In the absence of that, go back to design theory to explain your direction.

Summary, And Where We Go From Here

Ending an article on such a doom-and-gloom note feels a bit wrong. But maybe pausing here would be good so that we can all reflect on the issues that siloed development creates in our own organizations. As UX people, we’re taught to understand the problem first before trying to solve it, right? So, let’s do that. Did I miss any consequences? Anything you’d like to add or challenge about the consequences I’ve highlighted in this article?

In part 2, I’ll explain my own journey with siloed development and go over some of the guidelines we’ve implemented to break down these silos and build collaborative teams that help eliminate the vast majority of the issues outlined in this post.

(al)

---

© Rian van der Merwe for Smashing Magazine, 2011.