Category: Processes

Microsoft leads the way

On page 4 of this Vanity Fair article (can’t seem to direct link), Kurt Eichenwald outlines how Microsoft leads the way—in this case, the technology giant ably demonstrates how to destroy a culture of innovation within a business in one easy step.

At the center of the cultural problems was a management system called “stack ranking.” Every current and former Microsoft employee I interviewed—every one—cited stack ranking as the most destructive process inside of Microsoft, something that drove out untold numbers of employees. The system—also referred to as “the performance model,” “the bell curve,” or just “the employee review”—has, with certain variations over the years, worked like this: every unit was forced to declare a certain percentage of employees as top performers, then good performers, then average, then below average, then poor.

“If you were on a team of 10 people, you walked in the first day knowing that, no matter how good everyone was, two people were going to get a great review, seven were going to get mediocre reviews, and one was going to get a terrible review,” said a former software developer. “It leads to employees focusing on competing with each other rather than competing with other companies.”

Supposing Microsoft had managed to hire technology’s top players into a single unit before they made their names elsewhere—Steve Jobs of Apple, Mark Zuckerberg of Facebook, Larry Page of Google, Larry Ellison of Oracle, and Jeff Bezos of Amazon—regardless of performance, under one of the iterations of stack ranking, two of them would have to be rated as below average, with one deemed disastrous.

For that reason, executives said, a lot of Microsoft superstars did everything they could to avoid working alongside other top-notch developers, out of fear that they would be hurt in the rankings. And the reviews had real-world consequences: those at the top received bonuses and promotions; those at the bottom usually received no cash or were shown the door.

Wow.

Do go and read the rest: the further revelations about just how utterly insane this idea was—is?—are quite flabbergasting.

In the end, the stack-ranking system crippled the ability to innovate at Microsoft, executives said. “I wanted to build a team of people who would work together and whose only focus would be on making great software,” said Bill Hill, the former manager. “But you can’t do that at Microsoft.”

If you want to know why every “innovation” that has come out of Microsoft in the last decade or so has been an ignominious failure, then you need look no further.

Removing comps in web design

For a few years now, I have had the feeling that we are approaching web design in the wrong way. Many designers—and their clients—have made the transition from the medium of print, and transferred the design processes too.

In print, we were all used to producing proofs with millimetric—nay, pixel-perfect—precision because we had to: the high-resolution of print meant that that one pixel gap was obvious when the material came off the press.

But it made absolute sense to produce these proofs—or composites (“comps”)—because print is a fixed medium: what you see is, pretty much, what you get.

Building a nightmare that never stops

Hence the bane of the website builder’s job: a pixel-perfect Photoshop comp married—in Hell—with a customer who doesn’t understand that their website is never going to precisely match that beautiful image proof that they have signed off.

The web has always been a fundamentally fluid medium: in print, the amount of text was often governed by the size of the printed page—in web design, the very opposite is true.

And this point is compounded when designing for a content management system (CMS), where the designer could not—and should not—absolutely control how much text a user can insert.

The death of the static image comp in web design

As such, I really believe that we need to kill this idea of using static image comps in web design and, a few weeks ago, Brad Frost succinctly summed up why in a post entitled The Post-PSD Era

Throughout my career, I’ve watched immensely talented designers waste a shitload of time creating fully fleshed-out comps of what a website could look like. Pixels get pushed, details are sweated, pages are printed out, hung on walls, and presented to clients. Clients squawk their feedback, then designers act on it. They repeat this dance until everyone is content (or until nobody gives a shit anymore, which happens more often than you’d think).Only then do those pristine comps get handed (more like shoved) over to developers to build.

It’s an increasingly-pathetic process that makes less and less sense in this multi-device age.

As it happens, Brad wrote this post at roughly the same time as I was presenting a new design process to my fellow managers—and I found it when looking for some pithy comment with which to populate a slideshow presenting said process to the rest of the company.

Bringing it home

My company designs and implements websites on its own Content Management System (CMS). I have moved through different positions within the company over the last five years, but I was put in charge of the new Creative and User Experience Team in July.

In between delivering customer projects, I have been attempting to make our processes more efficient. It swiftly became obvious that there were a number of problems with the way in which we designed and build our websites and intranets.

Improving our process: driving efficiency

The first has been largely improved by the adoption of an increasingly robust CSS LESS framework.

The second, however, was more difficult to address—customers’ expectation that their websites would look precisely (yes, even in IE7) like the lovely images that they had signed off .

We were also duplicating work.

So, the first thing that we did was to push the responsibility for producing wireframes solely onto the Information Architects; wireframes were already an output of these workshops (driven largely by the Attention Mapping exercises), so duplicating this work seemed ridiculous.

Next, we created a selection of mood boards—with recognisable, non-techie names—which, combined with the wireframes, enabled our designers to get a very good idea of what the customers were aiming for.

Zombie comps that will not die

