BlogmyQuery – BMQ

I spend a lot of time buying and testing iPad apps for kids. To be more specific, I lovingly do this for a certain two-year-old girl who is currently on a very successful #OccupyiPad mission in my house. Through extensive observational research, I’ve discovered what works and doesn’t work for my daughter, so I’m going to shamelessly generalize my findings to all children and propose four essential guidelines for developers who work on iPad apps for children.

Affordance Is King

Most apps for children show a bunch of different things on the screen that you can touch to make stuff happen. Cows moo, windows open and close, honey pots need to be collected, etc. But most of these apps give no indication of which elements are interactive and which are not. This usually results in a frantic and frustrating game of whack-a-mole to find the elements that actually do something.

The solution is simple: affordance. Give the elements in question a characteristic that indicates they are touchable. The Disney Puzzle Book apps do this really well. For example, in the Winnie the Pooh Puzzle Book app, the honey pots wiggle around to show the user that they need to touch them in order to collect them.

Pagination Is A Primary Action

Pagination is so important to the enjoyment of most children’s apps, but it is often a quagmire. Almost every app does this differently. The most common methods of pagination are touch-based arrows and swipe-based gestures (indicated by a skeuomorphic curled-up page corner). Both of these interactions are valid solutions, but because swipes can be tricky for tiny fingers and the gestures usually require some precision, the arrow approach is much better for kids.

Also, the entire bottom part of the screen is a hot area and needs to be avoided. Kids constantly touch that part of the tablet by accident, which makes accidental pagination inevitable if the controls are placed there. I like how the Old MacDonald app implements pagination: clearly marked forward and backward arrows at the top of the screen.

The Menu Is A Distant Secondary Action

Speaking of the bottom part of the screen: don’t put any interactive elements in the bottom part of the screen — especially menu actions, which are not important anyway once a child gets going with the app. The number of times I’ve had to stop the car to dismiss a random menu brought on by an accidental touch… well, it’s dangerous. The Mickey Mouse Puzzle Book app is a good example of this frustrating practice:

PlayTales has a clever implementation of the menu action in many of its books. First, the menu button is placed in the top-right corner, out of accidental reach (although the top middle would be better, in keeping with the top-left and top-right pagination mentioned in the previous point).

More importantly, it uses a two-touch method to bring up the menu. The menu icon is semi-transparent in its normal state. One tap removes the transparency, and a second tap brings up the menu. Although not foolproof, it’s an excellent way to avoid accidental taps.

If You Try To Trick My Kid Into Buying Stuff, You’re Dead To Me

I’m looking at you, Talking Tom Cat. A lot of apps do this, but Talking Tom Cat is the absolute worst. The screen is a landmine of carefully placed icons that lead to accidental purchases — not to mention the random animated banner ads that are designed to draw attention away from the app itself. GoDaddy’s dark patterns that try to trick users into buying more domains are one thing, but if you try to use persuasive design on my young daughter, all bets are off. Your app will be deleted, and we’ll never do business again.

Conclusion

Designing apps for children is extremely hard. Not only is quality, age-appropriate content hard to create, but designing the flow and interaction of these apps is made more difficult because designers must refrain from implementing advanced gestures, which would only confuse and frustrate kids (and, by extension, their parents). Yet all apps can and should adhere to certain basics. Hopefully, the four guidelines discussed here can become fixtures of all children’s apps.

(al)

© Rian van der Merwe for Smashing Magazine, 2012.

Have you ever looked at a bizarre building design and wondered, “What were the architects thinking?� Or have you simply felt frustrated by a building that made you uncomfortable, or felt anger when a beautiful old building was razed and replaced with a contemporary eyesore? You might be forgiven for thinking “these architects must be blind!� New research shows that in a real sense, you might actually be right.

That’s Michael Mehaffy and Nikos A. Salingaros describing a phenomenon we’re all familiar with, in their article “Architectural Myopia: Designing for Industry, Not People.� As I read the article, I became increasingly uncomfortable as I realized that the whole thing might as well have been written about Web design (and about our responses to the designs of our peers). How often do we look at a website or app and remark to ourselves (and on Twitter) that “these designers must have been blind!� Sometimes we’re just being whiney about minute details (as we should be), but other times we do have a point: “What were they thinking?�

Longaberger Home Office, Newark, Ohio. Image source.

In this article, we’ll discuss “designer myopia�: the all-too-common phenomenon whereby, despite our best intentions, we sometimes design with a nearsightedness that results in websites and applications that please ourselves and impress our peers but don’t meet user and business goals. With Mehaffy and Salingaros’s article as our guide, we’ll investigate the causes of designer myopia, and then explore some solutions to help us take the focus off ourselves and back on the people we’re designing for.

The Causes Of Designer Myopia

If the language in the opening paragraph sounds familiar, it’s because most of us privately and publicly mutter “What were they thinking?â€� almost every day as we move across the Web. We analyze the new Twitter app; we take it upon ourselves to redesign popular websites — and then we wonder if we should even be doing that. One thing is clear, though: we’re good at pointing out designer myopia in our peers.

