Why creative people sometimes make no sense

Matthew Schuler has been browsing Creativity: Flow and the Psychology of Discovery and Invention—the result of over 30 years of research into creative people by Mihaly Csikszentmihalyi.—and has distilled many of the creative quirks cited into a short, but uncannily accurate post.

Matthew quotes nine apparent contradictions that creative people apparently exhibit; I must say that I identify with all of them—to a greater or lesser degree.

As I have been carrying out a UI/UX review of our product—which I designed a few years ago—I find #8 particularly apt at present.

Most creative people are very passionate about their work, but remain extremely objective about it as well. They are able to admit when something they have made is not very good.

Throughout my career—from my humble beginnings in print, pottery and sculpture, through graphics and print, right up to the applications that I currently design—I find that, from many hundreds (possibly thousands) of things that I have created, there are only a few that I am still really proud of.

Indeed, I find that I am, at best, luke-warm about the vast majority of the work that I do only a few months afterwards.

This is less true now than when I first started working in print design, back in 1997. In those days, I was creating posters for the student theatre: budget constraints meant that full colour work was simply not available. As such, I learned to leverage the power duotones and tritones. And, of course, I could really go to town with metallics, fluorescent and other specialist inks.

The world has moved on since then: printers are now set up to produce full colour work incredibly cheaply—and now it is all of those interesting spot inks that I can now longer afford to dabble with. And, of course, real metallics simply don’t exist on the web.

Some of my pieces, however, transcend the limitations of their production methods: and some of these I have loved for many years.

The best tribute that anyone ever paid me was that they had come to see an adaptation of Neil Gaiman and Dave McKean’s Mr Punch1 purely because he “loved the poster”.

Which leads me to draw your attention to #6 on Matthew Schuler’s list:

Most creative people are genuinely humble and display a strong sense of pride at the same time.


1It was through Mr Punch that I discovered the art of Dave McKean: the poster style was influenced heavily by McKean’s work, and he remains my favourite artist of all time.


Two years ago, I tried to implement our web software interface using flexbox. Unfortunately, I was a little too eager in this endeavour, and had to hastily reinforce my fallbacks as the specification changed.

The Flexible Box Layout Model—commonly known as flexbox—has the potential to solve a number of perennial problems that front-end devs have been banging their heads against ever since CSS was invented in 1996, including equal height columns, true proportional width flexibility, and DOM ordering over-rides (very useful for Accessibility).

A number of these practical problems—and how flexbox solves them—are illustrated on Philip Walton’s Solved by Flexbox GitHub page.

However, as I discovered back in 2011, flexbox has had rather a chequered history—passing through three distinct specifications. Detailed support is outlined at caniuse.com, but, roughly, browser support is:

  • flexbox-legacy: supported by Safari 5–6 and Chrome 4–20;
  • flexbox-intermediate: Internet Explorer 10;
  • flexbox: Chrome 21+, Safari 6.1+ (allegedly), Firefox 21+ (sort of: there’s no support for flex-wrap and flex-flow).

To make things more complicated, Modernizr only has feature-detection for the oldest and newest syntax, which are output as flexbox-legacy and flexbox respectively.

And finally, once you delve into all of the possible variables, the syntax is not at all simple.

Luckily for us, a number of very smart people have been keeping up to date with all of the progress and built some useful web tools to generate code for us.

  • Flexyboxes provides a neat WYSIWYG interface for building flexible layouts, and it will generate code for all three syntaxes if you need to. Do be careful, however, as the older versions are not as capable as the up-to-date flexbox.
  • You can only use Flexplorer if your browser supports the latest syntax (which Safari 6.0.2 does not!), but it does also give a useful rundown of browser support for vendor prefix requirements.

With everything settling down—and a UI refresh of our software on the cards—I have been considering writing a set of LESS mixins for deploying flexbox in the wild. Inevitably, of course, putting “flexbox less mixins” swiftly shows that yet more smart people have got there first.

With so many to choose from, David de Coninck’s version jumped out at me most immediately—his use of guard expressions is really elegant.

See the Pen Flexbox 2013 LESS mixins by David De Coninck (@davidgenetic) on CodePen

Do you have a favourite LESS mixin that supports all of the syntaxes out of the box? Let me know in the comments…


Stripe wants to “redesign the world’s online payment structure”. It won’t.

I was recently having lunch in Skylon with a friend of mine who is also involved in software, and he mentioned that Stripe—a payment gateway—had now launched in the UK. A bit of light searching revealed a Wired article which asserts that Stripe’s co-founder wants to “redesign the world’s online payment structure to achieve one universal system”.

“… The internet has made it easy for people to communicate, but payment is still fractured. As a result the internet gets fractured as well. We don’t have this problem offline. The internet is a testament to a connected system that works—it’s a global network where any computer can reach another, and easily transfer information across.

“What if we designed payments for the internet? With interconnectivity and user experience as the goals. We’re designing from the groundup for the internet. We’ve not achieved it yet, but we expect more instruments will follow as Stripe spreads. The reason this problem is so important is that the web economy has so much growth left in it.”

The trouble is that this is simply not going to happen—not through Stripe, in any case.

Why? Well, just look at Section B5 of Stripe’s UK Terms and Conditions:

[B5] Prohibited Businesses