But, at the end, we were still producing fixed image comps that were taking too long to create and, importantly, amend. Customers were getting hung up on the positioning of elements when, in our CMS, you can place anything anywhere (just about).

So, in December, I my research turned up Samantha Warren’s styleti.es—a website dedicated to promoting the use of said Style Tiles.

Style Tiles are similar to the paint chips and fabric swatches an interior designer gets approval on before designing a room.
An interior designer doesn’t design three different rooms for a client at the first kick-off meeting, so why do Web designers design three different webpage mockups?

Style tiles are for when a moodboard is too vague and a comp is too literal. Style tiles establish a direct connection with actual interface elements without defining layout.

The sites and systems that we build are huge.

There is simply no way that we can proof up all of the pages that make up the tens of functional Modules that our customers may have bought.

Style Tiles and a way forward

As I saw it, Style Tiles—with a bit of modification—would enable our company to provide the important elements to our customers (the look of a menu system, how a Staff Directory entry might be displayed) without them getting hung up about where on the page these elements might appear.

After all, not only is the web a fluid medium but our CMS also gives the customer total control over their page structure.

With Style Tiles, clients could focus on the important details, rather than getting hung up on where those things appeared on a page. We would, in fact, be aligning our processes with the flexibility of our product and thus reinforcing its superiority.

There were, of course, other benefits, including being able to turn around work much more quickly and thus increase the productivity of the team.

It’s never enough…

But Style Tiles wouldn’t be enough—especially in the age of Responsive Design.

As such, we decided to build Live Prototypes alongside the Style Tiles. With our LESS framework (which has mobile @media break-points built in), and the CMS’s inbuilt styling options, this became a viable proposition.

The first run is scheduled for Tuesday morning: I’ll let you know how it goes…

Solving problems in a framework

Ian “Hixie” Hickson, editor of the HTML “Living Standard”* at WHATWG, is one of the most influential people on the web today. HTML5 Doctor has a very interesting interview with him, but I wanted to highlight one passage in particular.

In my day job, I usually describe myself as a web software designer. Trying to describe what that means is usually a little tricky: there are, of course, aspects of User Interface (UI) and User Experience (UX)** design in there; I also bring in some Information Architecture, a degree of HTML and CSS mastery (though, alas, my Javascript is pretty basic) and a great deal of market knowledge.

However, there is one passage from Hixie’s interview—in a context not entirely unrelated—which pretty much sums up the nitty-gritty of what I do.

Often when people send feedback (not just authors, pretty much anyone who hasn’t been in the process for a long time starts this way) they send feedback along the lines of “I want to add feature X” or “I want feature X to be extended in manner Y”. But when we drill down, ask them “what problem are you trying to solve”, or “what’s your use case” (same question but phrased differently), we often find that either (a) they actually don’t have a real problem, they just thought that it would be a good idea, or (b) their solution wouldn’t actually solve their problem. Often we’re able to come up with much simpler solutions (or point to already-existing solutions), which is quite satisfying.

Like Hixie, I am working within an existing framework—our Enterprise Content Management Framework—and, when a customer requires some new piece of functionality, I need to take into account what others have fed back and how to best solve their problem within our existing framework.

Luckily, we designed and developed the framework fairly recently—and in response to existing customer requirements—so often we can point the customer to an existing function that solves their issue.

However, when that isn’t the case, I never rely on our salesmen or, indeed, the customer’s own specification. Whenever faced with a development request, my first question is “what is the driver”, i.e. what is the problem that they are trying to solve.

Designing within a framework, understanding multiple customers’ needs, taking account of possible future developments and, thus, solving problems in the most elegant way are what give me pleasure in my job.

And deriving that enjoyment from such is what makes me good at what I do.

 

* Otherwise known as HTML5.

** There’s a school of thought that maintains that there is no difference between the two; indeed, many hold the opinion that any way in which customers interact with your company or its products is, in fact, UX.

Designers, customer feedback and measuring effectiveness

One of the most important things about being a designer—especially when you are dealing with clients who think that “design is totally subjective”—is to be incredibly precise about soliciting customer feedback.

When gathering design requirements, the first thing that I always ask a customer is “why? What are the drivers?”

Customer feedback on timescales

This even extends to the deadlines that the customer gives me: why do you need it by that date? Is there an internal driver—such as a presentation to the Executive Team or, maybe, a pre-defined publicity event?

These things are useful to know because it enables you to understand what latitude you have: and, when you are dealing with large corporate clients, you do need to have some latitude—not least because the main risk is that the customer themselves very rarely meets their own deadlines.

Customer feedback on design

Establishing drivers in design is equally important, because they help to ensure that your design meets the customer needs. I have always maintained that “design is art with a function” (and seen variations of that sentiment elsewhere), and in order to provide design that is going to meet that function, we need to know what the end goals are.

All of the above might seem unbelievably obvious, but I am constantly astonished by the number of designers that I encounter who design for themselves, and not for the client.

That is not to say that the client is always right as regards design—but the client is always right as regards the end goals that they want to achieve.