But what are the causes of this lack of imagination and foresight in our work? Shouldn’t we be smart enough to avoid the obvious traps of designing too much from our own viewpoints and not taking the wider user context in mind? Well, it turns out that we quite literally see the world very differently than others. Again, from “Architectural Myopia�:

Instead of a contextual world of harmonious geometric relationships and connectedness, architects tend to see a world of objects set apart from their contexts, with distinctive, attention-getting qualities.

In other words, we see typography and rounded corners where normal people just see websites to get stuff done on. We see individual shapes and colors and layout where our users just see a page on the Internet. Put another way, we’re unable to see the forest for the trees.

How did we get here? Notice the striking resemblance to Web design as Mehaffy and Salingaros describe the slippery slope that has led to this state in architecture:

With the coming of the industrial revolution, and its emphasis on interchangeable parts, the traditional conception of architecture that was adaptive to context began to change. A building became an interchangeable industrial design product, conveying an image, and it mattered a great deal how attention-getting that image was. The building itself became a kind of advertisement for the client company and for the architect (and in the case of residences, for the homeowner seeking a status symbol). The context was at best a side issue, and at worst a distraction, from the visual excitement generated by the object.

This is why we often see designs that seem to be built for Dribbble, portfolios and “7 Jaw-Dropping Minimalist Designs� blog posts, instead of being “adaptive to context� based on user needs. We have gained much from the “industrialization� of design through UI component libraries and established patterns, but we’ve also lost some of the unique context-based thinking that should go into solving every design problem.

Jon Tan touches on this in “Taxidermista,� his excellent essay on design galleries in the first issue of The Manual:

Galleries do not bear sole responsibility for how design is commissioned. However, they do encourage clients and designers to value style more than process. They do promote transient fashion over fit and make trends of movements such as minimalism or styles like grunge or the ubiquitous Apple-inspired aesthetic.

The result of all of this is that we sometimes end up designing primarily for ourselves and our close-knit community. Jeffrey Goldberg reminds us that this is true for much of the technology industry in “Convenience Is Security�:

Security systems (well, the good ones anyway) are designed by people who fully understand the reasons behind the rules. The problem is that they try to design things for people like themselves — people who thoroughly understand the reasons. Thus we are left with products that only work well for people who have a deep understanding of the system and its components.

And so we end up with a proliferation of beautiful websites and applications that only we find usable.

We all follow some rules of thumb without understanding the reasons behind them.

We can’t talk about designing primarily for the community without bringing up the awkward point that we often do it deliberately. We thrive on the social validation that comes from positive Twitter comments, being featured in design galleries and getting a gazillion Dribbble likes. And let’s be honest: that validation also helps us get more clients. This is just part of human nature, and not necessarily a bad thing. But it can be a bad thing; so at the very least, we need to call it out as another possible cause for designer myopia so that we can be conscious of it.

The Manual brings clarity to the ‘why’ of Web design, and much more.

Oh, and while we’re at it, let’s ask the obvious next question. Why are we so good at noticing when others fall into the myopia trap but fail to catch ourselves when we do it? In “Why We’re Better at Predicting Other People’s Behaviour Than Our Own,� Christian Jarrett reports on some recent research that might provide the answer:

[When] predicting our own behaviour, we fail to take the influence of the situation into account. By contrast, when predicting the behaviour of others, we correctly factor in the influence of the circumstances. This means that we’re instinctually good social psychologists but at the same time we’re poor self-psychologists.

In other words, we’re much better at taking the entire context into consideration when looking at other people’s designs than when we are creating our own. Scary stuff.

So, if designer myopia is indeed a pervasive problem (and if we are not good at recognizing it in ourselves), what do we do to fix it? I’d like to propose some established but often-ignored techniques to get us out of this dilemma.

1. Conduct Observational User Research In Context

The first thing that Mehaffy and Salingaros suggest in their article to overcome myopia is this:

First of all, re-integrate the needs of human beings, their sensory experience of the world, and their participation into the process of designing buildings. Leading design theory today advocates “co-design,� in which the users become part of the design team, and guide it through the evolutionary adaptations to make a more successful, optimal kind of design. Architects spend more time talking to their users, sharing their perception and understanding their needs: not just the architect’s selfish need for artistic self-expression, or worse, his/her need to impress other architects and elite connoisseur-critics.

Note that this is not just about asking users what they think. It’s about making users part of the design process in a helpful, methodologically sound manner. To accomplish this, we can look to anthropology to play a substantial role in the design of products and experiences. Ethnography (often called contextual inquiry in the user-centered design world) is the single best way to uncover unmet needs and make sure we are solving the right problems for our users.

In “Using Ethnography to Improve User Experience,� Bonny Colville Hyde describes ethnography as follows:

Ethnographers observe, participate and interview groups of people in their natural environments and devise theories based on analysis of their observations and experiences. This contrasts with other forms of research that generally set out to prove or disprove a theory.

That’s the core of it: we do ethnography to learn, not to confirm our beliefs. By using this method to understand the culture and real needs of our users, we’re able to design better user-centered solutions than would be possible if we relied only on existing UI patterns and some usability testing.