By registering for Stripe, you are confirming that you will not use the Service to accept payments in connection with the following businesses, business activities or business practices: (1) door-to-door sales, (2) offering substantial rebates or special incentives to the Cardholder subsequent to the original purchase, (3) negative response marketing, (4) engaging in deceptive marketing practices, (5) sharing Cardholder’s data with another merchant for payment of up-sell or cross-sell product or service, (6) evading Card Network’s chargeback monitoring programs, (7) engaging in any form of licensed or unlicensed aggregation or factoring, (8) airlines, (9) age verification, (10) age restricted products or services, (11) bail bonds, (12) bankruptcy lawyers, (13) bidding fee auctions, (14) collection agencies, (15) chain letters, (16) cheque cashing, wire transfers or money orders, (17) counterfeit goods, (18) currency exchanges or dealers, (19) embassies, foreign consulates or other foreign governments, (20) firms selling business opportunities, investment opportunities, mortgage consulting or reduction, credit counseling, repair or protection or real estate purchases with no money down, (21) credit card and identity theft protection, (22) cruise lines, (23) essay mills, (24) flea markets, (25) drug paraphernalia, (26) extended warranties, (27) fortune tellers, (28) “get rich quick” schemes; (29) gambling (including but not limited to lotteries, Internet gaming, contests, sweepstakes, or offering of prizes as an inducement to purchase goods or services), (30) sports forecasting or odds making, (31) illegal products or services, (32) mail-order brides, (33) marijuana dispensaries and related businesses, (34) money transmitters or money service businesses, (35) multi-level marketing or pyramid schemes, (36) online or other non-face-to-face pharmacies or pharmacy referral services, (37) prepaid phone cards, phone services or mobile phones, (38) pseudo pharmaceuticals, (39) quasi-cash or stored value, (40) securities brokers, (41) sexually-oriented or pornographic products or services, (42) shipping or forwarding brokers, (43) substances designed to mimic illegal drugs, (44) telemarketing, (45) telecommunications equipment and telephone sales, (46) timeshares, (47) travel agencies or travel clubs, (48) online or other non-face-to-face tobacco or e-cigarette sales, (49) weapons and munitions (50) virtual currency that can be monetised, re-sold or converted to physical or digital goods or services or otherwise exit the virtual world, (51) personal computer technical support, (52) selling video game or virtual world credits (unless you are the operator of the video game or virtual world), (53) selling social media activity, such as Twitter followers, Facebook likes or Youtube views, (54) human hair, fake hair or hair-extensions, (55) any product or service that infringes upon the copyright, trademark or trade secrets of any third party, or (56) any product, service or activity that is deceptive, unfair, predatory or prohibited by one or more Card Networks.

The vast majority of the businesses prohibited above are—assuming relevant registration and permits are obtained—totally legal and legitimate businesses.

As it happens, I was looking at Stripe in connection with a charity-related business that I am involved in. At first I was incredibly excited: Stripe seemed to offer all of the security and flexibility that we need—including OAuth integration.

Unfortunately, there is a gambling element to this business; and, even though the business has all of the required permits and clearances from the British government, Stripe’s Terms and Conditions mean that we cannot use their service.

Section B6 of the T&Cs covers illegal trading, which would surely be enough in most circumstances.

[B6] Business Conduct.

You will only accept payments through Stripe for transactions between you and your customer for the bona fide sale of lawful goods or services. You will not solicit or use a cardholder’s Card Data for any purpose other than to process payment for your goods and services. You will comply with all applicable laws, rules, regulations and orders of governments having jurisdiction in connection with your use of the Service.

One can only conclude, therefore, that Section B5 is something that Stripe have inserted to assert their own morality into their business model. Which is entirely fair enough: Stripe’s gaff, Stripe’s rules.

However, Collinson cannot make grand, sweeping statement about wanting to  “redesign the world’s online payment structure to achieve one universal system” or opine that “we’re still waiting for [an integrated] payment tag, but rather than universal it’s still fractured” when Stripe itself is committed to preventing entirely legitimate—and heavily regulated—organisations doing business online.

Collinson goes on to say:

“Payment systems are holding back online progress. You still have to fill in 15 different fields, then get redirected to Verified [by Visa].”

Collison imagines a one-click world, where making use of any entrepreneurs’ product is as fluid, natural and as user-friendly an experience as the design itself, with little friction and more transactions.

It seems that, like many entrepreneurs, Collinson makes a good case for interconnectivity on one hand whilst, in fact, establishing business practices—based, presumably, on the personal morals of him or his investors—that stifle creativity on the other.

When we have a Stripe-like system that will encourage—or at least allow—any and all legal businesses use their service then we might actually get the universal payment system that Collinson says he desires.

Until that time, talk of wanting to “redesign the world’s online payment structure to achieve one universal system” remains so much hot air.

Microsoft announces Steve Ballmer’s retirement

So, Microsoft has announced Steve Ballmer’s retirement as CEO—presumably effective from whenever the company can find someone competent that Ballmer has not driven out.

Here’s the hitch though: Ballmer has chased all potential successors out of the company — Ray Ozzie, Robbie Bach, J Allard, and most recently, Steven Sinofsky.

Just about everyone in the tech scene reckons that Ballmer was, in fact, fired—and not before time.