When pushing back, always do so from solid foundations

Designers should not argue with the customer on the basis of their own personal preference: designers should only argue with the customer when they are absolutely sure that the customer’s proposed design changes will harm the end goals.

Apart from anything else, arguing from solid design principles linked to the goals that the customer has set does a good job of removing the assumption that design is purely subjective: design is not subjective—that’s art.

Customers are often intimidated by the design process

It is easy to under-estimate how intimidated people often get around designers. Some years ago, I had a manager who said that he didn’t understand design and therefore was unable to manage a me.

This is, I believe, partly because people imagine that designers possess a weird, eldritch power that no one could ever hope to understand. Whilst this mystique often means that customers and companies will pay good rates for top-notch designers, the flip side is that many often distrust designers more than other functions.

This lack of trust often causes a lack of clear communication between customers and designers. At best, this can engender frustration on both sides and, often, a project that no one is entirely happy with; at worst, it can lead to a catastrophic break-down in the relationship (which is a subject for a future post).

Dealing with imprecise customer feedback

I shall expand on this tendency, and how to counter it, at a later date; however, for now, the most immediate consequence to consider is that customers are often unable—or, through intimidation, unwilling—to articulate criticism properly.

Mike Monteiro has written a particularly good post on this.

When a client says, “I don’t like green”, most designers translate the sentence into “You must change the green.” But no one asked you to, did they? They merely made a statement about their subjective dislike of a particular color. Your job, as a designer, is first and foremost to listen. And then to gather data. Don’t jump the gun. How, if at all, does the client’s subjective taste enter into the success of the project?

Your role is to be a problem-solver, not a people pleaser. So beware the urge to change your work simply because someone voices a displeasure. You weren’t hired to be nice or to make friends. If you can do either of those while also doing good work, then go for it. But don’t do it at the expense of doing your job.

At the beginning of this post, I pointed out that you should always establish what the drivers are—for just about anything. So, when the customer says that they don’t like the green, don’t assume that you know what they mean—as Mike says, probe them for the real reasons behind this view.

Let’s also remember that clients aren’t trained at giving feedback. When they make a subjective statement like “I don’t like green”, they might actually be trying to tell you that they don’t think the green works. It’s on you to figure that out, though. Ask the right questions to steer them back from that subjective answer.

“Do you think the green decreases the likelihood of a user achieving their goal? If so, can you elaborate?” (Insert your own specific goal there.)

You’ll most likely get an answer like “I don’t know. I just don’t like it.” It’s at this point that you better have a non-subjective reason for why you used that green. And give that reasoning in an objective manner. You don’t want to fight their subjectivity with your own.

But, on the off-chance that the answer is “Yes!”, ask for specifics on how. The client may have a valid point that you hadn’t thought of.

It is extremely rare—even after you have been through the whole preparation process of Information Architecture meetings, mood boards and wireframes—that a customer will sign off that very first design concept.

As such, the design process is built on successive iterations. Whilst these will—in most cases—ensure that everyone (or, at least, the customer) is happy by the end of the process, each iteration takes time.

Design iterations cost money

The more iterations that you go through costs you or your company more money. Most design firms have their own particular stages in design presentation, and so iterations will cost more or less depending on your exact process. However, unless you are billing time and materials through the whole process (very unusual in the market sector that I work in), the main point is that every, single iteration eats into your profit margin.

In my experience, many designers are not particularly financially aware: to them, making sure that the end result is right is far more important. This is, of course, a recipe for bankruptcy.

Most outputs are not subjective and can be measured

Think back to the manager who wouldn’t manage designers because he “didn’t understand design”: he had fallen into the trap of thinking that design was purely subjective, and he was intimidated by the mystique surrounding design.

This manager felt that he couldn’t judge, subjectively, whether something was a good design or not.

However, what he could have done was to find some way of measuring my effectiveness in regards to what the company needs to do—make a profit.

There are a number of ways to approach this, including looking at how many other resources it takes to implement the design. However, in the context of what we have been talking about, there is one, simple way to understand whether your designers are providing good value for money through proper engagement with your clients.

Measuring a designer’s effectiveness

A good designer is not simply one who can judge spacing, or colour complements, or can use Photoshop or Fireworks, or whatever: a good designer is one who can communicate with the client, tease out their true drivers, and create designs in response to good, solid data.

So, I would like to propose that you start to judge your designers not simply on how whizzy or pretty their designs are, nor even how accurately those designs fulfil the customers’ goals.

Your really good, productive designers—the ones who know how to communicate with clients and understand their needs the best—are the ones who achieve all of the above in the fewest possible iterations.

Measure this, and you will have a good idea as to which of your designers are listening to the customer, communicating clearly, and then applying their own creativity in a focused, sensible manner.

Summary

Whilst monitoring iterations is far from being a silver bullet, it will give you a objective, measurable platform to start from; you can then start to look around at the other factors which might help to streamline your design processes, and deliver better solutions to your customers—whilst also increasing profitability.