Leaving the office and spending time observing users in their own environments is the best way to understand how a product is really being used in the wild. It’s the most efficient way to get out of your own head.

2. Design To Blend In

Let’s stick with the architecture theme for a moment. The concept of “paving the cowpaths� is another effective way to look beyond ourselves and to design websites and applications that form part of our users’ landscapes (rather than break their mental models). In “Architecture, Urbanism, Design and Behaviour: A Brief Review,� Dan Lockton writes:

One emergent behavior-related concept arising from architecture and planning which has also found application in human-computer interaction is the idea of desire lines, desire paths or cowpaths. The usual current use of the term […] is to describe paths worn by pedestrians across spaces such as parks, between buildings or to avoid obstacles […] and which become self-reinforcing as subsequent generations of pedestrians follow what becomes an obvious path. […]

[T]here is potential for observing the formation of desire lines and then “codifying� them in order to provide paths that users actually need, rather than what is assumed they will need. In human-computer interaction, this principle has become known as “Pave the cowpaths�.

This is such an interesting perspective on user-centered design. By starting a design project with an explicit goal to “pave the cowpaths,� we will always be pulled back into a frame of mind that asks how the design can better blend in with our users’ lives and with what they already do online. The same questions will keep haunting us, and rightly so:

• Do we have analytics to back up this behavior?
• Are we sure this is what users naturally do on the website?
• We know that most users click on this navigation element to get things done. How do we make that behavior easier for them?

In the same paragraph in “Taxidermista,� Jon Tan also calls for us to step back and ask questions like these before starting to design:

The answers to a project’s questions may have something to do with fashion, but not often. Good design does not have a shelf life. The best web designers gently disregard issues of style at the start. They rewind their clients back to asking the right questions, so they can rewrite the brief and understand the objectives before they propose solutions.

By asking the right questions, we focus our effort on fitting into the ways that users move on the Web, as opposed to bending them to our will.

3. Triangulate Results

The two recommendations above are very specific, so I’d also like to make a more general point. There are, of course, several other user-research methodologies to help us get into the minds of users and bring them into the design process in a helpful, meaningful way. Methods such as concept testing, participatory design and, of course, usability testing all have their place. But the real power lies in using not just one or two of these methods, but three or more. This is where triangulation comes in:

Triangulation is a powerful technique that facilitates validation of data through cross verification from more than two sources. In particular, it refers to the application and combination of several research methodologies in the study of the same phenomenon.

Using multiple data sources — both qualitative and quantitative — is a great way to avoid any myopia traps along the way. In addition to (or instead of, depending on the project) the two methodologies covered above, you should use as many appropriate techniques as possible to help confirm your intuition and direction.

As Catriona Cornett points out in “Using Multiple Data Sources and Insights to Aid Design�:

When used correctly, data from multiple sources can allow us to better identify the context in which our designs live. It can help us validate our assumptions and approach design with confidence and not subjective opinion. This not only helps to create better design, but also helps us achieve that all-important buy-in from stakeholders. It’s easier to defend a design when you have deep, rich insights to back it up.

The first response I get when proposing triangulation (or sometimes even just one research method) is usually, “We don’t have time!â€� The good news is that this doesn’t have to slow you down — even an hour at a coffee shop observing real users with your product will shock you out of your myopia. The only thing that’s not an option is skipping research completely.

Summary

User research and the techniques discussed in this article aren’t new, but they’re usually left to specialist researchers to champion, or they’re swept under the rug because “We’re using established UI patterns on this one.� Hopefully, this article has shown that designer myopia is too common and too dangerous to ignore or to be left to specialist researchers to fix. Sure, user researchers are critical to ensuring that a proper methodology is followed, but we can all get out there and use the data and information available to us to make sure we don’t put too much of our own viewpoints into our designs.

Web design is personal — deeply personal. As Alex Charchar puts it in his gut-wrenching essay for The Manual:

I now know that it is through love and passion and happiness that anything of worth is brought into being. A fulfilled and accomplished life of good relationships and craftsmanship is how I will earn my keep.

I doubt that any of us would disagree with those words. Our best work happens when we throw ourselves wholeheartedly into it. But this outlook on life and design comes with its own dangers that we need to watch out for. And the biggest danger is in being unable to see beyond our own passion and taste and, with the best intentions, in failing to make the necessary connections with our users.

My hope for all of us is that the three simple guidelines discussed here — contextual user research, designing to blend in, and research triangulation — will enable us to keep the perspective we need as we throw everything we’ve got at the design problems that we have to solve every day.

(al) (il)

© Rian van der Merwe for Smashing Magazine, 2012.

There are many ways to skin a redesign (I think that’s how the saying goes). On a philosophical level, I agree with those who advocate for realigning, not redesigning, but these are mere words when you’re staring a design problem in the face with no idea where to start. This article came out of my own questions about how to make the realignment philosophy practical and apply it to my day-to-day work — especially when what’s needed is more than a few tweaks to the website here and there.

I propose an approach to redesign through realignment, by using a framework adapted from Edward Tufte’s principles on the visual display of quantitative information.