As someone who has always loathed Windows as a horrible piece of software (or, if you prefer, ‘as a Mac fan-boi’) I am, of course, very sad to see Ballmer go. The man’s inability to understand how to penetrate the important new markets has not only brought the destruction of Microsoft exponentially closer, but his total lack of vision and ridiculous pronouncements have also destroyed the company’s technical credibility.

The wider problem for Microsoft is that Ballmer had just initiated his (extremely risky) One Microsoft re-structuring and the decision to get rid of Monkey Boy now explains why he has remained at the helm for so long and through so many disastrous product launches, e.g. Zune, Vista, Windows 8, the Surface Tablet, Windows Mobile, Windows Phone, etc. And that reason is, quite simply, that Microsoft’s board have no more clue than Ballmer about how to save the company: it has taken them this long to work out that Ballmer was never going to be their saviour.

Indeed, not only does the board seem to be at sea, but—as Guy English points out—they don’t seem to understand that this moment is, in fact, the worst possible point to fire the idiot.

Ballmer writes in his farewell memo:

There is never a perfect time for this type of transition, but now is the right time.

No. It’s not.

They’ve just completely recreated the company in a pattern that’s totally alien to most organizations of their size. Indeed, the current configuration only seems to work for Apple. Which, arguably, grew into it completely organically. The structure of Apple certainly wasn’t created by fiat a month prior to a CEO hitting the bricks.

The only way that today’s news could have been good for Microsoft is to have announced a successor and to have said that the new structure was determined after long discussions with them. The only story that could be positive is that Ballmer and his successor, whoever they are, have worked closely together and now that the structure has changed there’ll be a year of handing over the reigns.

As it stands? Ballmer has completely shaken up the way that Microsoft has always worked. Now they don’t only need to find a new CEO who believes they can lead Microsoft out of the hole they’ve dug themselves but one who believes that the last decision that Steve Ballmer made, a company wide reorganization, is the way they, as the new leadership, want to run the company.

Microsoft is currently searching for a new CEO who’ll fit the straight jacket Steve Ballmer has left behind.

Yes, Microsoft is still making large amounts of money, but it is difficult to escape the fact that Ballmer’s tenure—certainly over the last decade—has been a failure: Marco Arment neatly sums up why.

My favorite part of this news is that this — the massive, probably-terrible internal reorganization — is what seemingly got the board to finally fire Ballmer. It really shows how far Microsoft is up its own ass.

Let the stock stagnate for over a decade? Fine.

Fail to dominate consumer web services, and only get your share by losing billions of dollars for years? That’s OK.

Lose control of online collaboration of Office documents to your biggest rival? Well, maybe the internet will turn out to be a fad.

Miss the entire smartphone revolution, then field what’s still one of the least popular major smartphone platforms? No problem.

Preside over the mass cannibalization of the PC business by tablets, while having effectively zero tablet marketshare? Hey, maybe you can try again next year.

But try to mess around with our divisions? You’re fired.

Anyone who read my last post on Microsoft will realise that the mind-boggling management practices at the company had stifled any chance of innovation long ago—certainly before Ballmer became CEO (although as part of senior management, he bears a heavy burden).

After all of this, however, people will no doubt point out that Ballmer was good at milking the assets that Microsoft already has, and that’s true.

So, perhaps the board should rethink their decision to fire Ballmer and adopt the strategy suggested by Tim Worstall—sweat the remaining assets, return as much money to the shareholders as possible, and then wind up the company.

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.


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.

The “post-comp” era

A few days ago, I wrote about moving into the “post-comp” era in the web design process. I linked to a post by Brad Frost, and now Dan Mall has written a reply to that article.

As I mentioned in the comments, I think it’s an expectation problem. The typical workflow for web design projects is to send a client a “preview” of the site to approve before beginning development. This “preview” usually comes in the form of a comp that shows how a page might be laid out and often contains specific, pixel-perfect choices with typography, spacing, images, columns, and other very fine details. The problem is that this says to a client, “We’re now at a stage where we’re focusing on details.” It’s only natural that their feedback focuses on details.

A responsive design process is like a scandal. You’ve gotta pre-emptively control the conversation. If your client wants to have conversations like this, it likely means you didn’t do a good job of setting expectations.

As Dan points out, this expectations need to be set in the Sales process—at this point, the designer should be engaging with the potential customer and trying to establish the deliverables.

Rather than promising multiple rounds of page designs as some of the first design deliverables, we’re setting the expectation that the first things they’ll see are unstyled HTML to demonstrate content hierarchy and flexibility across various screen sizes and a few pieces of a visual style—works-in-progress and unrefined broad strokes, not polished visuals that call for critique at a fine detail level. That’s why I’ve grown to love element collages; they’re literal enough that your client can start to see a picture of things coming together but still enough of a work-in-progress that there’s no expecation that the site would actually look like this for everyone.

This is, in this age of multiple devices, simply not sustainable; in short, it creates false expectations for your customers.

To be fair, I don’t think we’re in a post-PSD era, but I do think we’re moving towards a post-“full-comp” era. I can’t envision a project where I don’t use Photoshop. Photoshop isn’t the problem. It’s a great tool. My favorite, actually. It’s the stigma that comes with presenting a full comp (I define “full comp” as an image of a website viewed on a desktop, typically around 960px wide). By default, presenting a full comp says to your client, “This is how everyone will see your site.” In our multi-device world, we’re quickly moving towards, “This is how some people will see your site,” but we’re not doing a great job of communicating that.

As an industry, we sell websites like paintings. Instead, we should be selling beautiful and easy access to content, agnostic of device, screen size, or context. If you can get your client to believe in the sales process that you’ll do that for them, they won’t care what the site looks like.

This is precisely right. Of course, when you are in a company that has a Sales Team—rather than the salesman being, principally, you—then the first people that you have to convince is the Sales Team.

As I mentioned in my previous post on this subject, we have just started moving our first customers towards this process; however, we are feeling our way to a certain extent and not yet nailed down the outputs.

Yes, the projects on which we have deployed this process do seem to be going fairly well: however, we need to firm up the process very swiftly now—and then sell it to our Sales Team.

I am absolutely convinced that we are moving into a post-comp era and that it is going to lead to far more satisfying results for both designers and customers. However, it needs to be presented in the correct way, and both sides need to understand the deliverables. In short, expectations need to be sold, set and delivered.

I will continue to update you all on how it goes…

Reciprocity: give to get

Living in the world that we do—with its smartphones, transatlantic travel, ultra-high-def TVs and One Direction—it’s sometimes easy to forget that we are, at the most basic level, animals.

We have, over the course of human evolution (modern humans it’s generally agreed upon have been around for at least 200,000 years), carried with us various traits that helped our long gone ancestors to navigate and survive on this planet we call “home”.

In the modern world of communications these traits may seem of no real concern to us but the truth of the matter is that we still act and make decisions based on them.

The use of reciprocity, for example, can be a powerful tool to help create a reaction and a connection with your clients and customers. It can help build a deeper relationship, creating trust and loyalty.

At the most basic level, reciprocity is the exchange of something of value between two or more people. This doesn’t have to be as obvious as giving a present or receiving a birthday card: assistance, advice and contacts can equally be a form of reciprocity.

By and large we try to repay in kind what another person has given us; if we don’t, we usually have an overwhelming feeling of guilt—and there aren’t many people who enjoy that feeling. I know I don’t.

There are many theories as to where reciprocity comes from and why it’s a major influence over our lives and decision making. It has been theorised that it relies on a universally held belief of future obligation: if we give something of value away it won’t be lost forever but will be repaid to us in the future with something of equally valuable (or even more so). Humans for the most part will almost always strive to repay this “debt” even when the expectation of repayment is a vague one.

We can see reciprocity happening all the time in the online arena—take LinkedIn, for example. When we receive endorsements or recommendations from our clients or associates, most of us will respond in kind without being asked—we somehow feel compelled to do so.

When someone comments on one of our photos on Facebook, we will often comment back on one of theirs. Even if we don’t feel obligated, we would rather do this than not as it’s fundamental to our social success.

We can make use of this ancestral practice in a variety of ways.

  • Write free articles—not only will you be giving your readers knowledge for free but you’ll also be enhancing your position and credibility as an expert in the field in which you operate. The same can be said for coding. There are many developers who use reciprocity by giving away bits of code they have created: those who download the code feel obliged to either spread the word about the developer’s site, leave comments of thanks (usually praising the developer’s skills) or offering solutions or “bug fixes” for free.
  • Offer a free consultation—by giving away a bit of your knowledge and helping your potential clients/customers just a little it will instil the feeling that you’ve gone out of your way to help. It will enhance your reputation and increase the prospect of a more meaningful and prosperous relationship.
  • Compromise—by showing that you have the ability to compromise, your client will more than likely wish to reciprocate in kind, leading to a mutually beneficial outcome. This doesn’t mean that you have to become weak and go against your fundamental principles. Be strong, but always make room for compromise too.

It seems that even though we are moving full steam ahead into the future, there are certain traits that are ingrained in the collective human psyche. Don’t forget to use those traits—they’re effective, they work and they have done for at least the past 200,000 years.

Applications that I use

Having mentioned Sketch in my previous post, I thought that I would expand on the applications that I use in my workflows. And to start with, I need to expand on what those workflows actually are.

Which is tricky—because I do quite a number of varied jobs.

First, I do a considerable amount of management, both in my team and in the wider business. This is why my job title is the, slightly unwieldy, Creative and User Experience Manager (usually shortened to CrUX Manager).

Essentially, I lead the team that designs and builds our customers’ websites and intranets on our company’s content management platform (CMS). However, I also design the user interface (UI) and user experience (UX) for the CMS—plus I also design a lot of the new functionality too.

Occasionally, I give talks at events—both internal and external—about the web, CSS, Accessibility, and other related issues.

Because I know a lot about the web, our product and our customers, I have also spent a lot of time in customer pitches, Information Architecture (IA) workshops, and in discovery meetings for new software. In other words, I am heavily involved in a customer’s entire journeys with our company—and, in many cases, for determining the steps along that journey.

And, since I run the CrUX team, I am also responsible for recruitment to that team and, with the operations team, for managing resources on a day-to-day basis. And, of course, when we have a new starter, I am responsible for sorting out software and hardware—which means that I know how much we invest in our applications!

Which brings us back to where we began—the applications that I use to achieve all of this.