But first, a little context.

Redesign Through Realignment

Let’s recap the redesign versus realign argument. Here is Cameron Moll in “Good Designers Redesign, Great Designers Realign�:

The desire to redesign is aesthetic-driven, while the desire to realign is purpose-driven. One approach seeks merely to refresh, the other aims to fully reposition and may or may not include a full refresh.

A realignment can include a full refresh, but the starting point is not the visual layer. The starting point is an understanding of the website’s users and their objectives, of market trends and of brand strategy. These are the hard questions that guide a realignment — not a desire to try out some new fonts or see whether a +1 button would look good on the home page.

But surely a visual refresh can be beneficial, too? What’s the danger in giving users something new to look at? In an essay that builds on Cameron’s article, Francisco Inchauste sums up the problem as follows:

Great designers adjust an existing work with little disruption of the foundational design for a goal or purpose. The end result is a modification to the design that improves the user experience. Good designers, on the other hand, recreate existing work focusing on the aesthetic, with a misunderstood notion that it will always improve it. However, they end up disrupting and/or damaging the user’s experience, making no real impact with the effort.

The main problem with big redesigns, therefore, is that, even though objectively the UX might have been improved, users are often left confused about what has happened and are unable to find their way. In most cases, making “steady, relentless, incremental progress� on a website (to borrow a phrase of John Gruber) is much more desirable. With this approach, users are pulled gently into a better experience, as opposed to being thrown into the deep end and forced to sink or swim.

So, if we agree that a realignment is preferable to a redesign (and I’m sure we never will, but let’s assume we do for the sake of this article), a big question remains unanswered: What happens when a realignment requires major changes to the website? What happens when small tweaks aren’t enough, when a website’s UX is so far gone that you’re tempted to scrap everything and start over?

One way to go about it is to use a continual realignment process to redesign the website. Build a vision, and know where you’re going in the long term; but get there incrementally, not with a big-bang release. Remaining rooted in the realignment approach ensures that the focus remains purpose-driven, even if the process results in major visual changes. “That’s fine,� you say, “but how do you do it? Where do you begin with such a project?� Let’s now look at one possible approach to redesigning through realignment.

Edward Tufte And The Data-Ink Ratio

I’ve always been intrigued by Edward Tufte’s principles for visualizing large quantities of data. The Visual Display of Quantitative Information is one of my favorite books of all time. Recently, I’ve been wondering whether its principles could be applied to Web design and, specifically, the realignment process. The deeper I got into it, the more I realized that within Tufte’s principles lies a goldmine for people who make websites.

One of Tufte’s central principles in The Visual Display of Quantitative Information is what he calls data-ink:

Data-Ink is the non-erasable core of a graphic, the non-redundant ink arranged in response to variation in the numbers represented.

Before we unpack what this means for Web design, it’s important to note that Tufte’s work applies specifically to information graphics and the display of quantitative data, not to the design of graphical user interfaces. However, when carefully interpreted and applied to the field of Web design, the principles are extremely useful.

With that in mind, I propose the concept of data-pixels for the design of user interfaces to mirror Tufte’s data-ink for information graphics. In the context of Web design, we can then think of data-pixels as the simplest and most desirable path that a user can take through a flow (the “non-erasable core of an interfaceâ€�). It is what would remain in “focus modeâ€� — if nothing else existed on the screen, just the design elements that enable users to get from one screen to the next.

For example, on a payment screen, data-pixels would be the credit-card fields, text labels and “Pay nowâ€� button. Nothing else. This is obviously not possible — you need headers, payment summaries, tooltips, trust seals, etc. But the “core dataâ€� are the elements of the page that we cannot remove without the user getting stuck with no ability to recover.

From this irreducible point of the design, you can start to add other elements as necessary, and this is what Tufte’s work is all about. Much of what Tufte espouses is finding the right data-ink ratio (or what we’ll call data-pixel ratio) for quantitative data, so that the core data can shine through. He lays out five principles for data-ink. Here is an overview and how these principles can be adapted to redesign through realignment.

Principle 1: Above All Else, Show the Data

Data graphics should draw the viewer’s attention to the sense and substance of the data, not to something else.

– Edward Tufte, The Visual Display of Quantitative Information

During a realignment, we should be guided by the principle that every page should be focused on the core data and the primary task that users need to take in that particular flow. Anything else is noise and should be added only after very careful consideration.

Craig Mod has written a great article titled “The Shape of Our Future Book.� In it, he describes the “quiet confidence� that a Kindle has when it is woken from its sleep state (compared to the iPad in particular), and then he addresses the data-pixel issue as follows:

I think the same concept of “quiet confidence� can be applied to data. Namely, in designing user experiences, we need to produce data that doesn’t draw attention to itself explicitly as data.

This doesn’t mean that design has to be boring or that aesthetics are not important. It means that we need to be mindful that any layer of design we add to the core data has to serve a specific function and cannot distract from the data itself.

Image credit: Sarah Blake

Principle 2: Erase Non-Data Pixels, Within Reason