Graphic Design

For the moment, I find myself continually coming back to Photoshop—like a dog to its sick. I don’t really like Photoshop for design (and I loathe Illustrator) but it is familiar and thus relatively easy to dip into.

However, I am gradually weaning myself off Adobe’s products in favour of smaller, cheaper applications that are, in many ways, better for the job than Adobe’s bloated behemoth’s.

I have been playing about with Sketch (about £30) a lot, and I think it’s a wonderful application. It is very capable and, with every update (usually monthly), it becomes more capable and more stable. I am aiming to make it my primary design tool.

For non-vector based work, I have been getting into using Pixelmator (about £20) which is also an excellent (and cheap) photo-editing and design application.


My browser of preference is Safari. Its Web Inspector tools are almost as capable as Chrome’s, and I find the browser faster and more reliable than Google’s offering.

However, I do test in all major browsers—including Internet Explorer 7, 8, 9 and 10. To achieve this on my Mac, I use VirtualBox (free) and the wonderful IEVMS script to automate the conversion of Microsoft’s supplied disk images to a format that VirtualBox can read.


A few years ago, I found myself, with a colleague, in a café with free Wi-Fi; up until that point, I had used Dreamweaver to code my work. However, my laptop was not equipped with my meatier applications and so—needing to do some coding and having read a good review of it—I downloaded Panic’s Coda.

And I have never seriously used another coding environment since (although I have also dabbled with MacRabbit’s Espresso—before they merged it with CSS Edit). I certainly never launched Dreamweaver ever again.

Coda was, essentially, my first foray into the sunlit uplands of indie Mac Developers. Up until that time, I had basically used Adobe applications and little else; for someone with this experience, the speed with which Coda launched and operated, as well as its feeling of lightness, were a revelation.

That independent developers are challenging Adobe in its core areas of photo-editing and vector design (this latter being an area that Adobe basically stole when it killed my beloved Freehand) is one of the very best things about the Mac platform right now.

I write in LESS and use the excellent CodeKit to process it, as well as for compressing images, and other useful things. Be sure to read CodeKit’s amusing release notes, by the way…

Finally, I started using CodePen a lot for experiments, reduced test cases, reference files, etc. I particularly like the fact that it compiles LESS on the fly. I haven’t had much time to continue playing with it recently, but that should change in the next few days.

Software Design

My role in this area is, essentially, to gather customer needs, to productise them, and write requirements specifications.

For this I use Apple’s Pages (£14) for the text and, for the workflows, Celestial Teapot’s very nice little diagramming application called, simply, Shapes (roughly £3!).

This latter app is—like most Mac indie apps—under active development and Celestial Teapot seem very good at taking feedback and incorporating it into releases.


For most other administrative tasks, I use Pages, Numbers and—for presentations and speaking engagements—Keynote.

When presenting, I use Apple’s Keynote Remote—running on my iPhone—to control the slides and display presenter notes (where necessary). In the absence of Wi-Fi (a rare thing these days) I carry a standard, hardware Apple Remote.


I do dabble with a few other apps, and I like to try out new applications quite often.


Where necessary, I use MockingBird for building up wireframes; it is simple, elegant and easy-to-use. The lack of development on it over the last couple of years has been disappointing, but it is still an excellent online application.


One app which has a great deal of potential is Tumult’s Hype. Using this application, you can build up complex animations using a timeline model, and Hype will then generate a file containing CSS3 animations (including complex matrices): even better, it will also generate the Javascript required to cater for older browsers.

Combine this with Modernizr and the built-in YepNopeJS, and you have a modern, compliant solution for creating complex animations.

Project Planning

Since I have taken over my current job role I don’t use OmniPlan as much, but I still find it useful for internal scheduling: it’s a fully-fledged project management application, with proper concepts of utilisation and efficiency.

Font Management

For font management, I still use the free version of Linotype FontExplorer X (which, whilst difficult to find now, has lasted me for years and years!), but I am starting to switch over to Bohemian Coding’s Font Case.

For web fonts, I use TypeKit (although, since Adobe has taken over, I am finding some issues with reliability. What a surprise) and, occasionally, Google Web Fonts.

And that’s about it. There are one or two applications that I play with, but the major ones are those listed above.

Do you have any favourite applications? Feel free to leave your preferences in the comments…

Subtle patterns

My team have a great habit of sending around things of interest, and so it was one of my colleagues who pointed me towards Meng To’s website.

Whilst the site is, indeed, a thing of beauty (as one would expect from a UI/UX designer), I was most interested to see that, on his blog, Meng was pushing Bohemian Coding‘s Sketch.

Sketch is a brilliant vector-drawing application—a replacement to Illustrator and much of what I use Photoshop for—that I have been moderately evangelical about at work. (This may or may not have something to do with my personal mission to eliminate Adobe’s over-priced, bloated software from my work-flows).

One of Meng’s posts is about how to get started with Sketch, and he links to a number of great resources—including icon sets and, usefully, a new-to-me website called Subtle Patterns.

Subtle Patterns does exactly what it says on the tin: it provides pages and pages of free subtle patterns for use in your designs. I have immediately book-marked it…

I will write more about Sketch at a later date, but I heartily recommend giving a trial.

A Link List Apart

A LIst Apart's new home page
The new A List Apart home page, viewed at my browser’s full height. No, I haven’t scrolled down.

A List Apart have embarked on a redesign, and I have to say that I am not a fan. Let me very briefly lay out the reasons why:

  • the cut-off logo looks weird. Not cool—just weird. I keep checking whether my scrolling has gone haywire.
  • it has massive text. Why does it have massive text? Seriously, why would you want to force me to scroll more than I already have to? And yes, I do have a scroll-wheel at home; but no, I do not have one at work. And that applies to Zeldman’s site too.
  • the RSS Feed is now full of endless links to other endless resources. If I spent every hour of my day checking them, I would be unemployed.
  • part of the excellence of A List Apart was its carefully selected articles that did not clutter my RSS Reader with endless link lists of other people’s things to read. I thought that ALA’s principled stand against the constant barrage of information whoring was admirable—it showed a confidence in its format and writing. Now it is just another Daring Fireball or Shawn Blanc.
  • I wouldn’t mind lots of link lists to interesting articles if all of these massively profitable sites—like Daring Fireball and Shawn Blanc and, now, ALA—weren’t basically linking to the same stuff. (I know, because they are all in my Feed Reader.)
  • yes, I do know that I can modify my ALA Feed: but why should I have to…?

I don’t pretend to be the world’s most amazing designer—and, even if I did, you certainly wouldn’t know it from this largely unmodified template—but I rather think that ALA’s redesign is not an improvement.

And I really wish that people would stop trying to make money by piggy-backing off the time and effort that other people put in. I mean, I don’t always agree with them, but at least the denizens of Boagworld write their own material.

The increasing prevalence of blogs consisting of little more than daily link lists is a bit like having a bunch of friends who think that repeating Monty Python sketches word for word for an entire evening is either amusing or interesting.

Eventually, the tech internet is going to consist solely of link lists of link lists.

At which point, I shall pray for the Apocalypse.

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…

Cultural fit

I’ve been with my present company for nearly five years and have fulfilled numerous job roles over that time: I was hired as the second Web Designer, then moved into Project Management, then to Marketing Manager. After that, I led the nascent Product Development Team as Product Manager for two years; about six months ago, I was asked to head up and lead the Creative and User Experience Team (design had been part of the Operations Delivery Team, rather than a function in its own right).

In this time, I have been involved in hiring for a varied selection of job roles: designers, telemarketers, sales development managers, project managers, account managers, front-end developers, back-end developers, operations managers, and more.

In every case, whilst the candidates’ skills have been important, what has defined their success within our company is whether or not they are a good “cultural fit”.

An article in Bloomberg BusinessWeek maintains that, in hiring, job applicants’ cultural fit can trump qualifications.

In the December issue of the American Sociological Review, Northwestern professor Lauren Rivera concludes that companies are making hiring decisions “in a manner more closely resembling the choice of friends or romantic partners.” Rivera found that apparently off-topic questions have become central to the hiring process. “Whether someone rock climbs, plays the cello, or enjoys film noir may seem trivial,” she wrote, “but these leisure pursuits were crucial for assessing someone as a cultural fit.” As a result, Rivera argues, “employers don’t necessarily hire the most skilled candidates.”

The phrase “cultural fit” may summon up obnoxious images of old boys clubs and social connections, but it’s a powerful buzzword among human resources professionals. A cooperative, creative atmosphere can make workdays more tolerable and head off problems before they begin. “I used to work for an e-commerce company that spent a lot of time refining its culture,” says Mercedes Douglas, now head of recruiting at Kikin, an Internet search startup. “I hired someone as a manager, and it created a lot of tension because he didn’t fit in. People tried to alienate him because they weren’t interested in him as a friend,” she says. And it also goes the other way. “I once hired a woman who really didn’t have the right background or experience for the job, but who I hit it off with during the interview,” says Rebecca Grossman-Cohen, a marketing executive at News Corp. (NWS). “And because we got along so well, I was able to train her easily, and she ended up doing great things for us.”[*]

Cultural fit is tremendously important and, given two candidates with different skills, we will certainly go with the one that we feel is going to fit in best with the company culture.

Don Melton does offer some words of warning about this attitude—not least in that it is possible that asking certain questions of a candidate could get you into trouble legally. However, this hiring policy can have negative effects on your business too.

More importantly, screening for cultural fit is a tricky goal since your organization could wind up with a monoculture. Making sure your new employees embrace your company culture, e.g. innovation, is a good thing. Making sure all those employees are similar culturally can play havoc with diversity and limit perspectives. And that’s bad.

This is true, but the danger can be somewhat mitigated by the fact that the cultural fit in certain teams might be different. The culture which pertains to our Sales & Marketing Team, for instance, is very different to that within my own—partly because they do a different job, and have a rather different attitude to the customer.

However, none of this alters the fact that the people driving our company forward—regardless of what team they are in—share a certain attitude: they are, in the main, extremely knowledgable about our customers and markets, extremely technically savvy (not necessarily in the detail of code, but in identifying wider trends), strong-willed and entrepreneurial. Importantly, they are able to understand how to apply all of this general knowledge to the specific problems and developments that our company needs to address.

But most crucially, all of these people are committed to ensuring the company’s success, despite any set-backs.