While it is true that these boring [pixels] sometimes help set the stage for the data action, it is surprising […] how often the [pixels] themselves can serve as their own stage.

– Edward Tufte, The Visual Display of Quantitative Information

Once the context for the realignment is set by the overarching principle of focusing on core data, it’s time to evaluate the design and start improving the data-pixel ratio.

The first step is to look for ways to erase non-data pixels — the parts of the design that don’t directly apply to the user’s primary task. Look for elements that cannot be connected to guiding a user to the desired outcome, such as:

• Colors that don’t support the visual hierarchy through contrast;
• Typefaces that draw attention to themselves for no good reason;
• Gratuitous imagery (stock photography in particular) that does nothing more than break up the page (consider using white space and proximity grouping to create natural breaks instead);
• Alignment, sizes and color contrast that draw unwanted attention (for example, indented paragraphs, large social-media icons, a bright ad that doesn’t fit the website’s visual style).

One website that could certainly benefit from the removal of non-data pixels is doHome. Notice the gratuitous reflection of the navigation menu, the unnecessary stock photography, and the fact that so little content on the page tells you what the website is about:

MailChimp does a good job of limiting the non-data pixels on its sign-up page. Clear language indicates what to do; large fields with top-aligned labels ensure that you complete the form quickly; some information is included about the plan you’re signing up for; and the button to sign up is big and high-contrast.

Squarespace’s sign-up page removes as much non-data pixels as possible to put all the focus on the task at hand. The background disappears as soon as you click the “Sign up� link, and you’re presented with the following zero-distraction form:

Google+ is another example of a design that employs minimal non-data pixels. As Oliver Reichenstein says:

It is extremely difficult to keep a complicated user interface so light, white and free of lines, boxes and ornaments. The content hierarchy is always clear, color definitions and consistent and clear without labeling them.

This list isn’t exhaustive, but it illustrates the purpose of the principle: to critically evaluate the visual elements in order to strip out what isn’t necessary.

Principle 3: Erase Redundant Data-Pixels, Within Reason

Gratuitous decoration and reinforcement of the data measures generate much redundant data-[pixels].

– Edward Tufte, The Visual Display of Quantitative Information

“Redundant data-pixels� refer to elements of the design that are repeated without good reason. Some examples:

• Rows of products in a table with an “Add to cartâ€� button next to each one.
  (Consider using check boxes, with one “Add to cart� button at the bottom.)
• Animation as a way to draw attention to an element.
  (Consider using high-contrast color and size instead.)
• “Are you sure you want to do this?â€� dialogs for simple tasks such as adding a product to a cart.
  (For potentially catastrophic actions, like deleting an account, this type of dialog is, of course, appropriate.)

Below is an example from the offline word, courtesy of Allan Kent. The chart shows the price of parking per hour. Surely a simple sign that reads “R10 per hour� would suffice?

Note the addition of “within reason� to each of the data-pixel principles. Tufte himself acknowledges that redundant pixels are sometimes necessary:

Redundancy, upon occasion, has its uses: giving a context and order to complexity, facilitating comparisons over various parts of the data, perhaps creating an aesthetic balance.

The exception, then, is when, in Tufte’s words again, “redundancy has a distinctly worthy purpose�. A “Pay now� button at the top and bottom of a check-out page could be an example of this. One of the buttons is redundant, yet it introduces efficiency so that users don’t have to scroll up or down to place their order.

The guiding principle here is to strive for a minimalist aesthetic, adding redundant pixels only when they serve a larger purpose (for example, when they’re essential to the brand’s promise or to user efficiency).

Principle 4: Maximize the Data-Pixel Ratio, Within Reason

Every [pixel] on a graphic requires a reason. And nearly always that reason should be that the [pixel] presents new information.

– Edward Tufte, The Visual Display of Quantitative Information

Once you’ve erased as many non-data pixels and redundant data pixels as possible, the next step is to figure out what (if anything) is missing from the design. The goal of this principle is to add more pixels to the design, if necessary.

There should always be a reason for adding elements to a design, and the reason will usually be that those elements provide information and/or functionality that increases usability. Some examples:

• Breadcrumbs that tell users where they are on the website and give them an easy way to get back to where they came from.
• An aesthetic layer of color, typography, layout and so on, to ensure consistency between brand perception and the website.
• Hover states or tooltips to provide appropriate guidance or contextual help to users.

An example of necessary pixels is relevant inline error messages. Consider the sign-up form on Quora below. Very few non-data pixels are on the page. The form’s layout is simple, with no extraneous decoration. But if you try to enter only your first name, the page instantly reminds you that a full name is required:

One could argue that this isn’t technically part of the “core data� of the design. Quora could have let this slide and either allowed accounts with first names only or sorted it out after users have signed up. But it has decided that data integrity is important from the start, so it has added this real-time check.

A little closer to home, this is what the header of kalahari.com (where I currently work) looked like when I started at the company:

Identifying the non-data pixels in this design is easy: very large radii on the rounded corners, color that grabs too much attention, too many unimportant links, etc. After maximizing the data-pixel ratio to put the focus on the core data (which is search), we ended up with this header:

Principle 5: Revise and Edit

Probably, indeed, the larger part of the labour of an author in composing his work is critical labour; the labour of sifting, combining, constructing, expunging, correcting, testing: this frightful toil is as much critical as creative.

– T.S. Eliot, Selected Essays, 1917–1932

Tufte quotes T.S. Eliot to describe the relentless effort of editing and revising in graphic design work, and it’s certainly true for Web design.

Once you’ve completed a cycle through these principles, it’s time to go back and start again. Every realignment cycle exposes new opportunities to “above all else, show the data�. UX is a never-ending cycle of improvement, and following a realignment process bakes this constant cycle into the strategy in a very natural way.

Summary

As I mentioned at the beginning of this article, there are many approaches to redesigning a website. The hardest part often is knowing how and where to start. As I’ve shown, Edward Tufte’s timeless principles for the visual display of data can be adjusted and used as a framework to get over that initial hump and serve as a catalyst for a cycle of continual improvement through realignment.

What other models or approaches are there to frame a realignment project? How do you get started?

Front page image source: Elliot Jay Stocks

(al)

© Rian van der Merwe for Smashing Magazine, 2011.

In part one of this series, we looked at the consequences of designing and developing software in isolated environments. Some people work in lonely silos where no process exists, while others work in functional silos where too much (or the wrong) process makes innovation and progress difficult.

So, how do we break down the artificial walls that keep us from creating great things together? How can organizations foster environments that encourage natural, unforced collaboration?

There are no quick fixes, but these are far from insurmountable problems. I propose the following five-level hierarchy as a solution:

There are no shortcuts to breaking down silos. You can’t fix the environment if the organization doesn’t understand the problem. You can’t improve the development process if the right environment doesn’t exist to enable healthy guidelines. You have to climb the pyramid brick by brick to the ultimate goal: better software through true collaboration.

Let’s look at each of these levels.

Level 1: Make Sure Everyone Understands The Problem

Photo credit: TransGriot

Most organizational leaders would probably admit that collaboration is not as good as it should be, but they might try to solve the problem incorrectly. As Louis Rosenfeld recently said in “The Metrics of In-Betweenness�:

Many senior leaders recognize the silo problem, but they solve it the wrong way: if one hierarchical approach to organizing their business doesn’t work, try another hierarchy. Don’t like the old silos? Create new ones. This dark tunnel leads to an even darker pit: the dreaded — and often horrifically ineffective — reorg.

The first level is admitting that there’s a problem and that the current problem-solving methods just aren’t working. This isn’t about moving branches of the organizational tree around. It’s about planting the tree in more fertile ground to establish the right foundation in order to start looking for solutions.

Level 2: Empower Teams To Do Great Work

Once the organization is united around a common understanding of the problem, then the starting point for breaking down silos is to take a healthy look at the culture and work environments. Above all, the needs of makers (such as designers and developers) should be taken seriously by managers (those who direct and enable the work). Mike Monteiro takes on this issue by attacking the calendar in “The Chokehold of Calendars�:

Meetings may be toxic, but calendars are the superfund sites that allow that toxicity to thrive. All calendars suck. And they all suck in the same way. Calendars are a record of interruptions. And quite often they’re a battlefield over who owns whose time.

Paul Graham takes a more holistic view in “Maker’s Schedule, Manager’s Schedule.â€� He explains that managers break their days up into hour-long stretches of time, while makers need large blocks of time in order to focus:

When you’re operating on the maker’s schedule, meetings are a disaster. A single meeting can blow a whole afternoon, by breaking it into two pieces, each too small to do anything hard in. Plus you have to remember to go to the meeting. That’s no problem for someone on the manager’s schedule. There’s always something coming on the next hour; the only question is what. But when someone on the maker’s schedule has a meeting, they have to think about it.

Makers need long stretches of uninterrupted time to get things done, and get them done well. Most siloed environments don’t support this because of an insatiable need for everyone to agree on everything (more on this later). So first, helping managers understand why this is such a big deal for makers is important, so that the managers can effect cultural change.

Michael Lopp talks about this in his article “Managing Nerds.� Substitute the word “nerds� in this article with “designers and developers� (no offense intended). Michael describes how nerds are forever chasing two highs.

The first high is unraveling the knot: that moment when they figure out how to solve a particular problem (“Finally, a simple way to get users through this flow.â€�). But the second high is more important. This is when “complete knot dominationâ€� takes place — when they step away from the 10 unraveled knots, understand what created the knots and set their minds to making sure the knots don’t happen again (“OK, let’s build a UI component that can be used whenever this situation occurs.â€�).

Chasing the Second High is where nerds earn their salary. If the First High is the joy of understanding, the Second High is the act of creation. If you want your nerd to rock your world by building something revolutionary, you want them chasing the Second High.

And the way to help designers and developers chase the second high is to “obsessively protect both their time and space�:

The almost-constant quest of the nerd is managing all the crap that is preventing us from entering the Zone as we search for the Highs.

So, how do you change a culture built around meetings and interruptions? How do you understand what designers and developers need in order to be effective, and how do you relentlessly protect them from distractions? Here are two ways to start:

1. Ask the makers what’s missing from their environment that would help them be more effective.
   Find out what your designers and developers need, and then make it happen. A quiet corner to work in? Sure. A bigger screen? Absolutely. No interruptions while the headphones are on? Totally fine. Whatever it takes to help them be as creative as possible and to be free to chase that second high.
2. Start working on a better meeting culture.
   This one is a constant struggle for organizations of all sizes, and there are many ways to address it. I try to adhere to two simple rules. First, a meeting has to produce something: a wireframe, a research plan, a technical design, a strategic decision to change the road map, etc. Secondly, no status meetings. That’s what Google Docs and wikis are for (agile standups are an exception to this, for reasons best left to a separate article).

Level 3: Create A Better Design And Development Lifecycle

Once a team is optimized for creativity, then it becomes possible to build appropriate guidelines around that culture to take an idea from vision to shipped product. This includes the development process as well as the prioritization of projects, so that you only work on things that are important.

The Design And Development Process

Formalizing the design and development process is so critical: from the identification of user, business and technical needs, to the UX design cycle, to technical design and, ultimately, to development, QA and launch. By formalizing this process based on a common understanding of the needs of the business, the team will have no excuse for skipping the UX phase of a project because “it would take too long.� By providing different scenarios for whatever timelines are available, the team ensures that design and UX always remain a part of the development lifecycle.

But one particular aspect of the development process has a direct impact on organizational silos: ensuring the right balance between design and engineering, and how designers and developers work together. This isn’t explored enough, yet it can have far-reaching implications on the quality of a product.

Thomas Petersen describes the ideal relationship between designers and developers in “Developers Are From Mars, Designers From Venus�:

They are the developers who can design enough to appreciate what good design can do for their product even if it sometimes means having to deviate from the framework and put a little extra effort into customizing certain functionality. If they are really good developers they will actually anticipate that they have to deal with it and either use a framework that allows them be more flexible or improve the framework they prefer to work in.

And they are the designers who learn how to think like a programmer when they design and develop an aesthetic that is better suited to deconstruction rather than composition. They know that composition in the Web world is not like composition in the print world and that what they are really doing is solving problems for customers, not manifestations of their creative ego.

Beyond the usual discussion of whether designers should be able to code, one of the main causes of bad blood between the groups is that developers are rarely asked what they need in order to write the best possible code. Designers should always ask their development teams two questions:

1. “How would you like to contribute to the product development process?�
   It is amazing how few people actually ask this question, as is how the opinions of the people who understand the product at its most detailed level often don’t have a voice in ideation or prioritization. Any cycle that doesn’t include developers from the beginning will likely fail, because the conflict between design and utility cannot be resolved with detailed specifications. It can be resolved only around a table, with plenty of paper to draw on and time to argue about the best way to do things. Of course, designers need time on their own to create, but developers need to be given a chance to contribute to the product that they’re building in a way they’re comfortable with.
2. “What information do you need to start coding?�
   The theoretical discussion about low-fidelity versus high-fidelity mock-ups or prototypes is largely misguided when it comes to real-world development. The goal is right-fidelity specifications, and that all depends on the maturity of the application you’re working on and the style of the developer. Some developers need perfect PSDs before they start coding; others are fine with back-of-the-napkin sketches along with a solid UI component library. Find out what they need, and provide just that — anything more than what they need will not get looked at, and that’s when tempers can really flare up.

Bringing such diverse worlds together is hard work. But, in “So Happy Together: Designers and Engineers,â€� Dave Gustafson warns what might happen if you don’t invest in this:

What’s the alternative to this kind of collaboration? Keeping design and engineering separate, where the pass-off from one to the other is aptly called “throwing it over the wall.� Designers may enjoy an unhindered blue-sky design process, but they’ll likely be disappointed with what actually gets made. Without engineers in the design process, there are bound to be some unrealistic features in the concept — and without an understanding of the designers’ intentions and priorities, engineers are likely to compromise the design with changes to meet cost goals. Some money may have been saved on the engineering and manufacturing — but not enough to offset a product that misses the mark.

The Prioritization Process

When there is no clear development process, “prioritization� can end up being a complex algorithm consisting of the last email request sent, the job title of the requestor, and proximity to the development team. This is no way to build a product. One way to address the difficulties of prioritization is through the concept of a “product council.�

At a start-up, the entire company could make up this group — even if it’s a group of one. In large companies, the group should include the CEO and the VPs of each department, including marketing, product, engineering, support, etc. The name is not important — the purpose is. The product council would have weekly or by-weekly meetings with two goals:

1. Review the current product road map to assess whether the right priorities are being addressed.
2. Introduce new ideas (if any) that have come up during the week and discuss business cases and priorities.

This meeting would have several very positive outcomes:

• It would give the management team complete insight into what the product or design team is working on, and would allow for anyone to make a case for a change in priorities. This eliminates the vast majority of the politics you see at many organizations, and it frees up the teams to do what they do best: execute.
• No one in the company would be able to go straight to a designer or developer to sneak things onto the road map. The user, technical or business impact of every big idea must be demonstrated.
• It would prevent scope creep. Nothing would be put on the road map without something else moving out or down. This is absolutely critical to the development cycle.