And these people are often not “managers”; this being the case, our company is not massively hierarchical because power naturally flows to those with not only the knowledge and skills but also a “can do” attitude.

After all, if you have a question about something, you aren’t going to go to that guy who is going to get annoyed or mock you for not knowing the answer, are you? No, you are going to go to the guy who not only knows the answer and will give it to you freely, but is also going to say “what can I do to help?”

Whilst it could be argued that this leads to a certain exploitation of these individuals, in a small company, the maximum dissemination of knowledge is incredibly important. And if I, as a salesman, am asking a question about the capabilities of one of our products, it must mean that I require it so that I can do my job, i.e. selling said product; and, of course, selling said product (and being accurate about its features) is to the benefit of the company.

As such, it does also mean that these knowledgable individuals are seen to be aligned with the company’s aims rather than just their own. This perceived similarity of purpose binds them—in the minds of others as well as, often, themselves—into a team that transcends normal hierarchical or departmental bounds.

And so we return to this idea of cultural fit, and of which kind of culture you actually want people to fit into.

When I interview people, I do want definitely want them to fit into my team’s ethos; but if they are highly skilled and are going to be able to do the job that I need them to do really well, then we’ll hire them.

However, what I am really looking for—every time—is someone who is likely to become one of those “core” people; someone who is going to advance the company, who will be a manager—whether officially or not.

And that’s the cultural fit that we’d really like candidates to suit.

* Let’s hope that the interviewee in the latter example wasn’t Rebekah Brookes.

** As it happens, I am currently looking for two Web Designers / Front-end Developers. And one of them most definitely needs to be a “core” person, since they will eventually be leading the Creative and User Experience Team.

Bandwidth media queries

Back in March 2012, Chris Coyier opined that, in addition to other @media queries, what we really needed was bandwidth media queries.

But is screen width the correct metric to use here? Perhaps it is, why would a screen that is 400px wide ever need an image that is larger than 400px wide? Well I think the retina display on certain new devices are answering that question for us. Those devices may respond to certain width media query but really have twice the pixels available and be able to show much sharper images. Yes, we have device-pixel-ratio media queries for that as well, but I still think we’re dancing around the issue.

That issue is: bandwidth. If I’m in a place / on a device that has super slow internet, I’d love to be served a very light web page so browsing is still acceptably fast. If I’m in a place / on a device that has super fast internet, by all means ratchet it up and deliver me more.

This doesn’t mean ignore screen size. That’s obviously relevant when it comes to layout. This extension of media queries would give us a more appropriate tool for media in a world where the size of your device is increasingly unrelated to its bandwidth.

So I wonder: is it possible?

The short answer, as provided by Yoav Weiss writing at Smashing Magazine and interpreted by your humble Devil, is “no, it’s not; and it is not desirable in any case. And even were measuring bandwidth desirable, bandwidth media queries would be entirely the wrong way to approach it”.

The reasons are many-fold, but they start with the fact that not only is effective bandwidth is incredibly difficult to measure but also that, even on a relatively stable connection, the TCP protocol is designed so that bandwidth actually changes all of the time.

And that is without including mobile users, whose rated bandwidth might change as they move between broadcast cells.

TCP is the dominant protocol for the reliable transfer of data on the Internet. The protocol itself has a certain overhead that results in a difference between the theoretical and the effective bandwidth. But another factor is responsible for an even more significant gap between the two. TCP doesn’t always use all of the bandwidth available to it, simply because it doesn’t know the bandwidth’s size.

Sending more data than the available bandwidth can cause network congestion, which has disastrous implications on the network. Therefore, TCP uses a couple of congestion control mechanisms: slow-start and congestion avoidance.

Each TCP connection is created with a very limited bandwidth “allowance,” called a congestion window. The congestion window grows exponentially over time, until the TCP connection sends enough data to “fill the pipe.” That is the slow-start phase, which can take up to several seconds, depending on the network’s delay. Then, TCP periodically tries to send just a little more, to see if it can increase the amount of data it sends without causing congestion. That is the congestion-avoidance phase.

Both of these mechanisms assume that packet loss is always caused by congestion; so, packet loss results in a significant reduction to the congestion window, as well as to the rate at which data is sent. On wireless and mobile networks, this behavior is not always ideal because they can suffer from packet loss for reasons other than congestion (for example, poor reception), which can result in under-utilization of the network.

So, bandwidth, by its very nature—by its very design—is variable over time. But even if the browser could accurately measure the effective bandwidth at any one moment, bandwidth media queries are precisely the wrong way to implement any tests.

As far as the browser is concerned, a media query is a direct order with which the browser must comply. It has no room for optimizations. It cannot avoid obeying it, even when it makes absolutely no sense. Let’s explore what that means for bandwidth media queries.

Let’s assume for a minute that browsers actually do have an accurate way to measure the current bandwidth and that a solution for responsive images is in place and can use a bandwidth media query.

The natural thing to do, then, would be to define a responsive image with multiple sources— a high-resolution image to use when the bandwidth exceeds a certain value, and a low-resolution image when the bandwidth is low. The browser loading the page that contains the image would then download the high-resolution image, since it has good bandwidth conditions.