From there, projects would move to small dedicated teams, which would have complete ownership of the design and implementation. The product council sets the priorities, not the details of implementation — those are up to the teams themselves. I’m always reminded of what Jocelyn K. Glei says in her excellent article “What Motivates Us to Do Great Work?â€�:

For creative thinkers, [there are] three key motivators: autonomy (self-directed work), mastery (getting better at stuff), and purpose (serving a greater vision). All three are intrinsic motivators.… In short, give your team members what they need to thrive, and then get out of the way.

In pursuit of collaboration, we run the risk of overshooting our target and gaining the false sense of security that “consensus� brings. Consensus too often results in mediocre products, because no one really gets what they want, so the result is a giant compromise. Marty Cagan says this very well in his article “Consensus vs. Collaboration�:

In consensus cultures people are rarely excited or supportive. Mostly because they are very frustrated at how slow things move, how risk-averse the company is, how hard it is to make a decision, and especially how unimpressive the products are.

So, even though everyone agreeing on something is great, having someone be responsible for the decisions in that particular project is infinitely more important. This person does not do all the work, but rather is the one who owns the product’s fate — its successes and failures.

In many organizations, this person is the product manager, but it doesn’t have to be. Whoever it is, the role should be clearly defined and well communicated to the rest of the organization. The role is not that of a dictator, but of a diplomat, working with UX, business functions and engineering to build products that are driven by user, business and technology needs.

Level 4: Communicate Better

Once the appropriate guidelines are in place and the teams are working effectively, it’s time to root out any other causes of mistrust that might still exist. And one of the best ways to build trust in an organization is to eradicate secrets.

I am huge believer in full transparency, and I see little need in keeping any relevant information about a project from anyone. (The prerequisite? Hire trustworthy employees!)

If plans, progress and problems are published for all to see, there is no need to hide anything and no need to play politics to get things done. Here are just some of the things that should be published on a public wiki for anyone to view and comment on (written from the perspective of a UX team):

• Roles and responsibilities of the product and UX teams.
• How road-map planning and the prioritization process work.
• How the product development process works, including (critically) where UX fits into even the smallest projects.
• The goals and success metrics for every product line.

Publish everywhere, invite anyone. The tools at our disposal make this so easy, from Dropbox and Google Docs to ConceptShare and Campfire. There is no excuse for keeping things to ourselves.

Level 5: Prove That It Works

When the groundwork is laid for silos to start crumbling down, one last piece of dynamite will blow it all up: it’s time to start proving that it works. People will believe you for only so long if you say, “Trust me, this is the right thing to do!â€� At some point you have to show them the money.

A common theme throughout this series has been that better collaboration results in better software. The only way to cement these changes into the organizational culture is to show that you’re actually shipping a better product because of it.

Here’s what I do to demonstrate the business value of a collaborative development process that includes a tightly integrated UX cycle:

1. Share case studies from other companies or projects that clearly show the business benefits of working this way. Showing that it’s been successful elsewhere should buy enough time and resources for the team to put in place its plans to follow a proper collaborative design and development process in one or more of its projects.
2. Start on a project where changes can be measured by an improvement in one of the three A’s of revenue generation:
   • Acquisition
     Getting new users to sign up for your product.
   • Activation
     Getting those new users to make their first purchase.
   • Activity
     Getting those first-time purchasers to come back for more.
3. Benchmark well before the start of the project, and set clear goals to measure the success of the project.
4. Follow through on the commitment to collaboration, and measure your results. See “How to Measure the Effectiveness of Web Designs� for ideas on which measurement tools to use.
5. Publish your metrics widely so that everyone in the organization can see the results. And don’t hide the failures. There will be failures — the trick is to own those mistakes, learn from them and get better.

Summary (aka “Whose Job Is It, Anyway?�)

So, whose job is it to break down organizational silos and build a collaborative development process?

Guess what? It’s your job. Whether you’re a designer, developer or manager, this isn’t something that someone else will get around to — if it was, then it would have happened already. Building collaboration is best done through a groundswell in the organization, led by the makers, the people who build the actual product. It might be difficult, but I hope there are enough case studies and examples in this series to help you get started on this journey of organizational change.

Collaboration only works if everyone in the organization is open about their processes and workflows, without fear of being judged unfairly. Arguments over what’s right and how to do things differently will happen. And they should — it’s the only way to get better at what we do.

Building collaborative environments is not easy, because change management is not easy. But the positive outcomes of doing this far outweigh the pain of making it happen. You’ll end up with happy, creative teams that feel a sense of ownership over what they’re building and a sense of pride in its quality.

I often remind my team that we are judged on the products we ship, not on the number of times we ask for help along the way. So, what possible reason could there be not to collaborate and create a better product — because it will make us all look better in the end anyway? (Hint: there isn’t one.)

Go. Make it happen.

(al)

© Rian van der Merwe for Smashing Magazine, 2011.

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.