Let’s say that, after a few seconds, the bandwidth conditions change for some reason. The browser (sharp at detecting bandwidth as it is) will immediately detect that the bandwidth is down. The browser is now obligated to download the lower-resolution image and replace the high-resolution one with it. The result is a useless download of the low-resolution image and a worse user experience, because the quality of the image that the user sees is worse than it could be. Even if this happens to only a low percentage of users, that’s bad news.

Now, you could argue that the browser could optimize and use the version it already has. But the fact of the matter is, it can’t; not with media queries — at least not without changing the whole meaning of them.

So, the quick answer to Chris’s question is: no, bandwidth media queries are not possible. And even if such measurements could be implemented reliably, media queries would be the entirely the wrong way to go about making web pages responsive to bandwidth anyway.

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.

A new CSS property — position:sticky;

My blog colleague, Mike, wrote about implementing “sticky” menus in Javascript; however, it seems that this effect can be achieved in WebKit browsers through a new CSS property—position:sticky;.

By simply adding position: sticky (vendor prefixed), we can tell an element to be position: relative until the user scrolls the item (or its parent) to be 15px from the top:

At top: 15px, the element becomes fixed.

HTML5 Rocks has put together a demo although, of course, it will not work in anything other the latest version of Chrome or the WebKit Nightlies.

However, I can think of a couple of places where I should incorporate position:sticky; into our company’s CMS and shall do so, against the day when the property is widespread.

As a point of interest, this tends to be my general strategy for new CSS properties: I implement them into our systems so that, in the future, people get a nice surprise!

Sticky Navigation Bars

A key consideration I make when designing intranets is how the navigation must always be easily accessible because users can land on any page and each user will have a different set of aims when using the site. Links are sent over email all the time and I can’t expect the sender to clean up a URL to remove things like anchor references or variables.

The solution: sticky navigation bars.

The effect is simple. When a user scrolls down the page the navigation is seemingly ‘lifted’ out of it’s placeholder and flows down the page with them, allowing them to click through to any other part of the site (so long as it is held within the primary navigation system).

The method was also remarkably simple, thanks to a jQuery plugins called Waypoints.

I’m using WordPress for my intranet project, so the code I use in my header.php file is:

The vital thing here is the containing element being set to use the nav HTML tag and the menu class being set to nav-bar.

Then in footer.php we call the Waypoints plugin. I put these JS calls in the footer because if they hang or fail the user can still use the website, albeit without the sticky nav. I’ve also added my site-specific code to a separate JS file because I like to keep things tidy. Don’t forget this is all jQuery so you’ll need to call the core files too.

I also do some really simple css.

Then, inside stickynav.js I do this:

Easy, huh? Credit where it’s due, this is not my own solution it’s my implementation of a tutorial here.

A useful resource for teaching customers about web design

As discussed in my last post, many customers do not really understand design; this is doubly true when it comes to designing for the web. Right on cue, Wee Nudge is an excellent recourse for teaching customers about web design (and, indeed, design in general).

Topics include spec work, the “fold”, whitespace, wireframes, content—and that all-important subject of giving, and getting, feedback. The articles are from a variety of sources, and should be an invaluable resource in enabling you to work better with your customers.

You know what they say: “give a man a web design and you feed him for a day; but teaching customers about web design will enable a great working relationship.”

Or something like that…

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.


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.

Web Fonts

Adobe have just recently announced the release of Adobe Edge Web Fonts, a large library of web fonts. Whilst Adobe has teamed up with Google in order to offer many of these typefaces, they are served through TypeKit—which was bought by Adobe some months ago—and are free to use (for now, at least).

I am a great fan of using web fonts—anything has to be better than constant doses of Arial. There are certain pitfalls and caveats that web designers do need to bear in mind, but I shall cover those in a later post.

Right now, I would like to make an observation—simply because it amuses me…

Ten years ago, companies were getting frustrated that they couldn’t use their super print-specified corporate fonts on their websites (at least not without using some horrible substitution system like Flash or Cufon).

So, in the last few years, we have seen more and more companies changing their corporate image—and all of their print and branding material—to one of the 30-odd typefaces available to “normal” web browsers (such as Trebuchet or Lucida).

Now, the web font revolution has hugely expanded the number of typefaces available on the web—rendering all of the rebrands utterly unnecessary!

I am most amused…

How browsers build pages

There are any number of guidelines and theories about how best to write sustainable CSS, and smacss (pronounced “smacks” apparently) is another of those. I was reading through the introductory chapters, and was interested to learn how browsers build pages.

The browser starts at the top and sees a body element. At this point, it thinks it is empty. It hasn’t evaluated anything else. The browser will determine what the computed styles are and apply them to the element. What is the font, the color, the line height? After it figures this out, it paints it to the screen.

Next, it sees a div element with an ID of content. Again, at this point, it thinks it is empty. It hasn’t evaluated anything else. The browser figures out the styles and then the div gets painted. The browser will determine if it needs to repaint the body—did the element get wider or taller? (I suspect there are other considerations but width and height changes are the most common effects child elements have on their parents.)

This process continues on until it reaches the end of the document.

This seems, to me, to be a very inefficient way of building a page since multiple “repaints” are necessary, but it is easy to forget just how fast and efficient modern browsers have become.

Below, you can view a vastly slowed down video of a Mozilla browser rendering a page using this method.

Pretty impressive, I think. But it still seems conceptually inefficient…