Newer posts are loading.
You are at the newest post.
Click here to check if anything new just came in.

June 25 2013


A Q&A with UX Mad 2013

When it comes to meeting with the community in-person, UX designers have plenty of events to choose from. One particularly unique option is UX Mad, bringing together speakers from all different walks of life. As it turns out, those walks of life were also prime candidates for an interview.

UX Mad is an annual, one-track, user-experience-design conference held every July in Madison, WI. Featuring a wide variety of speakers – from professional musicians to craft ice cream makers – it offers attendees an opportunity to meet and mingle with an otherwise disparate group of passionate creators.

In fact, the lineup reflects just how multidisciplinary experience design can be. Looking at their various backgrounds made me wonder: where do these speakers overlap? The answers, you’ll find, are surprising. Read on for wide-ranging insight into the creative minds of this year’s speakers and even a chance to win a ticket to the event!

How do you define user experience? How did you get into it?
Lea StewartLea Stewart: UX is a way to describe an ecosystem of products and services that consider a users’ needs, behaviors, and attitudes. Coming from Industrial Design, I don’t think of it as strictly digital. Instead of developing a next-generation training shoe, a UX designer might envision the “experience of running”.
MoldoverMoldover: To me, user experience represents a change in focus from simply getting something to work to making it as intuitive and enjoyable as possible.
Sergio NouvelSergio Nouvel: User experience is an evolution of design in general. Once you begin to care about users, you start to wonder which factors influence a good design beyond the mere look-and-feel. You start being a lot more aware of how easy the interface is to consume (which itself depends on how the content is structured, what it intends to do, etc.)
Can you give us a sneak peek of your talk at UX Mad?
Jenn DownsJenn Downs: Marketing automation is a powerful tool, but if used incorrectly it can reduce empathy for the user. Using technology to manage the relationship isn’t a replacement for human-to-human contact.
Jessica PetersonJessica Peterson: I’m taking part in a discussion panel of people chosen from distinct disciplines with a similar regard for the role of research in the design process. We want to demonstrate why the science of research and applied research is critical.
MoldoverMoldover: Human interface design for musical instruments presents unique challenges and vast new possibilities. The proliferation of low-cost rapid-prototyping tools has put the means of fabricating instruments within reach of any potential musician. I’ll go through the design process for some of my inventions.
Pamela PavliscakPamela Pavliscak: Data isn’t just a four-letter word. Numbers let us track improvements and setbacks over time, communicate important information at a glance, and tell us where we stand against competition.
Russ UngerRuss Unger: I’m giving a talk about Jim Henson and how the way he worked applies to what we can do in UX. It’s not one of those “X Things We Can Learn About UX From [a person];” it’s about the way he worked. It’s a little bit of history, observation, and fun. Oh! And Muppets–lots of Muppets! Probably a bunch of stuff you never knew about them, and Jim Henson!
What was the last creative project you did for fun? How do you deal with blocks?
Jesse ShternshusJesse Shternshus: I’ve been working with a designer to re-brand my company. I challenge myself by giving myself a couple minutes to think of as many terrible ideas as possible. Sometimes really good ideas come out of it.
Martin AtkinsMartin Atkins: I like speaking and work pretty hard at the payoff of that. The same goes for my books. There’s a difference between the information and the delivery of that information in a form that works. I try to have enough going on that when I am creatively blocked I can keep my energy output up while the wheels and cogs keep turning and (hopefully) magically produce the solution like some fairground wizard.
Pamela PavliscakPamela Pavliscak: Even though I observe and talk to strangers using technology all the time, I’m pretty awkward when it comes to mingling in large social groups. Recently, I had to go to an event by myself, so I decided random UX testing might at least give me some conversational gambit. A few takeaways: find a quiet corner, talk to people early in the evening, make friends with all the servers, and let people see some results.
Sergio NouvelSergio Nouvel: How do I deal with creative blocks? I don’t. I don’t regard hitting the point of frustration as a “block”. I see it as a necessary step. I never consider myself blocked, so it helps a lot with the feeling of being blocked.
What does mobile mean to user-centered designers?
Andrew MaierAndrew Maier: Mobile means we can no longer depend upon a certain context in which people will use things (not that we ever really could). As a consequence, we have to make our solutions more robust – to consider alternative ways of presenting information and affording functionality.
Golli HashemianGolli Hashemian: Honestly, it annoys me that everyone focuses so much on mobile as a separate topic of user experience. From a high level, designing for mobile isn’t a separate process – it’s an evolution of user-centered design. We study how our customers use our product and design accordingly, taking context into account as well.
Sergio NouvelSergio Nouvel: Mobile has always been with us simply because we are mobile beings (unlike a tree). Mobile isn’t new: think of a watch as a mobile analog device. Mobile is a context. Devices will keep changing, and what really matters is not the resolution or the touch screen, but the context – the unpredictability of what’s surrounding a user, what state of mind they’re in, or what else they’re trying to do. The first step is admitting our inability to cover absolutely every scenario.
What disciplines within user-centered design excite you? Why?
Andrew MaierAndrew Maier: Civic design & social entrepreneurship. They’re areas that absolutely need our attention (as designers) because they have the most power to affect people on a day-to-day basis. Democracy is interactive by design. Nowadays, we’ve lost that feeling of empowerment.
Jessica PetersonJessica Peterson: Nothing beats first-hand research. Making sure we understand what the users are thinking and what their needs are is just as important as making sure the interface is well-designed, the colors and proportions and pleasing, and the features are usable.
Lea StewartLea Stewart: My background is in industrial design, so that’s where my passion lies. I have an internal struggle with creating more “stuff” that may someday be discarded. I focus on sustainability and to ensure that whatever I design is truly needed and wanted by users instead of heading for the landfill.
MoldoverMoldover: Hardware. It’s refreshing to make physical objects when we spend so much time manipulating digital “things.”

That’s all, folks! A big thank you to all of this year’s speakers for taking the time to answer our questions. Everyone listed above (and more!) will be in Madison this July 12-13, so come on out, meet them, have a good time, and eat some cheese!

Welcome to Wisconsin

Will we see you there? UX Mad is just a few weeks away. If you haven’t bought your ticket yet but you’re itching to go (especially after such riveting responses), you’re in luck: we’re giving one away.

To enter, let us know who you’re most excited to meet and why in the comments below. Be sure to follow @uxbooth, and to leave your Twitter handle with your comment so we can get in touch with you for your freebie. Entries must be in by midnight (PST) June 27th. We know it’s tight, but we want to give the lucky winner the time to arrange travel and lodging, as we can’t provide those. Good luck!

The post A Q&A with UX Mad 2013 appeared first on UX Booth.

June 11 2013


A User Experience Business of One

My initial foray into UX frustrated me. Although my job title suggested that I made products easier for end-users, I actually spent a lot of time selling user experience to clients, stakeholders, and colleagues. I knew I needed to broaden my focus, but I didn’t know where to start. And that’s when I discovered The Business Model Canvas.

The story behind what we today know as the Business Model Canvas is an interesting one. Originally created as a conceptual framework for Alexander Osterwalder’s PhD project, it later became the subject of an entire book called Business Model Generation, co-authored with Yves Pigneur. Today, both the book and the canvas allow those of us without business training (including yours truly) to better understand sustainable business practices.

My application of the Business Model Canvas is likely atypical, though. Instead of using the canvas to aid clients, I wondered: what if I looked at my role as a business itself? After all, I need resources to operate (a budget, my supervisors’ time, my colleagues’ expertise); I have customers (people to whom I provide value); I have costs (my time, materials, stress). Could understanding all these things help me design more efficiently?


To follow my logic, it’s useful to first understand how the business model canvas is laid out.

Personal Business Model Canvas Worksheet. Source:

Divided into nine parts, it includes:

  • Key partners – Who supports you?
  • Key activities – What do you do to create value?
  • Key resources – What do you require?
  • Customers – For whom do you create value?
  • Value – What problems do you solve? What needs do you address?
  • Channels – How do you communicate your value?
  • Customer relationships – How you interact with customers?
  • Revenue – What do you get?
  • Costs – What do you give?

Using the original book’s sequel (Business Model You) as a guide, I thought critically about my role within my organization. Rather than rigorously weigh all nine considerations here, though – something for which the book is much better suited – let’s look at three in particular: customers, value provided, and key channels.

Customers: not just the end-user

While it’s relatively easy to assume that our customers are the same as the customers of the company for which we work, this isn’t strictly the case. As the book defines them, customers are anyone for whom we’re creating value, including:

  • Clients and stakeholders, who rely on us for our expertise;
  • End-users, who rely on us to represent their needs;
  • Software developers, who rely on us to clarify interactions and interfaces;
  • Other members of the design team, who rely on us for user research; and, finally,
  • Colleagues in quality assurance, who rely on us for specifications and clarifications.

Notice that end-users are only one item on the list. Notice, also, that colleagues are customers too. Couple this with the fact that we practice user-centered design and it becomes increasingly obvious why it’s part of our job to consider our team and their benefit.

User experience design isn’t limited to human-computer interaction; it includes human-human interaction as well. Before filling out the canvas, I instinctively knew this – that my responsibility did not end with “end users” – however, I didn’t know what I could do to serve them more effectively. That’s when I considered value propositions.

Value: not just deliverables

Just as clients tend to think of our work as deliverables, designers often think of our work as different activities: holding workshops, conducting interviews, writing scenarios, making wireframes. Yet one of the biggest mistakes we can make is to assume that the activities we conduct are the same thing as the value we provide.

When I sat down to determine the value I provided, I was stumped. I could only think of – dare I say it – clichés. Yeesh. “Making things easy to use,” “generating empathy,” etc. I needed to break it down.

My actual first draft of value provided – this describes what value my role provides, irrespective of activities.

To determine the value I provided to others, I started with a list of what I was currently doing at work: conducting user interviews, diagramming mental models, building low-fidelity prototypes, tracing mind maps, putting together personas. Next, I considered my reasoning for each activity. Why did I interview project stakeholders?, for example. Then I asked myself: So what?

Repeatedly. Until I hit something.

This resulted in the following table:

Activity I do this to… So that… User interviews Build empathy for customers We avoid building a product “for everyone” Mental Model Diagram Determine our feature fit Stakeholders can see gaps Low-fidelity prototype Share the vision Everyone can agree to the product direction, sooner

Does interviewing customers before designing reduce the risk of product-market mismatch? Does one particular kind of prototype make it easier to adapt the design vision? You don’t know until you think it through.

Next, I considered the value provided by each of these activities for my customers:

Activity Value to client Value to developers Value to designers Mental Model Diagram Risk reduction. This helps clients see gaps in their offering (where they might lose competitive edge or profit) Convenience. This allows developers to more easily write user stories by providing user motivations. Cost reduction. This provides designers with context so they can more quickly make design decisions.

Notice how the value differs depending upon the customer. Finding the right way to phrase the value we provide for a given audience is, simply put, a user-centered way of thinking. It requires asking the right questions and actually listening to the answers. In this case, we just have to add business constraints, and organizational fit to our list of topics to listen out for.

Communicating this way signals that we have a wide skillset. When I sit down at a meeting, I sometimes sense that a new client considers the role of designer to be analogous to that of an aesthetician: the person responsible for adding “color” to an interface. Communicating my role in terms of value signals that I think broadly. It raises expectations.

Key channels: stop waiting for recognition

The third realization I had when filling out the canvas was that I was often waiting for people to become curious about what I did instead of communicating my own value. Channels are the methods we use to communicate to customers. They afford three things:

  • Awareness of the value we provide. They allow us to spread the word about what we can offer (and listen to others to see where its needed most).
  • The value itself. Channels allow us to deliver the value we promise.
  • Customer support after we’ve delivered our value.

Most importantly, this exercise helped me realize that I needed to start doing things resonated most with each of my customers. To that end, I might:

  • Demo something I did in the company demo meeting and talk about the value to developers
  • Share a usability test recording
  • Make a cheat-sheet of my activities’ benefits for the sales team, or
  • Write articles about our process for the company website so clients could learn more about what UX means for business

Making the sale

To there you have it: the business model of a UX Team of One. Selling UX – especially within an organisation – is a complex topic. Whole books have been written on the subject. The three insights above resulted from reconsidering my value and what I could improve on.

I eventually came to realize I needed a plan for communicating value to different groups of people I work with, and that I had to stop waiting and start doing. I also came to accept that there were areas in which I needed help – such as translating my reasoning for UX activities into business terms. I’m currently working on writing out all these benefits, with the help of an experienced consultant.

The business model canvas hasn’t made my job any easier to do, but it has helped me prioritize. Communicating value is a journey. I recommend filling out the canvas for yourself and seeing which boxes are most difficult to fill (yours might differ from my 3 key learnings) or with which you could use some help. I have no doubt you’ll find the result rewarding.

Related resources

On UX within organizations
On UX benefits
On the Business Model Canvas

The post A User Experience Business of One appeared first on UX Booth.

Sponsored post

May 29 2013


Open Device Labs: Why Should We Care?


With all of the different smartphones, tablets and other devices that sport various operating systems and versions thereof, a Web developer’s job — testing (sometimes virtually) on multiple devices to resolve errors — hasn’t become any simpler. This article suggests how we can manage these tasks without pouring a truck-load of money into actually buying all of these different devices.

A user tests his website on a Blackberry device and takes notes of bugs.

Do You Test On Actual Devices?

Whether you develop websites or apps, you face several problems in ensuring that a product runs correctly on as many devices as possible. Emulators for iOS, Android, Opera and the rest can help with that, but they differ from the software that runs on real devices. One of the things you just can’t simulate properly is touch interaction. Without being able to test gestures, there is no way to find out whether your users will understand how to use your interface. Because this is unlikely to change anytime soon, there is no way around testing on real devices.

While most developers probably have a smartphone and a tablet at home, two devices cover only a fraction of the types of devices and operating systems available — devices and operating systems that you should be testing your projects on. There are dozens of screen sizes, browsers and display types, and they make a huge difference when you’re fixing bugs in a responsive design. Despite your CSS and JavaScript being valid and well written, malfunctions on some mobile devices will occur simply because the variety of rendering engines haven’t been sufficiently standardized.

Testing touch gestures on different devices.

Some errors you would probably never notice because they appear only on devices that are uncommon in your country — but may be common in others. Thus, buying a lot of devices for testing seems to be an obvious solution. But that leads to two major problems: buying all of these devices would become very expensive (and you probably would not use them regularly anyway). Secondly, remote debugging on a wide variety of devices is not that simple. Fortunately, this has become much easier with all of the tools available today, but you still have to deal with it.

Crowd-Sourcing Makes Life Easier

This is where crowd-sourcing comes in. No one needs all of these devices every day. In fact, most developers need them only every few weeks.

Instead of every developer buying them all, what if there was a place where people could share devices for testing? If each person purchased a single device, you might already have enough to set up a device lab — which would save you a lot of money. The bigger the community of people contributing to this lab, the larger the variety of devices to test on. Even better, the community could even ask manufacturers to provide their devices to the lab, thus saving you even more money. Thus, access to mobile devices and a great testing space would be made available not just to you, but to everyone.

The Open Device Lab initiative aims to do just that. Currently, there are more than 50 locations around the world where a developer can go to test their project on multiple devices (some labs have more than 80 in stock). Most are completely free to use, while a few charge a small fee to cover the cost of running the lab. Because open device labs are meant to be non-profit, this is a fair deal and still much cheaper than buying the devices on your own.

A co-working space can be a nice surrounding for an Open Device Lab.

The people behind the labs range from individual developers who establish labs in their local co-working spaces to agencies that open their doors to share their hardware and knowledge with everyone. Different labs focus on different types of development: some on websites, some on apps, others on operating systems. Most have rules on using the lab. In general, you will want to make sure that installing your own software or wiping a device is OK.

Most sites cover a wide range of mobile manufacturers. In general, open device labs aim to supply at least the devices most used in their area. To check which devices are available in your area, search for a lab and check the list of manufacturers.

Many labs also provide development tools, such as Weinre, Adobe Edge Inspect, JS Console and Remote Preview, as well as platform-specific tools, such as the Safari Web Inspector. Remote inspection might be set up in some labs so that you can test and debug your websites from your computer, while some labs will have helper tools to enable you to test a product synchronously on all devices and debug individually. Each lab has its own features, so check to see whether the one near you meets your needs.

While Remote Preview will display a website on different devices, JS Console is just a remote console for your website. Weinre and Edge Inspect allow for remote inspection through a WebKit inspector and synchronized browsing, but they only run in the embedded Web view of the OS.

The labs also address Wi-Fi issues that occur with normal routers when more than an 40 devices are connected to the network. People have already solved problems that would normally drive you crazy, and they are happy to share their solution with you. And you can do the same by sharing your knowledge with others.

Many labs are built in existing co-working spaces, which makes it easy to maintain and access them. Another advantage of this is that you can schedule your time in the co-working space to coincide with when you will need to test extensively.

A user takes notes about viewing his website on a Blackberry.

Help Yourself And The Community

You can benefit a lot from such spaces. When you’re tackling a particularly tricky problem, the lab very likely has people who can assist you.

But make sure to help others when they ask for it. Developing websites together is much more fun and, from my experience, produces better results. And when you deliver great work, other people will notice and will consider hiring you for future work.

Support Open Device Labs

Because open device labs are built by the community for the community, it is very important that users give a little back. Doing this is rather simple. Most people have old devices at home. If you do and don’t need them anymore, consider donating them.

Secondly, offer some spare time to maintain a lab or at least spread the word among your colleagues. All of these little things help labs to grow, in turn helping developers like you all around the world.

The Open Device Labs website has a map of all existing labs. You can see how many devices are available and from which manufacturers, and you can read and give feedback on each lab. Thus, you can easily find a lab that fits your needs.

Viewing your product on various devices at one place makes it easy for you to identify problems.

Nonetheless, many more labs are needed around the world, as shown in the world map. The demand is worldwide, but many people don’t know that such labs exist or how easy starting one actually is. Labs flourish with enough supporters, and the more supporters in a region, the better a lab gets. So, help to build these spaces, and tell others about the movement.

An API enables easy access to information about all of the labs. To open up your own lab, the non-profit organization LabUp will support you by providing relevant information. You can easily build a website for your lab, and keep basic information about the lab up to date using the API. It is CORS- and JSONP-enabled, so you can access it right from your own domain. The documentation describes what kind of data you can access with the API and how to implement it on your website.

Create An Open Device Lab

Open device labs are a new movement, so you might not find one near you. But filling the gap is easy. Just search for colleagues in your region, connect with them, build the lab together, and move the Web forward! If you work at a company that owns a lot of devices, creating an open device lab is especially easy. But creating one wouldn’t be much harder for a freelancer. LabUp will be happy to help you establish a lab by giving you tips on setting up the technical aspects and by connecting you to device manufacturers.

If you’d like to spearhead a lab in your area, taking care of the following details will give you a good start:

  • Make the space open and freely accessible.
  • Create a pleasant interior so that people look forward to coming.
  • Provide some devices at launch, and invite contributions or sponsorships.
  • Make sure the Internet connection is fast and reliable.
  • Build rock-solid Wi-Fi.
  • Install stands for the devices.
  • Secure the devices so that they don’t get stolen.
  • Coordinate people to run the lab when it’s open. (And consider keeping it open for long hours).
  • Find ways to reduce costs for you and the lab’s users.

In short, seriously consider creating, maintaining or supporting an open device lab in your area.

Open Device Labs often have a lot of different devices to test on.

More Resources

All images by Open Device Lab Nuremberg.

(al) (ea)

© Anselm Hannemann for Smashing Magazine, 2013.

May 21 2013


A Taste of Confab 2013

“Content is king.” It’s been the prevailing trend the past few years, but at Confab – a conference of Content Strategists – attendees seek more than just trends; they seek stories. UX Booth editor and resident content strategist Marli Mesibov reached out to some of the strategists speaking at this year’s Minneapolis-based event to learn more about what’s driving their current narratives.

When I first walked into Confab in 2012, I felt as though I had finally found home. During their workshops and talks, speakers discussed the “hows” and “whys” of writing, rather than merely the benefits of having content. They talked about writing from the perspective of thinkers – journalists, creative, researchers, and readers – instead of merely dwelling on its marketing value. It was a whole new world, connecting writing to design, turning copy into content.

It’s no wonder, then, that I’ve been looking forward to Confab 2013 since the day I left the event. And now that it’s only two weeks away, I can barely contain my excitement! In the weeks leading up to the event, I’ve begun conversations with this year’s speakers in order to learn more about areas of content strategy we don’t often hear about. Jonathan Kahn and Melanie Moran share their stories.

Digital Governance Fails Because We’re Afraid of Cultural Change

Let’s begin with Jonathan Kahn. He’s a busy man. Jonathan organizes events (Dare Conference, Confab London, London Content Strategy Meetup), presents worldwide (Webdagene Oslo, CS Forum Paris/Cape Town, IxDA Dublin), and writes extensively (A List Apart, Contents, lucid plot) about the revolutionary changes facing organizations, and why it’s so hard to overcome them.

With a background in web development, he’s also worked as an information architect, user experience consultant, and content strategy advocate. Jonathan is the Principal of Together London. He shared the story leading to his presentation, Digital Governance Fails Because We’re Afraid of Cultural Change.

For most of my career I told myself I was a firefighter, rushing in at the last minute to fix screwed up web projects. Recently, though, I discovered why I told myself that story: I was avoiding the scary part of my work, the difficult questions.

Today, things are different. My interactions with the content strategy community have helped me craft a new story, and it goes something like this:

  1. The internet puts new demands on our content. Customers expect useful, usable content across channels and devices, all the time.
  2. Organizations (usually) aren’t setup to deal with this reality. People avoid talking about content because it’s messy, political, and hard to do well.
  3. So our content is a mess, and nobody takes responsibility for fixing it. This creates problems for both the business and the customer. It also drives us crazy.
  4. Content is important, damnit! It’s a business asset. Content strategy provides a way for us to fix these problems, helping us spread the word about the value of content throughout the organization and around the world.

The content strategy story is all about asking hard questions: What content do we have? Is it any good? Why do we need it? What’s our messaging architecture, our voice, our tone? Which other departments do we need to work with? How can we create a sustainable plan for commissioning, editing, publishing, and maintaining content over time?

This story is a framework for making content strategists vulnerable. Brave. Able to put more of ourselves into our work. At the same time, there are ways in which this story can be limiting. To understand why, it’s important to discuss a challenge that almost all content strategists face: governance.


Governance includes the standards, policies, and procedures made to allow an organization to care for its digital operations over time. In theory, a governance plan ensures our content strategies stick, but it rarely works. Writers don’t follow our voice guidelines, marketers ignore our message architectures, and developers create apps without considering the complexities of content.

We’re doing good work, but it isn’t sticking, which feels like a terrible waste of time. Why won’t people follow our guidelines? Recall the first point I made in the content strategy story above: “the internet puts new demands on our content.” While that’s true, we’re scared to ask the obvious follow-on questions:

  • Why does the internet put new demands on our content?
  • Why is the business environment changing so quickly?
  • What does that mean for our business models? our siloed organizational structures? our “waterfall” development process? the software we buy? the agencies we hire?

These questions terrify us because we’re afraid to face the truth: content strategy is just one piece of the challenge of digital transformation. Our governance attempts fail because we’re working backwards: governance can only sustain culture, it can’t create it.

So what does governance look like when backed by the notion of digital transformation? To make our organizations sustainable, we need to change culture in a way that’s broader than content strategy, incorporating practices we know little about: service design, agile development, and cross-functional teams. Once we understand this, we can start changing our organizations’ culture, today.

Readers can learn more about how to affect a cultural change within their organization by attending Jonathan’s talk. It’s happening at 2:50pm on day two of Confab Minneapolis.

Content Strategy in Higher Education: Uniting Print and Web

Next we hear from Melanie Moran. Melanie is the Director of Integrated Communications at Vanderbilt University. Her presentation this year, “Content Strategy in Higher Education: Uniting Print and Web,” highlights her team’s year-long, ongoing journey towards cohesive, cross-platform storytelling.

She’s looking forward to learning from content experts from many different sectors and bringing home a passel of great ideas. In the meantime, she shared the thought-process leading to her presentation.

I’ll always remember when the light bulb went on for me – when I learned the importance of content strategy. I was sitting in a meeting of campus communicators at Vanderbilt University. I had just returned from conducting an hour-long interview with a faculty member, a professor whose research explored neuroscience and education. I needed his thoughts to inform a story I was writing for the web.

Just then, across the room, a colleague from another office reported that she, too, was writing a profile of a faculty member – for one of our print magazines. And wouldn’t you know it, it was the same guy. She had conducted the same research and was writing the same article.

This is crazy, I thought. Why was web not involved in planning for digital content to support print stories? From that moment forward, my colleagues and I began seeking ways to shake content out of its container – be that container print, web, video or even a press release. It eventually paid off in more innovative storytelling, expanded social media impact and a more strategic use of print.

How did we do this? Here are some of the key elements that informed our content strategy:

  • Story first

    Forget the deadlines; forget the Facebook and Twitter beasts that need to be fed. Forget about that for just a minute and ask, why is this a great story? You can have the most interactive website or jaw-dropping magazine around and no one will read it if the stories are lame. Story first, always.

  • Exploit the platforms

    Now that you’ve got your story, think about the many ways to tell it across different platforms. What is told with a photo or graphic on Facebook can then push to a feature on your website; can be explored in detail in your print publication; can be told via a video on YouTube. You get the idea. This will likely mean writing different headlines, using different images and even showcasing different parts of the story for different media – but that’s okay. Let go of the need to show everyone everything on every platform and disaggregate the story for maximum portability.

  • Strategy, not reflex

    We all know the perils of the “we’ve always done it this way” mindset. And I know it’s 2013 and many of us have already mourned and moved on from print, but for many people it remains a relevant, effective way to reach their audience.

    Vanderbilt’s alumni magazine, for example, lives in the homes and offices of alumni around the country and world. Its physical presence connects them directly with Vanderbilt through dynamic storytelling and gorgeous photography and illustrations. We support this connection heavily with digital, of course, but print remains an important and compelling component of our strategy.

  • Analytics, analytics, analytics.

    It was beautiful, it was epic. You laughed, you cried. …but did anyone read it? How was the social media engagement? Did it drive traffic back to your website? Picked up by media? Put yourself on a pretty strict plan of analytics tracking and use it to refine your content strategy. Then share what you find with decision makers, as data drives most organizations. Being able to provide it in relation to communications will elevate others’ understanding your work and the impact it has on your brand’s strength and reputation.

Readers interested in learning about cross-channel storytelling should join Melanie Moran at Confab Minneapolis. Her session begins at 9:40am on day two of the event.

See you there?

So, there you have it. Confab Minneapolis begins on Monday, June 3 and – in addition to Jonathan and Melanie’s – the workshops and talks range from content measurement and modeling to creating content in a zombie apocalypse.

As always, Confab features a mix of well known and up-and-coming content strategists. I’m particularly looking forward to Catherine Toole’s “Four Weddings and a Funeral” and Sara Wachter-Boettcher’s “Write Like a Human, Think Like a Robot.”

Who are you looking forward to seeing?

The post A Taste of Confab 2013 appeared first on UX Booth.

May 06 2013


New Defaults In Web Design: How Much Has The Web Really Changed?


Responsive design is about more than just layout; it’s about designing for the Web, which means, mostly, for people with browsers. And that’s just about everything we know about the people who visit our websites: they are probably using a browser. All the rest we just don’t know.

Up until not so long ago, we used to base our designs on some rather general assumptions about screen size and input type. With the rise of devices with various screen sizes and alternative ways to interact, these assumptions have turned out to be unreliable. We need to upgrade the defaults that we use when we start designing our websites.

A Closer Look

People keep saying that the Web has changed. But has it really? Let’s take a look at all of the things that have actually changed.

Screen Sizes

In the 1990s, the Web was 640 pixels wide. In the early 2000s, it grew to 800 pixels. A few years later, we decided it should be 1024 pixels. But five years ago, all of a sudden, something strange happened. A device with a very small screen entered the market. Suddenly, our ideas about the size of the Web did not work anymore. Later on, tablets entered the market. People hold these things however they want. Today, the height of the viewport could be bigger than the width! But is that new? Not really.

Screen sizes, shown in a non-flexible medium. Photo and work by Aram Bartholl.
Screen sizes, shown in a non-flexible medium. (Photo and work: Aram Bartholl)

We never really knew what size the window of our visitors would be. We just assumed it was at least the random pixel width that we felt comfortable with. These numbers were always arbitrary, and there were always people who could not see the entire website. We simply ignored them.

“Everyone Has a Mouse”

We’ve always assumed that everyone uses a mouse. Even though we knew that this was not always true, most designs completely ignored alternative ways of interacting. People who had to use a keyboard, for whatever reason, had a very hard time interacting with our websites.

But because most people did use a mouse, and because back then many designers thought that designing only for the majority was OK, we created websites that were unusable for a lot of people. And this turned out to be a growing number. Many mouseover interactions are completely dysfunctional on a touch device. Because people love these devices, and even managers and designers use them, they are harder to ignore.

“Everyone Has Broadband Internet”

Another thing we always assumed was that everyone had a super-fast Internet connection, at least as fast as our own. And if they didn’t already have it, they’d have it soon. This was again mostly true; speeds were increasing. But today, more and more people use crappy, unreliable 3G connections all the time. If you’ve ever travelled on a train in The Netherlands, you know what I mean. And if you’ve ever had to rely on the mythical “free hotel Wi-Fi,” then you know for sure that the assumption about the ever-increasing speed of our Internet connections is just not true. This is a big change in our thinking; we really should consider these users. This will have a major impact on what our designs look like.

“Everyone’s Computer Gets Faster Every Year”

It used to be true that computers would get faster and faster. If you waited half a year before buying a computer, you would get one that was twice as fast, for the same price. This was true of new desktop computers, but mobile devices have priorities other than processor speed. The most important thing for a phone, for instance, is battery life: you really don’t want to have to charge it after every phone call.

And there’s another trend: instead of creating ever-faster devices, many manufacturers are starting to sell ever-cheaper devices. Many people care about price and battery life more than about processor speed. This is also not new: what happened to your old computers? You probably sold them or gave them away. People keep using old stuff. Not everyone has the same hardware as we designers do.

“All Monitors Are Calibrated”

Well, we always knew this to be untrue, right? Only the monitors of visual professionals are calibrated. Most other monitors don’t display colors accurately, and many monitors are downright crappy. Most mobile phones that I’ve tested have pretty decent screens, until you start using them outside, in the sunshine. If you’re lucky, you can read the content, but you definitely cannot see the subtle gradients in low-contrast designs.

I haven’t even mentioned “modern” black and white screens. These, too, are not new. People have always used crappy monitors, and people with bad eyesight have always visited your websites. It’s just that more and more people are seeing a subpar color palette. Instead of buying a state of the art monitor, buying a cheap monitor and several low-end devices to test your work on might be a better investment.

All of these things are not new. In 2002, John Allsopp wrote the monumental article “A Dao of Web Design.” People such as Jeremy Keith and Roger Johansson have written about all of these facts for years and years. And yet, somehow, we’ve always managed to actively ignore them. But we really can’t anymore. The Web actually did change in the last five years, with new devices, new browsers and many, many cool new features. We need new defaults. The old ways of creating websites just don’t work anymore.

This Is Responsive, the excellent resource about responsive design by Brad Frost.
This Is Responsive, the excellent resource about responsive design by Brad Frost.

In the past few years, we’ve been actively researching new ways to deal with all of these different screen sizes. But apart from responsive design, there are many more challenges in today’s ever-growing pile of devices. We have to find new patterns of interaction: we need interfaces that work on any device. Maybe we have to reconsider that enormous photo carousel on the home page, now that we know that not everyone has a cheap and fast connection. New defaults are emerging, and I’ve collected a few for you here.

The things in this article are not new. Many clever people have written about them in many articles and many books. But these ideas, like all good stories, have to be repeated many times so that people understand and remember them.

New Default: Activate

I initially titled this section “New Default: Touch.” But I came to realize that “touch” has a different meaning for everyone. Some people, like me, think of a single tap when we hear the word. Others think about swiping and complex gestures. That’s why I settled on the heading “New Defaults: Activate.” All devices, no matter what kind of input they offer, let the user activate something in some way.

With a mouse, it’s a click; with a touch device, it’s a tap; on a keyboard, it’s the “Enter” key. There are ways to activate things by voice, and by waving your arms in the air. And many devices offer more than one way to interact. The only thing that all of these devices have in common is the action of activating. Most of them are capable of doing many other things, too, but all of them can activate stuff.

Only recently have we really started thinking about alternative methods of user input. We used to assume that everyone uses a mouse. Hiding content and showing it on mouseover was considered to be a decent design pattern. And it used to work for most people — until all of these wonderful touch devices entered the market. What should a device without a mouse do when content can be revealed only with a mouse? Different devices have different solutions. Let’s look at a simple drop-down menu.

You can find a live example of this navigation pattern right here.
See a live example of this navigation pattern.

When you hover over a menu item, a submenu appears. But apart from hovering over an item, you can also simply click on it to follow the link. Now, what should happen when you tap on the item with a touch device? Should the submenus appear, or should the link activate? Or both? Or should something else happen? On iOS, something else happens. The first time you tap a link like that, the submenu appears; in other words, the hover event fires. You have to tap a second time to actually follow the link. This is confusing, and not many people will tap a second time. On Android, the submenu appears and the link is followed simultaneously. I don’t have to explain to you that this is confusing.

It’s very well possible to think of complex solutions whereby you define different interactions for different input devices. But the better solution, I think, is to make sure that the default interaction, the activate event, just works for everybody. If you really need to, you could choose to enhance this default experience for certain users.

For instance, if you are certain that someone is using a mouse, you could enable some mouseover interactions. Or if you’re sure that someone has fat fingers, you could make small buttons a bit bigger. But only do so in addition to the default activate interaction, and only if there’s no doubt about it, and only if the enhancement would really make things better. Those are quite a few ifs, and some of them, such as the mouse usage, are very hard to detect — especially on devices that offer more than one way to interact, such as a laptop with an optional mouse, touch pad, camera, microphone, keyboard and touchscreen. Give it some serious thought. Do you really need to optimize for a mouse?

New Default: Small Screens

Growing is easy. Most things grow. Babies grow, trees grow, curious minds grow. They don’t grow by themselves, but you don’t need much energy to make things bigger. This is just what things do when they live. While shrinking things is definitely possible, it’s also much harder. You could, for instance, compress a car to a fraction of its original size. A compressed car does have a certain aesthetic appeal to it, but it is definitely not as useful as it was before. The same goes for websites. Shrinking a desktop website does not always result in a pleasant experience on a small screen.

Trees grow on their own, cars are less usefull when they shrink.
Cedro di Versailles by Italian artist Giuseppe Penone clearly shows that things grow. On the other hand, the work Papalote Goliad by American artist John Chamberlain shows that shrinking can be aesthetically appealing but may result in less useful results.

To build a responsive website that works on all kinds of screens, designing for a small screen first is easiest. It forces you to focus on what’s really important: if it doesn’t fit in this small square, it is probably not terribly important. It forces you to think better about hierarchy, about the right order of components on the page.

The same principle that we follow for interactions — whereby we design the activate event first and enhance it later — applies to graphic design. We should start designing the things that we know everyone will see. That’s the content. No matter how big or small a screen is and no matter how minimal the feature set of a browser, it will be able to show letters. Because this is about the only thing we know for certain — since color is absent on most Kindles, most of the latest CSS doesn’t work on old browsers, and layout is of minor importance on small screens — starting with the text is logical.

I wrote an in-depth article about defining breakpoints on the basis of typography, so I won’t repeat every detail here. But the basic idea is that you start by designing the relationship between the different font sizes. Almost everyone, no matter what device they have, will be able to see this. When the typography is done, you would start designing the layout for bigger screens; you can think of this as an enhancement for people with bigger screens. And after that, when the different layouts are done, you could add the paint. And by paint, I mean color, gradients, borders, etc.

I’ve presented this as a very strict way of working; in real life, of course, things are not as rigid. I’m not talking about “activate only” or “small screen only.” When I say to start with typography, I don’t mean that you aren’t allowed to think about paint at the same time. Rather, I’m trying to find the things that all of these different devices, with all of their different screen sizes and all of their different features, have in common. It just seems logical to first design this shared core thoroughly. The strange thing is that this core is often overlooked: Web professionals tend to view their own creations with top-of-the-line devices with up-to-date browsers. They see only the enhancements. The shared core with the basic experience is often invisible.

New Default: Content

The way we designed our websites until recently was by putting a header with the logo and navigation at the top, putting the subnavigation on the left, putting some widgets on the right, and putting the footer at the bottom. When all of that was done, we’d cram the content into the little space that was left in the middle. All of the things we created first — the navigation, the widgets, the footer — they all helped the visitor to leave the page. But the visitor probably wanted to be there! That was weird. It was as if we were not so confident in our own content and tried our best to come up with something else that our guests might like.

But rather than pollute the page with all kinds of links to get people out of there, we should really focus on that thing in the middle. Make sure it works. Make sure it looks good. Make sure it’s readable. Make sure people will understand it and find it useful. Perhaps even delight them with it!

Once you’re done with the content, you can start to ask yourself whether this content needs a header. Or a logo. Or subnavigation. Does it need navigation at all? And does it really need all of those widgets? The answer to that last question is “No.” I’ve never understood what those widgets are for. I have never seen a useful widget. I have never seen a widget that’s better than white space.

A typical news site with more attention for widgets versus the complete focus on the content on Medium.
Compare a typical news website’s attention to widgets with Medium’s complete focus on content.

By starting with the content first, you can come up with some very interesting solutions. For instance, does the logo really need to be at the top of every page? It could very well go in the footer on many websites; such as in digital style guides or on pages for registered users. Many links that we used to put in the subnavigation might work better in relevant spots in the main content.

For instance, the option to add extra luggage to a flight booking might be most effective right there in the overview of the flight, instead of in the middle of a list of links somewhere on the left of the page. And when looking at the hierarchy of a page, does the main navigation look more important than the main content? Most of the time it shouldn’t be, and I usually consider the navigation to be footer content. A simple “skip” link at the top of the page could either take the visitor to the navigation or fetch the navigation and show it at the top of the page.

In this era of responsive Web design, we need many new clever solutions. As we’ve seen here, our old defaults don’t work anymore. We need to reconsider how we work with interaction, how we approach design and how we shape our content. But we need to think about one other very important thing, and that is where our content comes from.

New Default: The API

Luke Wroblewski wrote a fantastic article about designing an application for the command line first, and then enhancing it for different needs. This is not just a nerdy idea, but a very practical idea, too. If you are able to design and develop your own application, you could test the functionality relatively easily before even starting to think about what it will look like on different devices. This requires designers to work with developers to design a feature that at first works only from the command line. If the feature does not work as expected, then you merely have to change the API, rather than also a bunch of visual designs. Once the API works as you want it to, enhancing it for all of the devices and screen sizes that you want to support becomes easier.

Most of the time, you wouldn’t design the entire API of the application that you’re building. Most companies would choose a content management system (CMS) of sorts or a specialized tool to help them achieve what they want to do. I’ve always been amazed that CMSes are so often chosen only by technical people and business people. This causes many problems during the design process.

Developers and business people have different goals than designers. Developers want stuff that is easy to develop on. Business people want stuff that’s cheap. But designers want to make the best and most beautiful things possible. These goals can easily conflict.

I’m not saying that designers alone should choose the system, but they should definitely be a part of the decision-making process. I’m convinced that the selection of CMSes will improve. And I’m convinced that CMS makers will start to improve their products once designers get involved. Right now, all CMSes I know of deliver hostile cruft unless you tweak them extensively.

But it works the other way around, too. If designers are involved in the selection process, they will have a say in the choice of tool and will understand how it works, what’s possible, what’s easy and what’s hard. This will result in designs that are based in part on the tool, not just on imagination. This is an important part of the design process that has not yet been optimized. Right now, the command line and the systems that deliver the content we design for are the domain of the developers, and designers have nothing to do with them. That is a pity. Just as you would want to take advantage of the knowledge of developers in the design process, you would want to take advantage of the knowledge of designers in the development process.

Progressive Enhancement

If you review the sections above, you’ll see that what I’ve described is nothing other than progressive enhancement. You start with the content, then design the content and optimize it for different screen sizes and devices, and after that you can further optimize for very specific features such as mouse usage and fat fingers. Many Web developers build websites according to this principle. They transform the beautiful Photoshop documents that they receive into all of the different layers described above.

This can work out fine if the developer has a good sense of design and a delicate attention to detail. But if they don’t — which is often the case — this can easily result in crappy usability and ugly details. I’m not saying that designers shouldn’t use Photoshop anymore. If that’s your tool, go ahead and use it. But do remember that you’re designing the layers of the Web, not the layers in Photoshop. There’s much more to the Web than a single beautiful image. People will see our creations in innumerable ways. We design for all of these people — remember that. We don’t just design for the CEO with a laptop. We also design for the people on the train and the people with “free hotel Wi-Fi.”


I’ve mentioned Photoshop a few times because it’s still widely misused for designing websites. One reason we have a hard time with progressive enhancement in the design process is due to a lack of good Web design tools. The tools we use are built to wow; they mostly help you to create the “paint,” not to design the core. Fortunately, more tools are popping up with very specific functions in the design process. These are micro-tools such as the International Measure Slider, which helps you to define breakpoints in your grid; tools such as Gridset, which helps you to create grids for different screen sizes; and excellent tools that help you to define typography. By incorporating these tools into our design workflow, we might start making better stuff.


The Web has always been a weird, borderless, flexible medium. In the last couple of years, we’ve started to realize that designing for this medium is fundamentally different from the design work we’ve done previously. The fixed dimensions and the singular ways of interacting that formed the basis of all types of media that we’ve worked with for centuries just don’t work on the Web. This truly is a unique medium.

We have to find new defaults, new starting points for our design process. I’ve explained some of these new defaults here, but of course there are many more. The way we work with forms, for instance, could probably use a whole series of articles by itself. Some new starting points are well established by now, but I’m sure many more will be invented in the near future. I am curious to hear about new patterns and new defaults that you have discovered and have used successfully in your projects.


© Vasilis van Gemert for Smashing Magazine, 2013.

April 22 2013


Is Photoshop Really Dead?: Repurposing Photoshop For The Web


Like any overzealous teenager aspiring to be a Web designer back in 1999, I found myself in an “Electronic Design” class, behind the wheel of one of those old-school aqua iMacs. If you found yourself in a similar situation, chances are you were given Adobe Photoshop as your vehicle for designing the Web. For me, it was version 6.0.

No matter which version you had, undoubtedly you know someone who can “trump” you by having adopted an earlier version. We designers take much pride in this, in case you hadn’t noticed.

One of these is likely nostalgic to you.
One of these likely makes you nostalgic. (Image: Design You Trust)

It’s not a stretch to say that Photoshop was once regarded as the quintessential Web design tool, a sign that its fandom reached more than just photographers. Refrigerator magnets, pillows and even tattoos have shown homage to the unmistakable UI. Let’s face it: Photoshop is the software we’re identified with, and its place in Web design history is substantial.

I was careful to choose the word “history” there because that’s what it’s seemingly becoming.

Falling Out Of Love

Yes, unlike anything else in the realm of Web design, we collectively have a love-hate relationship with Adobe’s flagship software. While we love it for the common aptitude and experience we share, we hate it for its shortcomings. The pain points of using Photoshop to design for the Web are well documented and support the staunch anti-Photoshopian’s cause to remove it from their process. In fact, complaining about Photoshop has become so commonplace that it’s not just a rite of passage, but rather the signature of a true Web designer.

As our needs changed, Photoshop couldn't quite keep up.
As our needs changed, Photoshop couldn’t quite keep up. (Image: Derrick Diemont)

The Software’s Pain Points

  • Crashes
    True story: about 95% of instances of Mac OS X’s beach ball (or, as I affectionately refer to it, the pinwheel of doom) occur while using Photoshop. OK, so I can’t back that up with actual data, but I venture to say this is a common experience, especially for those of us attempting to “Save for Web.” Familiar with that nauseous feeling you get when the program hangs and you haven’t saved in a long time? Yeah, that alone makes you rethink using Photoshop.
  • Text rendering
    I’ve always found rendering the most basic of fonts as anything like the browser ends up doing to be incredibly difficult for Photoshop. Helvetica ends up looking like a mess, and coming close usually takes much tinkering with a few settings. This wouldn’t be problematic, except that the goal of comping is to show an accurate representation of what a website will look like.
  • Lack of interactivity
    At the end of the day, designing static comps doesn’t adequately translate how elements are intended to behave through interaction. When presenting comps to the client, discussing these points is possible, but that’s less than ideal for complex interaction. I’ve found myself using terms like “If you can imagine…” far too often in an attempt to show something as simple as a hover state.
  • Expense
    While we hem and haw over whether to buy an icon set for $5, realize that Photoshop is far and away the most expensive piece of software in the common Web design toolset. A new purchase of it will run you $700 USD. Upgrades help, and Creative Cloud has been nothing short of genius, but the investment in Photoshop is still monstrous compared to that of wireframing tools, code editors and FTP clients.

The Process’ Pain Points

  • Expectations
    The environment of Photoshop provides complete design control, because every pixel we manipulate can be exported to our expectations. When we actually develop for the Web, browsers aren’t as predicable (I can think of one in particular that’s none to kind, but I digress). No manner of fixes or hacks will produce an exact match of our Photoshop comp.
  • Presentation
    When attempting to convey responsive Web design, presenting static comps of full pages is less than ideal. The options are few and difficult: create numerous sizes of a single page, or try to explain verbally how a design will shift. I find neither to be practical or completely accurate, because innumerable device sizes are in the wild.
  • Double the effort
    A Photoshop comp is a visual representation of what a website or app could be, but not a functional one. This becomes problematic in the scope of effort required, with a comp being produced and then reproduced through Web technology (HTML, CSS and JavaScript). Additionally, the detail of the production is quite considerable — static comps are typically pixel-perfect and fully fleshed out, and front-end development carries the same goal.
  • The big reveal
    Ever worked hard on a design, spent hours polishing that last drop shadow on a button, exported a JPEG and then gotten nervous five minutes before a meeting because you have no assurances on whether the client will even understand the comp, much less like it? That’s true with many presentations, but the Big Reveal exacerbates this feeling. When your design process doesn’t include sharing any work in progress when comping, naturally it will lead up to a huge moment when you finally tell them to open a file or click a link. Wouldn’t it be nice if the client was involved in style-related decisions earlier than this?

Photoshop Misunderstood

Is it really a battle between tools?
Is it really a battle between tools?

OK, I think we’ve thoroughly bashed Photoshop enough at this point, although it’s important to realize where your tools fall short so that you can adapt (if you haven’t already). While there are plenty of jimmy-rigged workarounds to the aforementioned pains, and the right combination of settings will potentially ease those pains, there should be an easier way.

The most significant response has been to design directly in the browser. CSS3 provides many of the style elements that we had in Photoshop (such as rounded corners, drop shadows and gradients), and preprocessors such as LESS and Sass are great ways to speed up our workflow. These have become so popular, in fact, that there’s been much clamoring about trashing Photoshop altogether and using HTML and CSS exclusively, from start to finish.

Let’s not go overboard, right?

An important distinction is made by some designers that’s worth noting: the browser is the delivery vehicle of our designs, while image editors serve the purpose of creative exploration. Just because we have the ability in code to replicate what an image editor can output doesn’t mean it’s always the best environment for it. Those of us who learned Web design through Photoshop (or Fireworks) find value in being able to transform design elements without the abstraction of a text editor and, for the most part, have gotten quite good at it.

“As such the browser lacks even the most rudimentary tools like the ability to draw lines or irregular objects through direct manipulation.”

Designing in the Browser Is Not the Answer written by Andy Budd.

The notion that image editors have no place in our workflows is also faulty in this regard: we’ve purposed them to have a particular and quite heavy focus in our workflow. We’ve used Photoshop as the canvas for our design, when it’s apparent that the browser is better suited because it’s ultimately where the design will live. However, Photoshop still has worth, and arguably much worth, in our processes, just not as the canvas. Confused? That’s OK. I’ll explain.

A workflow you may be familiar with is such: sketch, wireframe, produce the visual design in a graphics editor, develop said design in HTML and CSS. Skipping Photoshop assumes that we “design” in the HTML and CSS phase. The tricky part in doing that is determining what a suitable design deliverable is, which we’ll get to momentarily. Naturally, the question becomes, What do we do with Photoshop, now that we’re in the browser?

Photoshop as a High-Fidelity Sketch Pad

What if Photoshop were used as a hi-fidelity sketchpad?
What if Photoshop were used as a high-fidelity sketch pad? (Image: Kyrie Eleison)

I propose that an image editor is still handy when executing design via HTML and CSS, and it has everything to do with sketching. An essential part of the “old” way, where we produced the design comp in Photoshop, is that we were allowed to experiment in a “visual” environment. Photoshop allows you to directly manipulate the very foundations of design: line, shape, text and color.

While HTML and CSS are great for executing the design, experimentation is abstracted because code isn’t directly manipulating any design foundation. It’s a layer removed. This isn’t to say that good design can’t come from a code-only approach; rather that the experimentation of design finds a natural home in an image editor, which may be helpful to many of you who, like myself, prefer such an arena.

Consequently, I’m in favor of a yin and yang approach, leveraging Photoshop for what it’s good for (experimentation), and code for what it’s good for (implementation). For me, leaving one out of the party makes it difficult to be creative and practical when designing. Avoiding code and producing full-page comps in Photoshop, while great for some, gives me headaches when considering responsive Web design and having to reproduce entire pages again in HTML and CSS. However, skipping Photoshop altogether puts me face to face with the browser for design, which works for some elements (navigation bars, blocks of text), while other elements pose a creative stumbling block (“hero graphic” banners and their headlines, sidebar calls to action).

It’s a balancing act. I don’t think you can say, “Design everything in the browser,” just like you can’t say, “Never get into the code.”

– Jason VanLue

For today’s Web design process, I view Photoshop as a high-fidelity sketchpad: expensive, I realize, but it does everything we need it to and we’ve used it for ages. It’s a tool that we’re quite proficient and efficient at. Whereas it used to be our literal canvas, Photoshop can now become our “palette,” as the browser becomes the canvas. We prototype designs in the browser, but turn to Photoshop every so often to ideate, and eventually implement those quick creations in code, concurrently.

Are you still using Photoshop as the canvas? Try using it as the palette.
Are you still using Photoshop as a canvas? Try using it as a palette.

“I still use Photoshop, but I use it differently. It’s no longer for prescribing exactly what a site should look like. Instead, it’s used for quick layout exploration and asset creation.”

Where to Start written by Trent Walton.

Getting Responsively Unstuck With Page Layers

A far too familiar situation is designing in the browser and getting stuck figuring out what to do in those strange in-between widths. Confining the content to a single column works for the narrowest width, and your hypothetical wider four-column design gets really squished at 500 pixels or so. I continually find myself in this mode of coding a bunch of potential solutions, none of which looks intentional. Same for you?

Here’s an idea: use Photoshop. I know that everything probably exists in the browser, instead of the full-page comps that we said were so problematic. Who would ever want to build a website only to have to make a version of the semi-finished product in Photoshop? Well, what I’m about to suggest will sound completely backwards. Hang tight!

Page Layers is a unique app that might find its way in to your workflow.
Page Layers is a unique app that could find its way into your workflow.

I’ve gotten used to a tool named Page Layers to do the work for me. I’m sure you’ve heard of PSD-to-HTML tools, but this one is HTML-to-PSD! At first, I had no idea what I would ever use this for. Then it dawned on me that those moments when I’m stuck designing in the browser and would be better off using Photoshop to directly manipulate some things (i.e. without fiddling with CSS) is a perfect use of Page Layers.

Quite simply, you load the website that you’re working on in the app, at the width you’re having some difficulty with, drag the PSD icon to your desktop, and fire it up. The app gives you a PSD with all of the page elements on separate layers, making it easy to experiment with. I’m still getting my head around it, and it’s not without its flaws. Creator Ralf Ebert says that text and vector interpretation is tricky but hopefully on the way.


This might sound good in theory, but what do you show to a client for approval if you’re going to be using a combination of Photoshop “sketches” and the browser? Glad you asked.

Before we delve into methods of delivery, the important lesson in any of them is that the client should be involved in the design process much earlier than they would have been otherwise. To some extent, the Big Reveal can’t be avoided, because any time you present a visual design for the first time, a certain “unveiling” takes place. However, we can focus our clients on specific objectives if we involve them early enough, such as approving the layout in a wireframe or prototype, or approving styles in any of the formats discussed below.

Style Tiles

Style Tiles are based on a concept pioneered by Samantha Warren, who likens them to “the paint chips and fabric swatches an interior designer gets approval on before designing a room.” Designed in Photoshop, they are a variety of visual “tiles,” each containing styles for headings, subheadings, link text, buttons, colors, patterns and backgrounds. In delivering Style Tiles, the focus is on approving style, independent of layout and form (for example, responsive Web design). The emphasis is on iterating to find a suitable style to become the “system” of a website, and not on a pixel-perfect layout that will need to be redone in HTML and CSS. In doing so, a significant amount of time is saved from having to edit multiple full-page comps.

Samantha Warren's Style Tiles are a great approach, leveraging Photoshop for style discussions.
Samantha Warren’s Style Tiles are a great approach, leveraging Photoshop for discussions about style.

For many, this approach keeps the ideation squarely in Photoshop, which is familiar and comfortable. If there’s a knock on this approach, it’s that Style Tiles do require a bit of vision on the part of the client. Granted, setting proper expectations will help to bridge the gap, although for some chains of approval, communicating how the tiles “represent” the final product can be difficult.

Style Prototypes

I hinted at this approach earlier, so here’s an attempt to spell it out plainly. Referring to our wireframes, we begin by identifying which elements and content are crucial to the visual language of the website. For example, the logo, main navigation bar, hero graphic and location-finding widget may all be uniquely styled elements, whereas the main blocks of text and the sidebar links wouldn’t be as integral to the visual impact of the page, per se.

They might look like full page comps, but Style Prototypes just leverage important brand and modular elements.
They might look like full-page comps, but Style Prototypes just leverage important brand and modular elements. (Image: Dave Rupert)

I believe this deliverable should be in the browser and should be responsive. In my experience with using Style Prototypes, I’ve tried not to get hung up on fixing small inaccuracies that occur at certain breakpoints or on cross-browser bugs, because the objective is to gain approval on a design direction. The conversations, both internally and with the client, are steered to assess style only.

The main benefit of this approach is that it generally transitions into the final build of the website remarkably well, yet providing entire pages wasn’t necessary. Photoshop is truly a sketch pad here, because the deliverable is an HTML and CSS document. That said, one disadvantage of this method is that if you don’t define how much you’ll be mocking up, it’s easy to get carried away and include elements that contribute little to the look of the website, using more time and resources than necessary.

Element Collages

Arising from his recent redesign project for Reading Is Fundamental, Dan Mall has offered an interesting approach in Element Collages. Those who feel most comfortable using Photoshop to work out these ideas can simply export a JPEG, while those who feel the browser enables them to better express the ideas can make a prototype.

This format represents how I begin to think about designing a site. I often have ideas for pieces of a site in bursts. A full comp often requires ideas to be fully realized. An element collage allows me to document a thought at any state of realization and move on to the next.

– Dan Mall, “Element Collages

What’s great about this approach is that it brings a comfortable amount of context to Style Tiles by executing those styles on particular elements. If working through ideas in the browser proves to be problematic this early in the process, then Element Collages done entirely in Photoshop are a great alternative to Style Prototypes. Any way you look at it, it’s another approach that circumvents having to make static full-page comps early on for approval.

The folks at Clearleft have employed Element Collages as a RWD deliverable.
The folks at Clearleft have employed Element Collages as a deliverable of responsive Web design.

Whatever approach you use for design deliverables, the idea I’m proposing is to repurpose Photoshop’s role into something that helps you have a discussion of style far removed from specific discussions of page layout and content. Multi-device design dictates that we design systems, not specific page layouts. We can use Photoshop to create reusable assets and ideas simultaneously with browser deliverables such as prototypes. But remember, without setting proper expectations with the client, any new method will become confusing compared to any previous Web design experiences they’ve had.


If the idea is to move quickly between Photoshop and the browser, then Photoshop’s default settings and interface leave something to be desired. Thankfully, a wide range of tools, extensions, actions and apps exist that will help.


Using “Save for Web” can be an arduous process, one that doesn’t always produce usable results. I recommend getting Slicy, which exports your layers to files independently. If you’re using Photoshop to create assets for the browser, this is your tool.

WebInk Web Font Plugin

If nothing else, WebInk's Webfont Plugin will save you a few bucks not having to buy desktop fonts for comps.
If nothing else, WebInk’s Webfont Plugin will save you the few bucks of buying desktop fonts for comps.

Remember when we were knocking Photoshop for its type rendering? What’s worse is that there’s no way to try out fonts from your Web font subscription in anything other than the browser. Thankfully, Extensis’ WebInk service has a plugin that gives you access to its library as you experiment in Photoshop.

Bjango iOS Actions

Unequivocally “the mother lode of time-saving actions,” this list from Marc Edwards will make your life much, much easier. If it’s useful, it’s included: a panel of the most-used Photoshop tools, scaling a document by 200% or 50%, testing for color-blindness and much more. It’s free, so there’s really no reason not to have it.

CSS Hat or CSS3Ps

Until recently, Photoshop didn’t have a way to export CSS attributes for the elements you create (admittedly, Fireworks has, but I digress). If you don’t have the latest version, then CSS Hat and CSS3Ps are solid alternatives. If you do have CS6, the differences between the built-in feature and these plugins isn’t much, although the plugins might take longer to display results and are also more accurate at times.


Famously flat designed, LayerVault boosts production through collaboration.
Famously flat designed, LayerVault boosts production through collaboration.

When Photoshop becomes your sketch pad rather than your canvas, like pages, you can bet more PSDs will be lying around. LayerVault is a great app for collaborating and sharing your ideas before they hit the browser.


If you’re looking to experiment with layout in Photoshop, then the WebZap plugin makes comping incredibly speedy. You can choose from a number of predetermined layouts for elements such as headers, navigation and footers. If you work with Element Collages, WebZap is a great tool for getting down a quick baseline of each element so that you can get right into styling.


It's like an ammo holder for Photoshop.
PixelDropr is like an ammo holder for Photoshop.

Part of being fleet of hand between Photoshop and the browser is creating reusable assets. PixelDropr is a fantastic plugin that enables you to drag and drop assets (icons, buttons, photos, etc.) from a panel onto your document.


For some, static comps are still a viable design deliverable, but they need some basic interactivity. InVision is an app that turns your static comps into “Protocomps.” Even when the comp is just a few elements, using InVision is a quick and efficient way to make it interactive.

Repurposing Fireworks, Sketch, Pixelmator, Etc.

The principle of “refining your tools” certainly isn’t isolated to Photoshop. Any image editor, when used to fit your workflow (instead of vice versa), can be a wonderfully liberating and powerful tool. All Web design apps have their shortcomings, and Photoshop perhaps most famously so.

Yet the fault lies not in our software, but rather in how we integrate it into our workflows. I suppose even when the Ultimate Web Design App comes along, most of us will find something wrong with it. Why? Because we’ve learned to be resourceful and make our tools work for us, whichever tools they are. The right tool, used for the right purpose, at the right time, is more valuable than one that tries to be too many things.

So, Is Photoshop Really Dead?

I could switch code editors, computers, wireframing tools, browser plugins, and more, but I’d be pretty sunk if I had to do a project without Photoshop.

– Dan Mall

I truly believe that, for some of us, Photoshop is an indispensable tool that still has a purpose in our Web design workflows. I tip my hat to those designers who can stay creative using only the browser, but I know I’m not one of them. Whatever tools you use, there are two takeaways I feel strongly about: don’t let anyone stop you from using them, and continue to refine them in ways that support how you work. It’s important that we share how we approach responsive design for those who, like myself, are still trying to figure it out.

Photoshop isn’t dead, but the way you used to use it might be.

More Photoshoppery

(al) (ea)

© Dan Rose for Smashing Magazine, 2013.

August 09 2012


The Art Of Staying Up To Date


An important part of our job is staying up to date. Technologies don’t really change that fast — HTML5 and CSS3 take a long time to be specified and implemented. But the ideas surrounding these technologies and the things we can do with them are constantly evolving, and hundreds of blog posts and articles are published every day. There’s no way you can read all of those but you’ll still have to keep up to date. Here are some tips on doing that while still having some time left to work.

Ideas Surrounding These Technologies and the Things we can do With Them are Constantly Evolving


The hardest part of staying up to date is not reading too much. So many articles are published on a daily basis, so you’ll need filters. It’s unfortunately hard to make a living by reading articles all day, so you don’t want to read marginally interesting stuff, and you don’t want to read too much. You only want to read relevant stuff. You could try to automate this filtering, but I found that the best filters are actually people and time.


Some people produce lots and lots of ideas. Not all of these ideas are worth your time, but some of them are excellent. If you follow these people directly there’s a lot of noise you have to filter and you need a good sensor to recognize the good stuff. A very easy way to solve this is to not follow them directly but only follow the people surrounding them — they will do the filtering for you. If there’s an excellent idea, they will link to it. So in order to keep your sanity, don’t follow loudmouths (follow their more silent friends).

Don't Follow Loudmouths Directly

This tip works very well for Twitter, but it works for blogs as well. Don’t follow overactive sources, follow the people who follow these sources.


A few years ago I noticed that my RSS feeds started to dry up — especially blogs with opinionated articles. Articles where many people would leave their comments were all of a sudden gone. These discussions had moved to Twitter overnight. That’s the reason why I started tweeting (although I have to admit that I was addicted to it within a week). If you tend to your Twitter stream with care, it can become a very valuable source of good and relevant information. But if you follow the wrong people, or too many people, it will be exactly the opposite. My stream consists of mostly people who generally agree with each other. This means that it usually isn’t filled with tedious discussions about irrelevant details that can easily grow to gargantuan proportions. Now, I don’t say you shouldn’t listen to people you don’t agree with, I just think that Twitter is not the right place to follow these people.


Related to this Twitter-management (where I try to avoid heated discussions) is this other excellent filter I use: time. I almost never read articles the moment they are published, I wait a few days, or weeks or even months. If they are still interesting after a period of time, they are worth reading. You’ll see that lots of stuff is outdated even after a few days. Many articles are written in an emotional state, and many responses to these articles are written with even more emotion. These rows can certainly be entertaining, but they are rarely interesting after a week. I use Pinboard to create this buffer of unread articles, but there are many other handy tools available like Instapaper or Pocket (or you could just use your browser’s bookmark functionality).

Being up to date isn’t about knowing the latest trends and keeping track of all the gossip, it’s about knowing the right stuff by reading only the right stuff. But it isn’t just about reading the right stuff, it’s also about remembering it.

Backup Your Knowledge

The good thing about our current era is that we don’t have to learn everything we read by heart: we have computers these days to do the remembering for us. We just have to make sure that our computer can find the stuff we want it to remember. So create a database of the links to interesting articles that you read. I always write a small comment with these links when I save them to Pinboard, this way I can easily find them when I need them. You could buy the archival option from Pinboard, this makes it even easier to find older articles. I also created some IFTTT rules to backup these links to Evernote and Dropbox. I don’t want to depend on one tool, so I spread my knowledge around.

Use Your Knowledge

A very important part of understanding a new technique or design trick is by playing with it. You could of course immediately start using it in a big-production website (or you could also just first try it out). There are many tools out there that make it easy to test some snippets of code, like the amazing Dabblet and the incredible JS Bin. Playing around with code snippets that you find in articles will greatly improve your understanding of how things work.


There are many tools you can use for gathering and keeping your knowledge (and I already named quite a few). Here are a few more:


I use YoruFukurou as my Twitter client. It’s an unobtrusive client with some very handy tools for power-users, like muting certain words. It has some very handy advanced custom filter options as well. Tweetbot is a similar tool which works especially well on iOs devices. I fave every tweet that might have an interesting link (yes, that’s why I fave all of your tweets, but I’m not stalking you). All of these faves are automatically stored as unread items in a Pinboard account.


I read my feeds using the excellent self-hosted feed reader Fever. It has a feature that detects what articles are hot by checking how many people link to it. It uses the clever principle of Sparks — feeds that link to interesting things, but are not worth following to determine what’s hot. You can save articles for later (and yes, these articles are also saved as unread items in my Pinboard account, as well).

I Use Fever to Read My Feeds


As I mentioned before, by creating some clever filters you can make sure that your list of unread articles is manageable. But reading the articles and actually doing something with that knowledge can be pretty time-consuming. Every now and then I hit one of my two Pinboard bookmarklets that either show me the oldest unread item or a random one. As I said, many articles are outdated after a few days (but still many remain to be read). If an article is small, I read it right away. If it’s very long and very interesting, I either e-mail it to myself or I save it to Instapaper.

I save every article that is worth remembering to a second Pinboard account using Delibar, with a small comment and a few tags attached to it. There are many more ways to better organize these links, but this system works for me (I usually find a link I need within a few seconds).


IFTTT is a very handy tool that connects Web services. I use it to store my bookmarks on as many locations as possible. For instance, every article I save to my second Pinboard account is saved to Evernote and Dropbox. This makes it easy to access all these bookmarks from every device I use with specialized tools like nvAlt.


This whole article is just about staying up to date by reading articles, but one of the best ways to stay up to date is by talking to people. In real life you can talk to colleagues or attend conferences and workshops, as there are many regular meet-ups of like-minded people all around the world. You can use things like Twitter or IRC to start discussions or ask questions, or post your question on one of the many online fora out there.

Talking About Your Work is a Great Way to Form an Opinion

Other tools

There are many other tools out there that can help you with staying up to date. Many people use Instapaper, Delicious or Pocket to collect links. Others use email to send these links to themselves. Some people use the native bookmarks of their browser and others write their own bookmarking service.


Professionally I am specialized in HTML and CSS, and I have an interest in Web Design and some other areas. Since I have expert knowledge of CSS, it doesn’t make much sense for me to follow websites that offer CSS tutorials for beginners. So on this particular subject I follow the real experts and even the people who write the specs: my knowledge about CSS has to be more than up to date. Bas Poppink, a colleague of mine, calls this principle following the sources of your sources until you found the headspring. I call it the Poppink-principle. So if you’ve outgrown tutorials, ask the authors of these tutorials what websites and which people they follow.

What sources are right for you depends on a lot of things, like your experience and your fields of interests. Below you’ll find some of my sources. You might find some interesting stuff in there…

My Sources

My main source of information comes from people who tweet something that might interest me. Twitter is also great for discussing articles and opinions, or asking for advice. But there is more…


There are some feeds I rely on: the bookmarks saved by Jeremy Keith, Kazuhito Kidachi, Peter van der Zee, and Paul Irish. They usually add a helpful description to their bookmarks. There are a few people who regularly post high quality reading lists: you should definitely follow a few of those too, if not all. The rest of the links are distilled from a somewhat random collection of ancient and newer RSS feeds that definitely need some weeding. Do you really want to know what they are? Here is the OPML file.

But you’ll probably be better served by the excellent collection of Front-End and Web Standards feeds that Paul Irish curates. He also points at these great weekly email newsletters about JavaScript, Web design, CSS and HTML5. Definitely worth a follow if email is more your thing.

Your Own Sources

Whether you want to be the very best in your profession or someone who is good enough, staying up to date is essential for every professional. The exact people and feeds to follow depends on your own interests. Just take your time to find and collect them and be sure to critically look at them every now and then. Also, what tools you choose to use in order to stay up to date is totally up to you, as there are many more ways to stay up to date than I described here. I hope that this article somehow helps you in finding the right sources and in creating your own, better, flow of information.

Image source of picture used on front page.


© Vasilis van Gemert for Smashing Magazine, 2012.

July 17 2012


Five Tips to help Designers Find the Perfect UX Agency

Most UX designers I know aren’t masochists, but boy do they love chaos! Why else would they choose a field where, depending on where you work, a “matrix” could be a reference to content or Keanu Reeves? The fact is: unless they are the Che Guevara type, designers are often as good as the ecosystem and culture of their employer.

Consider the following scenario: your recent start up fails but you learn a lot about Lean UX along the way. Soon thereafter, you get a job offer to build the UX department at a major agency. However, at that agency, the project managers aren’t even sure what a task analysis is!

Introducing Lean UX there will probably take you a very long time (as will the cancerous growth on your UX soul).

Fear not, fellow UX designer! If you’re considering joining an agency, here are a couple of tips to make your search a little easier.

Don’t find a job, find a culture

A bacterial culture

Everything has a culture. What’s theirs like?

You can’t do it alone. Even if you’re Donald Norman. Does this agency simply want a voice in the room that can pull usability principles out of their hat during design reviews? Don’t work there.

UX designers need a culture that appreciates the vast, overlapping universe of experience design. Of course: unless you work at an Adaptive Path, IDEO or EffectiveUI, you’re most likely not going to find a place that are deeply knowledgeable about user experience. That’s okay. Perform your own gap analysis and understand to what degree the culture has a passion for learning user experience. That way, the majority of work you do will be focused on the client, not your team’s culture.

Look for receptive leadership

This is a big one. Get a sense of whether or not the leadership truly cares about the people doing the work. If you’ve ever seen Paths of Glory with Kirk Douglas then you’ll know what I mean. Disconnected leaders see their team mates as pawns used to advance their goals.

When staffing a project, does management take into account people’s personalities in addition to their skillsets? …or are they just checking items off a list? While managers should always care about profit, the best also care about their team’s experience. This kind of receptive leadership implies two-way communication. It means that there’s an emotional maturity in place so that an organization can course-correct by listening to (and acting in the best interest of) its members.

Next comes the leadership part. Will they say no to a client? This is key. If an account manager is told to “compromise for client happiness at all costs” then it’s unlikely that their agency can lead the client and help their team produce its best work.

Finally, does the leadership express core principles the agency must abide by? I’d settle for something like “we’ll never deliver bad work, no matter the timeline.” Regardless, ask them what they stand for. Next, see if they walk the walk: talk to their junior designers.

Ensure tolerance to uncertainty

My favorite quote from the Effective UI book is “intolerance to uncertainty is intolerable.” If only every agency I worked for had this chiseled in marble! A tolerant organization recognizes an essential and undeniable reality about good design: no solution is obvious.

A sword

Look for good values. The best agency will be steadfast on some issues and lax on others.

Do projects at this agency often begin without a signed Statement of Work (SOW)? This can happen when clients have an urgent deadline and/or when both sides “act on good faith.” In this case, the agency must communicate that work without an SOW is an investigation into what’s possible.

Next, note whether or not this agency explains working assumptions to their clients. If not, they’re vulnerable to scope creep and/or client bullying.

On the flip side, always avoid agencies that spell out every feature exhaustively. How can you find the best solution if the SOW already has? Without doing research there’s no way you can know what the best solution for a user should be.

Identify their process

Clients will always want work produced faster, for less money, and with more certainty. And while I feel for them (many have jobs riding on a project), agencies must do their part to both educate clients and earn their trust. A large part of that comes from managing expectations.

Scope is simply a measure of how much of their design problem a client wants to solve at any given time. Grill the agency as to what their scoping process is. Don’t look at the “cool” infographic they have on their website; talk to people on the ground and understand how plans come together.

Regardless of their actual methodology, an agency’s process should always protect the integrity of its design endeavors. Nothing wastes client money more than the internal kickoff in which someone says “what deliverables should we do?” The rest of the kickoff is then spent discussing how the design will be communicated rather than how design itself should communicate!

Look for checks and balances

An agency’s team dynamic should encourage cross-disciplinary collaboration and debate. Design is a human endeavor, making camaraderie critical. One person who’s only out to make themselves look good can take the whole thing down.

How does this agency handle conflict resolution? What if, say, an Account Manager and a Project Manager don’t get along? Does the agency prefers to “let people work it out?” That’s not leadership.

Alternately, if they run witch hunts in their post-mortems then they’re running on a culture of fear. No one department should be favored over another. All departments – including UX – should be treated with respect to ensure a democratic system of checks and balances.

In sum

No agency is perfect. No company. No client. No person. It comes down to intention, really: does this group of people want to transform human experiences for the better?

Any agency can become a great place to practice experience design. But you can save yourself a lot of heartache by interviewing your future employers with the same rigor and diligence which which they’ll undoubtedly interview you. In the process you’ll really learn why you do what you do.

The post Five Tips to help Designers Find the Perfect UX Agency appeared first on UX Booth.

April 24 2012


Breaking Out of the UX Status Quo

As a UX Designer you’ve committed your career to helping people. You challenge the status quo everyday…but are you challenging it enough? How about with your deliverables? Your customers are people, too! Are your common deliverables – personas, sitemaps, user-flows and wireframes – really usable or are they just getting in the way?

It’s no secret to us: user experience designers speak their own language. From personas to user journeys, card sorts to wireframes, there’s a certain vernacular to our profession. It’s something that we learn over the years but that our clientele must overcome immediately.

Frustrated with the conventional deliverables used to communicate our work, I began to reconsider their presentation. What resulted is certainly not “conventional,” but – taken together – they are arguably more usable.

Personas are like resumés

Personas come in all shapes and sizes. Contrary to what they’re designed to do, however, rarely do they convey a good sense of the user. Most look like resumés: sterile and lacking in personality.

When was the last time you hired someone based on their resumé alone? Even with a resumé you still need to conduct an interview in order effectively gauge a prospect. Seeing someone and listening to their words reveals their personality – the key element missing from most personas.

So I started a searching for a better way. The first thing I did was move my deliverables online. This allowed me to link them together so that clients could click between them. For desktop projects I use Axure and for mobile and tablet I use Both of them are great tools as they create clickable, HTML-based output.

Next, I searched high and low for inspiration. This persona, created by User Insight, is definitely different. Therein, the user (Tina) does not consist of mere bullet points; she comes off as a real person. Jason Travis’s personas are infinitely more visual. Being picture-based, though, they lack any descriptive text whatsoever.

Inspired by these (plus adding my ideas and style) I tried to put together a new version of the traditional persona.

Barnabas's persona

You can view a demo here.

This approach paints a much more holistic picture of a person. Not only does it include their goals, it includes important, ancillary information such as their worldview, what they are looking for and their motivation. Further, the overheard conversation adds just the right amount of insight into his/her life. The “questions” section helps identify the areas the target user is unsure of and the “life pieces” section makes the persona human-like with feelings and desires.

Sitemaps are like spiderwebs

Sitemaps are (as most of you know) used to “map” the major components of a website to a rather sparse-looking diagram. Because they’re so sparse, they also tend leave a lot to the imagination. This gives rise to common retort: “What’s this page do, again?” “Can you change this page to that?” “How about we scrap that page”

You know the routine. Because clients come to us for the visual thinking they often can’t turn these sparse diagrams into anything “useful” on their own.

This got me thinking: why not just put the thinking alongside the map?

Barnabas's persona

You can view a demo here.

Even though it’s just a small difference, this approach pays off. It helps our clients understand the internal monologue that drives the narrative. Knowing the reasoning behind your decisions helps others understand (and agree) with your perspective.

User journeys are like electric panel diagrams

User journeys map the steps of a user, correlating goals (explained in Personas) with a site map to better illustrate how users will get things done. As a result, designers can make informed suggestions to the site’s information architecture.

The problem is that most user-flows are very dry. It is difficult to feel empathy with a user and their journey if all you see are boxes and arrows (similar to electric panel diagrams).

After scouring the internet looking for something better I found a couple of good approaches.

Jakub Linowski's user flow

Jakub Linowski’s Grand Narratives & Play Points diagram offers a compelling yet easy-to–understand presentation based on wireframes.

A user journey from the Bluepoint+ deliverable framework

Blueprint+ (Service Design Visual) is great because it includes the persona and a timeline.

Carlos Abler's user journey

Carlos Abler’s Multiuser WireFlows combines the two former ideas.

All of these are good but they all seemed to be missing something.

I’ve been always fan of recycling, so I thought there has to be a way to re-use the sitemap and display the user-flow on it. I also wanted to re-use my personas in order to create empathy for the user’s journey. This led me to the following presentation:

Barnabas Nagy's user flow

You can also view a demo here.

As you can see, I simply re-used my sitemap and added one of my persona with speech bubbles. In the speech bubbles I added the thoughts of the persona at every stage of their journey. This adds a human touch. The thoughts of the persona can explain to clients the reasons for the journey taken and the scenario puts these thoughts into context. It is simple but visually understandable way to show your user-flow.

Clients that already understand your sitemaps and personas will have no trouble seeing the two work together.

Prototypes/wireframes are like abandoned houses

Wireframes created in the absence of personas are broken. Yet we do this all the time. Why do we create personas if we don’t use them?

Looking for a better way, I saw a picture in the essay of Rósa Gudjónsdóttir:

A man working next to two cardboard cutouts of personas.

I was fascinated by the idea of having my personas around me. I started to print my personas and stick them to the wall in front of me. It helped, however, the screen and the wall are two different worlds, analog and digital. No good.

I eventually placed my personas in the margin of my prototype to serve as a constant reminder of who my users are:

A wireframe juxtaposed with persona avatars.

You can also view a demo here.

Not only does this help us to not design for ourselves, our clients and stakeholders are now constantly reminded who will use our design. The time and effort we put into establishing our personas is never lost.

Never stop learning

As I mentioned earlier, these ideas have helped me better convey my work to my clientele. They are not perfect, of course, nor were they intended to be. I am certain that it is possible to tweak them or in fact come up with even better presentations that work for you.

Are you also frustrated with common UX processes or deliverables? Don’t let the status quo get you. Always try to make things better, iterate and optimize. Surprise your users – err, clients – with something new and innovative as this is the way forward. If you’ve tried your hand at something different, be sure to share your result in the comments below!

December 13 2011


Mixing Up Illustration: Combining Analog And Digital Techniques



In the digital age, don’t forget to use your digits! Your hands are the original digital devices

Lynda Barry

People often ask how I arrived at a finished illustration. Honestly, it’s different every time, but it always starts with a hand-drawn sketch. Sometimes, I paint it completely by hand; sometimes I’ll scan in a pencil drawing. Many of my pieces are 100% analog that I’ll show only at shops or galleries. Use anything you can; if the illustration would work as a wood carving, go that route. There are concrete steps one can take, but they certainly don’t have to be the same every time. My goal is to take a sketch or idea as far as it can go — and also, to get out of my comfort zone and challenge myself with every new job. For this article, I’ll use handcrafted brushes and Photoshop as my tools.

Sketching It Out

Concepting for me always starts with pencil and paper. If there is one consistent element through all of my pieces, it’s sketching. I love to draw. If I could establish and execute everything with a single pencil drawing, I would. The best thing to do is keep some type of sketchbook or journal with you as much as possible. Milton Glaser said it best: “Drawing is visual thinking.” Drawing creates many possibilities for any idea you might have. It’s then when the character’s personality starts to emerge. Then, I’ll add some volume to the sketch to show where the textures should really come through.

Sketch It Out


This is the most underestimated part of the process, but one of the most important. Here, we’re assessing the sketch. What textures would work? What colors would work? It helps to look at your influences.

Some artists who always inspire me are Mary Blair, Alice Provensen, Charley Harper, Maurice Noble and Eyvind Earle. And there are so many ways now to catalog and bookmark historical artwork.

Also, if I’m drawing an elephant’s skin, or wood on a camera, or a band on a helmet, I’ll want to take a close look at the real thing. Google Images is quick, but if I have time I’ll run to the library. Sometimes I do this as soon as I have an idea. Really seeing what you’ll be working with helps.

Researching It image

Crafting Your Own Brushes

I do this because I want my brushes to be my own. Many great websites out there offer textured brushes for Photoshop. For me, the more unique these brushes, the better. Based on my sketch and research, I will have some idea of what I want to capture. I’ll use oil pastels, paint, paper towels, charcoal and anything else. It’s all about being resourceful — use everything. One more thing: when making brushes, the grittier the paper, the better. The more tooth it has, the more the marks will scan. It is for this reason alone I have to clean my scanner all the time.

Tools for Making Brushes

Crafting the Brushes

Pastel Marks on Paper for Brushes
Some rough crosshatching for the elephant’s skin, with an oil pastel on drawing paper.

Scanning It All In

Scan everything: the initial sketch, the textures, anything you’ve made to this point. I’ll keep anything that I don’t use at this point in a library, possibly to use for something else. I’ve set the scanner to 600 DPI at “Millions” of colors. If your scanner has a “Sharpen” setting, crank it to “High.” You can scan the sketches in black and white at 1200 DPI, or in grayscale since the brushes will be black and white. I’ve set the colors to “High” so that I can archive the files and use them for something else. Once everything has been scanned, let’s open the images in Photoshop.

Here is a scan of my original sketch. I scanned it in at 300 DPI because I will eventually be printing this piece.

Original Scan

Initial Brushes

Up the Levels

If you scan as black and white, you won’t need to worry about adjusting the levels. I’ve scanned in color, so I’ll increase the black and white values in Photoshop. The levels can be found in Images → Adjustments → Levels.

Defining Brushes In Photoshop

I recommend making each one of these brushes a separate file. For the resolution, you can go up to 2500 × 2500. It really depends on what the finished piece needs to be. For this exercise, I’ll select a portion of the scan and define a brush from it.

Selecting the Brush to Make

Define Brush in PS

From the menu drop-down, go to “Edit” and then “Define Brush.”

Name Selected Brush

Now that we have created a brush, we can name it. It will be added to our Brush palette.

Brush Added to the Palette

You can view the Brush palette by selecting the Brush tool. Look at the options toolbar, and you’ll see a thumbnail of the brush; you can pull this down to view the entire palette. From the menu arrow in the top right, you can save brushes you’ve created. Brushes are saved in Photoshop’s Presets/Brushes folder. You can also load brushes from this menu as well.

Selecting A Color Palette

Now that our brush set is in order, let’s start painting. For the color palette, I’ve researched my idols. Mary Blair and Alice Provensen are masters of color and shape. I always look at their use of color and design. Again, this is why research is so important. Study the people you admire, and analyze why you admire their work. I really like a somewhat muted palette, with some small areas of intense color. In my scanned sketch, I’ve added another layer and sampled the colors I’d like to use.

Color Palette

Making Shapes And Painting

Let’s go to the Paths menu and draw the shapes that we want to paint. From here, we create a “New Path” using the Pen tool, to define the shapes that we established in the sketch. So, let’s open the sketch that we scanned, select the Pen tool from the toolbar, and select “New Path” from the Path menu. Once the Path is saved, we use the Path tool (which is the Pen tool), and start tracing out our shapes. The image below shows all the paths I’ve created that I intend to paint.

Creating Paths

Let’s start by painting the shape that will be the background. From the toolbar, select the Path tool, and select a specific path.

Selecting an Individual path

Now that we’ve selected a Path, we can create a selection from that path. To do this, select from the pull-down menu on the right in the Paths menu. You’ll see an option named “Make Selection.”

Make Selection from Path

Once that’s selected, a dialog box will pop up asking for a radius to feather the selection; 0 is fine. Also, enable “Anti-aliased” and “New Selection.”

Make Selection from Path

Now that we have a selection, we can “Create a New Layer.” This layer will be specific to this shape. We’ll end up with many layers for each shape, but they will give us the flexibility to edit down the road.

Create a New Layer

Now that we have a new layer, and the Path is a selection, we can use a brush from the brush set that we created. Also, I’m still using the colors from the palette that I created earlier.

Painting Shapes

Here’s where the research, brush creation and painting all come together. Let’s paint the path on a “New Layer,” using the steps described above.

Painting Shapes

Painting within the shapes you’ve defined is a chance to experiment. You can try all kinds of things, like making the brush more transparent or painting over other textures. For me, it’s a lot of trial and error. This image below is a close-up of the brush I’m painting with.

Brush Close Up

After many painted layers, I end up with a piece that is digitally painted with hand-crafted brushes.

Finished Illustration

Other Resources

You might be interested in the following articles and related resources:

  • Illustrations of Alice and Martin Provensen
    Alice and Martin Provensen were a husband-and-wife illustration team. They wrote and illustrated numerous children’s books, including many little and giant golden books from the ’40s until Martin’s death in 1987. Alice continues to work as an illustrator.
  • How to Steal Like an Artist
    An excellent article on creativity and life by the brilliant Austin Kleon.
  • The Drawn Blog
    A daily source of inspiration for illustration, animation, cartooning, and comic art.
  • Today’s Inspiration
    A great source for inspiration and the history of Illustration by Professor Leif Peng.


© David Mottram for Smashing Magazine, 2011.


The Messy Art Of UX Sketching



I hear a lot of people talking about the importance of sketching when designing or problem-solving, yet it seems that very few people actually sketch. As a UX professional, I sketch every day. I often take over entire walls in our office and cover them with sketches, mapping out everything from context scenarios to wireframes to presentations.

My Desk
My desk.

Although starting a prototype on a computer is sometimes easier, it’s not the best way to visually problem-solve. When you need to ideate website layouts or mobile applications or to storyboard workflows and context scenarios, sketching is much more efficient. It keeps you from getting caught up in the technology, and instead focuses you on the best possible solution, freeing you to take risks that you might not otherwise take.

Many articles discuss the power of sketching and why you should do it, but they don’t go into the how or the methods involved. Sketching seems straightforward, but there are certain ways to do it effectively. In this article, we’ll cover a collection of tools and techniques that I (and many other UX and design folks) use every day.

Sketching ≠ Drawing

Some of the most effective sketches I’ve seen are far from perfect drawings. Just like your thoughts and ideas, sketches are in a constant state of flux, evolving and morphing as you reach a potential solution. Don’t think that you have to be able to draw in order to sketch, although having some experience with it does help.

  • Sketching is an expression of thinking and problem-solving.
  • It’s a form of visual communication, and, as in all languages, some ways of communicating are clearer than others.
  • Sketching is a skill: the more you do it, the better you’ll get at it.

When evaluating your sketches, ask yourself, “How could I better communicate these thoughts?” Getting caught up in evaluating your drawing ability is easy, but try to separate the two. Look at your sketch as if it were a poster. What’s the first thing that’s read? Where is the detailed info? Remember, the eye is drawn to the area with the most detail and contrast.

Just as one’s ability to enunciate words affects how well others understand them, one’s ability to draw does have an impact on how communicative a sketch is. The good news is that drawing and sketching are skills, and the more you do them, the better you’ll get.

OK, let’s get started.

Work In Layers

Often when I’ve done a sketch, the result looks more like a collage than a sketch. Efficiency in sketching comes from working in layers.

Quick video showing how you can use layers to effectively build your sketches.


Start with a light-gray marker (20 to 30% gray), and progressively add layers of detail with darker markers and pens.


Starting with a light-gray marker makes this easy. It allows you to make mistakes and evaluate your ideas as you work through a problem. Draw a crooked line with the light marker? No big deal. The lines will barely be noticeable by the time you’re finished with the sketch.

As the pages fill up with ideas, go back in with a darker marker (60% gray) or pen, and layer in additional details for the parts you like. This is also a great way to make a particular sketch pop beside other sketches.

Sketching in layers also keeps you from getting caught up in details right away. It forces you to decide on the content and hierarchy of the view first. If you are sketching an interface that contains a list, but you don’t yet know what will go in the list, put in a few squiggles. Later, you can go back in and sketch a few options for each list item and append them to the page.


If you start drawing with a ballpoint pen and then go in later with a marker, the pen’s ink will likely smear from the alcohol in the marker.

As you get more confident in your sketching, you will become more comfortable and find that you don’t need to draw as many underlays. But I still find it useful because it allows you to experiment and evaluate ideas as you sketch.

Loosen Up


When sketching long lines, consider moving your arm and pen with your shoulder rather than from the elbow or wrist. Reserve drawing with your wrist for short quick lines and areas where you need more control.


This will allow you to draw longer, straighter lines. If you draw from the elbow, you’ll notice that the lines all have a slight curve to them. Placing two dots on the paper, one where you want the line to start and one where you want it to end, is sometimes helpful. Then, orient the paper, make a practice stroke or two, and then draw the line. If you look closely, you’ll see this in the video above.

A bonus to drawing from the shoulder is that much of the motion translates to drawing on a whiteboard; so, in time, your straight lines will be the envy of everyone in the room.

Play To Your Strengths


Rotate the page before drawing a line in order to draw multiple angles of lines more easily.


Very few people can draw lines in all directions equally well. Rotating the page allows you to draw a line in the range and direction that works best for you. Don’t try to draw a vertical line if you find it difficult; rotate the page 90 degrees, and draw a horizontal one instead. It’s super-simple but amazingly powerful.


This does not translate well to a whiteboard, so you’ll still need to learn to draw vertical lines.

Sketching Interactions


Start with a base sketch, and then use sticky notes to add tooltips, pop-overs, modal windows and other interactive elements.


Using sticky notes to define tooltips and other interactive elements lets you quickly define interactions and concepts without having to redraw the framework of the application. They are easy to move around and can be sketched on with the same markers and pens you are already using.

  • Define multiple interactions on one sketch, and then strategically remove pieces one at a time before scanning them in or copying the sketch.
  • Use different colors to represent different types of interaction.
  • Is one sticky note not big enough for your modal window? Add another right next to it.
  • Is one sticky note too big for your tooltip, user a ruler as a guide to quickly rip the note down to size.

Sticky Notes used on sketch as pop overs
Explore a variety of interactions and ideas in a single sketch using sticky notes.

Photo copies of sticky notes on sketches as pop overs
Upon photocopying various versions of a sketch, each with different sticky notes, you’ll end up with various distinct sketches.

Copying And Pasting For The Real World

At times, you may want to manually redraw a UI element multiple times in a sketch. This is not always a bad thing, because it gives you the opportunity to quickly iterate and forces you to reconsider your ideas. That being said, an all-in-one scanner or photocopier could dramatically increase your efficiency.


Use a photocopier to quickly create templates from existing sketches or to redraw an area of a sketch.


A photocopier is the old-school version of Control + C, Control + V. It makes the production of templates and underlays more efficient. It also boosts your confidence, because if you mess up (and you will mess up), you can easily fix it.

  • Does one part of your interface need to be consistently redrawn in multiple sketches? Run a few copies, and then sketch directly on the print-outs.
  • Did you mess up a part of the sketch? No problem. Cover up that portion of the sketch with a piece of paper or with correction fluid, run off a copy, and then start sketching directly on the print-out.
  • Are you working on a mobile project? Or do you want to make a series of sketches all of the same size? Create a layout and copy off a few rounds of underlays. Easier yet, print off underlays of devices or browsers; a good selection can be found in the article “Free Printable Sketching, Wireframing and Note-Taking PDF Templates.”
  • Do you want to change the layout of a sidebar in your last five sketches? Sketch the new sidebar, run off a few copies, and then tape the new sidebars over the old ones. It’s that easy.
  • To use a sketch as an underlay of another similar one, adjust the density or darkness setting on your photocopier to run a copy of the sketch at 20% of it original value.

Another advantage to photocopies is that marker will not smear on a print-out the way a ballpoint pen does. So, whenever you have an area of a sketch to highlight or add color to, run a few copies first.


Paper cuts.

Sketching over a photo copy
Sketching over a photocopy of the original to reevaluate the sidebar.

Final sketch over photo copy
The final sketch. Notice how the sidebar and its detail are darker than the photocopy. This is intentional, because it allows you to explore ideas in the context of the overall design.

The Design Is In The Details

Use a ruler; specifically, a quilting ruler. Quilting rulers are translucent and are normally printed with a ⅛″ grid screen, letting you see the line you’re drawing relative to the rest of the sketch.


Use a ruler and a light-gray marker to draw an underlay for a detailed sketch.


This lets you quickly draw a series of lines that are offset a set distance from each other. This works great for elements such as lists items, charts, buttons and anything else that needs to be evenly spaced. It’s like an analog version of “smart guides.”

Using a quilting ruler to create offset lines
Quickly creating evenly spaced lines with a quilting ruler and 30% gray marker.


After using a light-gray marker to lay out a sketch, use a ruler and ballpoint pen or black marker to finalize it.


When sketching in layers, you want the final design or layout to “pop.” A ruler enables you to be more precise in detailed areas and ensures that long edges are straight.

There is no shame in using a ruler. The key is knowing when to use it. Don’t start sketching with a ruler; rather, bring one in when you need the detail and precision. Remember, you’re sketching, not drawing.

Using a ruler to pop various lines on the sketch
Using a ruler to make sections of a sketch drawn with a 70% gray marker pop.


Use a ruler to quickly rip paper or sticky notes by firmly holding the paper with one hand and ripping away the edge with the other hand.


It’s quicker then grabbing scissors; you already have the ruler with you; and you can take it through airport security.

After lightly sketching an interface with a light marker, finalize it or make one area pop by using a ruler to lay down darker lines.

Ripping a sticky note with a ruler.
Ripping a sticky note with a ruler.

Tell The Whole Story


Draw the application in the context of where and how it being used, or frame it with the device it will be used on.


This forces you to think about the environment that the application will be used in, instills empathy for your users, and establishes understanding of the challenges unique to this application.

I get it. No one wants to sketch out a monitor every time they draw a wireframe. I’m not saying you have to, but a few sketches with context go a long way. Especially with mobile devices, the more context you add to a sketch, the better. Moreover, I always sketch the device for a mobile interface as an underlay, and I often try to sketch the UI at full scale. This forces you to deal with the constraints of the device and makes you aware of how the user may be holding the device.


Drawing the surrounding environment can be challenging and requires a higher level of sketching competency. Don’t let this intimidate you. If you’re not comfortable sketching the environment or you find it takes too long, use a picture as an underlay instead.

Various sketching of a mobile device in context of their enviroment
Sketching ideas for a mobile application in the context of where it will be used.

Ditch The Sketchbook


Draw on 8.5 × 11″ copy paper.


Sketches are for sharing. You can easily hang 8.5 × 11″ sheets on a wall to share ideas with others or to see a project in its entirety. When you need to save a sketch or two, you can easily batch scan them into a computer without ripping them out of the sketchbook. Still not convinced? Copy paper is cheaper; it allows you to use sketches as underlays without photocopying; and you don’t have to choose between book-bound or spiral-bound.

A wall of sketches
One of the many walls of sketches in our office.

What Are You Waiting For?

Sketching is not reserved for designers. Developers, project managers and business analysts can get in on the fun, too. It’s the best way for teams to quickly communicate, explore and share ideas across disciplines. Also, I’ve found that others are more receptive to give feedback and make suggestions when shown sketches than when shown print-outs or screenshots.

Remember, it’s about getting ideas out, reviewing those ideas and documenting them, not about creating a work of art. When evaluating your sketches, ask yourself, “How could I better communicate these thoughts?” Getting caught up in evaluating your drawing ability is easy, but try to separate the two, and know that the more you do it, the better you’ll get.

It’s worth repeating that sketching is the quickest way to explore and share thinking with others. It focuses you on discovering the best possible solution, without getting caught up in the technology.

Go for it! Don’t get caught up in the tools. Make a mess. And have fun!


Here are links to some of the tools described in this post.

All images by Michael Kleinpaste.

(al) (fi)

© Peiter Buick for Smashing Magazine, 2011.

November 22 2011


The Big Think: Breaking The Deliverables Habit



Right there in the center of my boilerplate for design proposals is a section that I glare at with more resentment each time I complete it. It’s called “Deliverables,” and it’s there because clients expect it: a list of things I’ll deliver for the amount of money that I specify further down in the document. Essentially, it distills a design project down to a goods-and-services agreement: you pay me a bunch of money and I’ll give you this collection of stuff. But that isn’t what I signed up for as a designer. Frankly, I don’t give a damn about deliverables. And neither should you.

(Image: Snoggle Media)

Case in point: for months now, I’ve worked consistently with a particular client for whom I do almost no work on actual design artifacts (wireframes, prototypes, etc.). Rather, I hold frequent calls with the main designer and developer to go over what they’ve done with the product (i.e. poke holes in it) and what they should do next (i.e. help prioritize). Some days, they hand me wireframes; sometimes, a set of comps; other days, live pages. Whatever the artifact, our purpose is always to assess what we have now versus where we need to get to. We never talk about the medium in which these design ideas will be implemented; we focus strictly on the end result, the vision of which we established long ago and continually refer to. And in working this way, we’ve been able to solve countless significant problems and dramatically improve the client’s website and products.

It’s not about deliverables. It’s about results.

Understanding why this works depends on understanding the real role of the designer and the deliverables they create.

A Designer’s Work

First, consider the role of a designer compared to what we actually spend most of our time doing.

What designers are hired to do — the reason why companies seek out designers in the first place — is what my friend Christina Wodtke calls “The Big Think”: we’re hired to solve problems and develop strategies, determining what needs to be achieved and making design decisions that help to achieve it. But because companies have a compulsive need to quantify The Big Think, designers end up getting paid to create cold hard deliverables. Our very worth, in fact, is tied intrinsically to how well and how quickly we deliver the stuff. Heck, we’re often even judged by how good that stuff looks, even when much of it goes unseen by a single user.

Is this how it should be done? Absolutely not.

Hiring a designer to create wireframes is like hiring a carpenter to swing a hammer. We all know that the hammer-swinging is not what matters: it’s the table, the cabinet, the deck. Clients don’t hire us to wield hammers, but to create fine furniture. It’s not the process they need or the tools, but the end result.

In theory, companies understand this. In practice, not so much. They cling to the deliverables.

The Essence of Deliverables

So let’s look at what a design deliverable really is.

The purpose of a design artifact, whether a wireframe, prototype or sketch, is to illustrate our thinking. Pure and simple. It’s part of the thinking process. It’s also, according to some, a record to look back on later to aid when reconsidering decisions, tweaking the design and so on. But let’s be honest: people rarely look back at these documents once the design grows legs and starts walking on its own. More often than not, significant changes result in new wireframes, and minor tweaks are made on coded screens, not back in the deliverables that we were paid so much to create.


Most of the time, design artifacts are throwaway documents. A design can and will change in a thousand little ways after these documents are supposed to be “complete.” In terms of allocating time and budget, design artifacts can be downright wasteful. They can even get in the way; designers could get attached to ideas as they transition to functioning screens, precisely when they need to be most flexible. Every design is speculation until it’s built.

Like it or not — and some of you will surely disagree — we can survive with fewer deliverables. Of course, what this looks like depends on how you work.

Breaking the Deliverables Habit

The most important parts of any design project are the vision of the end result, the requirements for it, the design itself, and a way to measure its success.

Interestingly, only one of these parts involves complicated design artifacts. The vision is merely a statement that describes the purpose and desired outcome. Requirements are but a list. Success metrics? Another list. The only part that involves more than a simple, concise summary is the design itself. And nothing requires that process to involve layer upon layer of wireframes, prototypes and comps before going to code. (More on how to change this in a minute.)

(Image: lucamascaro)

Comps, of course, are a must when graphics are involved; in addition to necessarily being the source of the graphic files to be used in the actual design, they define the visual language, the specifics of layout, spacing, typography, etc. Creating wireframes, on the other hand, as quick as it is compared to creating coded screens, can take much longer than going from sketch to code. So, consider cutting the load down to what’s most essential and useful: the interaction model.

In other words, you don’t have to create wireframes and comps for every idea or every screen; just for the toughest screens, the ones that define the most crucial interaction paradigms. Use them to iron out the model, not every last detail.

It’s time for more design and less stuff. Consider the revised process below.

1. Strategy Document

Distill your research on users and the business down to a short vision statement on what the user’s experience should be like. Add to this a list of design criteria (specific guidelines or principles for the design), as well as success metrics (how you will know that the design is achieving your goals). You should be able to do all of this within just a couple of pages; and keeping it short will help to ensure that everyone reads it.

2. Activity Requirements

Write a list of tasks that users should be able to perform, and functions that the system should perform that will benefit users. Prioritize the ones that will appear on the screen.

3. Sketch

To apply the design criteria and meet (or exceed!) the requirements, sketch a dozen or so ideas — in Keynote, on paper or on a whiteboard — and then take pictures of the sketches. Sketch the toughest, most complicated and most representative screens first. These will frequently determine the interaction model for most of the design.

4. Comp and Code

If you’re not doing the visual design yourself, collaborate with the graphic designer to iron out the details of the most representative screens and any other screens that require graphics. At the same time, collaborate with the developers to identify issues and areas for improvement throughout the process.

Forget the lengthy strategy documentation. Forget the deck of wireframes. Just short summaries (long enough to get the point across, but short enough to be able to do quickly), sketches and comps, limited to the things that need to be brought to a boil in Photoshop. Skimping on the deliverables can save a lot of time.

Untying Deliverables From Project Fees

Of course, sufficing with this shorter list of artifacts and untying deliverables from your fees require a change to the design process. In short, we need to shift the emphasis from documentation to collaboration.

Set the expectation from the beginning that you will work with stakeholders collaboratively. They will help you think through the design at every step. You will not be a wireframe monkey. Rather, you’ll focus on The Big Think. And you’ll do it together. If the client is unwilling or unable to spend time and energy on the design as you develop it, find another client. A client who is too busy to get involved in the process is a client who doesn’t care about their customers.

Collaboration is essential to great design. No one person can think of everything or always have the best ideas for every aspect of a product. It takes a group to make this happen. This might require you to occasionally browbeat the client into being available for frequent discussions on new and developing ideas, but the result will be infinitely better. And with the added input, you can focus less on stacks of deliverables and more on converting rough ideas into comps, prototypes and/or functioning pages that give undeniable weight to those ideas.

In practical terms, this means working closely and constantly with the visual designers and developers (assuming you’re not doing this work yourself). And it means frequently reviewing what’s being done and discussing at a deep level and at every step how to make improvements. It means talking through every detail and making sure someone has the job of being the resident skeptic, questioning every idea and decision in the interest of pushing the design further.

Break The Habit

By focusing on The Big Think, the deliverables will matter less. And for a designer, focusing on beautiful products is a whole lot more rewarding than dwelling on the step by step of deliverables. On your next time out, consider breaking the deliverables habit. Go from idea to code in as few steps as possible. Hefty amounts of collaboration can cure the sickly feeling that you’re an overpaid wireframer, empowering you to build designs that you know are killer work.


© Robert Hoekman Jr for Smashing Magazine, 2011.

September 13 2011


The S.M.A.R.T. User Experience Strategy

Advertisement in The S.M.A.R.T. User Experience Strategy
 in The S.M.A.R.T. User Experience Strategy  in The S.M.A.R.T. User Experience Strategy  in The S.M.A.R.T. User Experience Strategy

I was a competitive road cyclist for four years. My bikes were good, but my race results were much less impressive. Instead of medals and trophies, all I had to show for it were shaved legs and a farmer’s tan.

Regardless, on the road to becoming a competitive athlete, I followed a rigorous training plan with concrete goals. These goals were specific, measurable, attainable, realistic and timely. With this training plan, I was able to quantitatively and qualitatively assess my progress and adjust my routine to match.

Bikers-screenshot in The S.M.A.R.T. User Experience Strategy
(Image: Stig Nygaard)

In the years since, I’ve hung up my racing jersey and replaced it with a designer’s hat. While wearing this hat, I (and many others) have been told to “create a good user experience.” We’ve heard this in creative briefs, project kick-off meetings and critiques. It may have been a bullet point in a PowerPoint presentation or uttered by someone trying to sell a client or company on the value of their services. But there’s a fundamental problem with stating that your goal is to “create a good user experience.”

It’s not specific, directly measurable, actionable, relevant or trackable. Thus, it will create disagreement and disorganization, sending many projects into chaos. However, we can avoid this by using S.M.A.R.T. goal-setting criteria when defining user and business goals.

Bad Vs. Good Methodology

Before we get started, let’s look at how a poor methodology can derail an entire project.

There was once a project to redesign a significant section of a company’s website. This section introduced visitors to the brand’s history and technology, and analytics indicated that customers who visited this section had a much higher conversion rate. Stakeholders believed that improvements to the content and navigation could result in even higher conversions. This was seen as a golden opportunity to increase sales by improving the awareness and presentation of the brand’s story. Thus, a complete project to redesign this section of the website was born.

Here is a summary of the project from the stakeholders’ perspective:

  • High-level project goal
    Increase conversions and sales.
  • High-level project strategy
    Leverage the history and technology section of the website.
  • High-level project tactic
    Improve the content and navigation of the section to increase user engagement, better communicate the benefits of the products, and drive users into the conversion funnel.

Unfortunately, rather than communicate this to the design team, the goal for this redesigned section of the website was presented as follows:

Create a good user experience.

Sigh. There’s that phrase again.

The Problem

The designers were given a nebulous tactic masquerading as a goal. This meant that they had minimal understanding of the true objective of the project, which put them in a poor position to understand the problem and to hone the strategy and tactics to solve it.

To make matters worse, the lack of well-defined high-level goals, strategies and tactics made it difficult for the designers to define the architecture of the experience, in turn making it nearly impossible to set user goals and business goals for every page that needed to be designed.

Banksy Rat Bed in The S.M.A.R.T. User Experience Strategy
(Image: numberstumper)

To make a long story short, the designers spent four months working through unsuccessful concept pitches and design revisions. The concept behind the designs constantly changed, and the content and features failed to support a cohesive user story. Meanwhile, designers and stakeholders had different expectations of what this section of the website was meant to accomplish, so solutions rarely satisfied both parties. Nobody knew the needs of the user, and the needs of the business were but a neglected thought in the shadow of “creating a good user experience.”

After these four months, there was zero progress. Not only was the project’s situation dire, but the lack of approved and delivered work was eroding the team’s morale. With no concrete user or business goals to satisfy, the team aimlessly pursued a “good user experience.” It was like being told to drive but not given a destination.

The Solution

I was subsequently pulled into this team as the project and design lead. My first priority was to bring awareness and understanding of the high-level project goals, and then lead the team through a comprehensive exercise to document the user goals. Although we didn’t have access to detailed user studies and customer information to create data-driven personas, we did our best with anecdotal experiences, competitive analyses, and website analytics to create user goals for each page. We then worked with the cross-functional teams to understand the business goals and KPIs.

Using these goals, I led the designers to write thorough content and feature requirements. The benefit to this approach was that all content and features were made to serve documented user or business goals. This encouraged product simplicity and reduced scope creep. These goals and requirements were then reviewed and refined with all stakeholders. Once expectations were universally understood and accepted, the team proceeded to create the architecture, interactions and designs.

This comprehensive methodology took less than three months. But the magic is not the methodology itself, but the discipline to identify concrete goals that satisfy five basic criteria.

UX S.M.A.R.T. Goal Criteria

As I mentioned earlier in my competitive cycling example, my improvement as an athlete was based on goals that each met the five criteria of the S.M.A.R.T. goal-setting technique:

  1. Specific,
  2. Measurable,
  3. Attainable,
  4. Realistic,
  5. Time-based.

This technique can be applied to documenting the criteria for user goals and business goals:

  1. Specific,
  2. Measurable,
  3. Actionable,
  4. Relevant,
  5. Trackable.

With these criteria in mind, what would be considered a S.M.A.R.T. goal?

S-m-a-r-t-blank in The S.M.A.R.T. User Experience Strategy

S.M.A.R.T. User Goal Examples

Let’s use the product detail page for a fictional e-commerce website to illustrate. A product detail page is a page on which shoppers can learn more about a product for sale and add it to their shopping cart. It typically includes images of the product, the price, a description, and an “Add to Cart” button. Here is an example from a well-known fruit company:

Apple Store Pd Cropped in The S.M.A.R.T. User Experience Strategy
The product detail page for earbuds in the Apple Store. Notice the images, price, description and “Add to Cart” button.

Based on a competitive analysis of many e-commerce product detail pages (and on personal experience from working with and studying how consumers make purchasing decisions), here are some user goals for the product detail page of a fictional e-commerce website.

Primary user goal (UG1):

I want to learn more about this product’s design, features and specifications to determine whether it fits my budget, needs and preferences.

Secondary user goal (UG2):

I want to purchase this product.

These goals meet the UX S.M.A.R.T. goal criteria because they are:

  • Specific
    By stating exactly what the user needs to accomplish, these goals help us maintain scope and stay focused on designing content and functionality that is critical to our user’s success.
  • Measurable
    For the primary goal, we can measure clicks to determine how users are engaging with the content. Alternatively, one-on-one interviews or customer surveys could provide qualitative insight into whether your content is relevant to the user’s interests. For the secondary goal, we can measure the percentage of visitors to the page who click “Add to Cart.”
  • Actionable
    Because the goal is specific, we can readily identify content and functionality that satisfies the user’s goals. In this example, because users want to learn more about the product’s design, large product images should be included.
  • Relevant
    These goals are appropriate for a product detail page, but not for a return policy or terms and conditions page. By keeping the goals highly relevant, the content and features that we introduce to satisfy those goals will be relevant, too.
  • Trackable
    There’s no point being measurable if the data cannot be tracked over time. This is essential to determining the immediate, short-term and long-term success of our design and its future iterations.

In contrast, here’s a DUMB user goal:

I want a Web page that’s easy to use. (i.e. I want a good user experience.)

That’s not a witty acronym, and it doesn’t hide the fact that this user goal is not specific, measurable, actionable, relevant or trackable. It fails all five criteria because it fails the first: specificity. A good user experience has many facets, and without targeting a specific aspect of the page or product experience, there’s no action (strategy and tactic) to address it. If a goal is not actionable, then it has no reason to exist because there is no end towards which effort and action can be directed. Similarly, if the goals are not measurable, then there is no way to gauge the successes or failures of our actions, and subsequently no way to understand the product’s performance over time.

S.M.A.R.T. Business Goal Examples

UX S.M.A.R.T. goal criteria can also be applied to business goals. They are particularly relevant because businesses are run by numbers: number of clicks, number of customers, number of dollars, the list of measurable metrics continues. So, let’s take real-life business goals for the same product detail page of our e-commerce website as an example:

Primary business goal (BG1):

We want to increase the ratio of add-to-carts to page views for the product detail page to x%.

Secondary business goal (BG2):

We want to increase cross-sells to y% of total add-to-carts.

Just like the preceding user goal examples, these business goals meet the UX S.M.A.R.T. goal criteria because they are:

  • Specific
    By stating exactly what metrics the design needs to affect, these goals help us maintain scope and stay focused on designing content and functionality that will put us in a position to hit our targets.
  • Measurable
    For the primary goal of increasing conversions, we can measure the number of page views and how many resulted in an add-to-cart. For the secondary goal of increasing cross-sells, we can measure the number of clicks on cross-selling products.
  • Actionable
    Because the goals are specific, we can create more targeted strategies to accomplish them. For the primary goal of increasing add-to-carts, this could mean making the content on the page more relevant to users’ goals, or something as simple as improving the success of the add-to-cart button. For the secondary goal of increasing cross-sells, this could entail changing the visibility of cross-selling items (assuming we have already done a good job of selecting which related products to promote).
  • Relevant
    The relevance of this goal depends on the high-level objectives of the project. If the objective is to reduce the number of customer support calls each day, then this goal might not be relevant. But if the objective is to increase total sales revenue across all products, then it is very relevant.
  • Trackable
    We can count the number of page views and add-to-carts over an extended period of time.

By contrast, here’s a dumb business goal for the product detail page:

I want to make more money.

This is a poor business goal because it’s not specific and might not be relevant to this page at all. There are many ways to make more money, and without specificity in the strategy to accomplish this, creating a successful plan of action will be much more difficult. Remember, if a goal is not actionable, then it has no reason to exist because there’s no end towards which effort and action can be directed.

UX S.M.A.R.T. Goals Applied

So, now we understand the criteria behind well-defined S.M.A.R.T. goals and have applied them to the user and business goals for the product detail page of a fictional e-commerce website. How can we use this to our advantage as we move forward with the architecture and design of the page?

Associated Content and Feature Requirements

Because the goals we’ve defined are specific and actionable, we are able to propose content and features that directly satisfy them. Let’s revisit the four high-level goals of our product detail page and attach appropriate requirements to them.

Primary user goal (UG1):

I want to learn more about this product’s design, features and specifications to determine whether it fits my budget, needs and preferences.

Content and features required to satisfy this goal:

  • Relevant images that represent the product as a whole;
  • Relevant images (such as enlarged views and alternate angles) that show the product in detail;
  • General description that provides a brief overview of the product’s purpose and benefits;
  • Specifications that are relevant to consumers of this product type;
  • Product variations or options (such as color, size);
  • Selling price.

Secondary user goal (UG2):

I want to purchase this product.

Content and features required to satisfy this goal:

  • Selector for product variations or options;
  • Customer satisfaction guarantee (such as return policy, privacy policy);
  • Quantity selector;
  • “Add to Cart” function.

Primary business goal: (BG1):

We want to increase the ratio of add-to-carts to page views for the product detail page to x%.

Content and features required to satisfy this goal:

  • Reference user goal 1,
  • Reference user goal 2.

Secondary business goal (BG2):

We want to increase cross-sells to y% of total add-to-carts.

Content and features required to satisfy this goal:

  • Related products that the user might also be interested in (for example, if the user is looking at the detail page for a small digital camera, recommend a small case to put it in).

Because everything must serve a documented goal, scope creep during the project’s lifecycle is reduced. This is not to suggest that content and features beyond these goals cannot be included. Components such as global navigation or a site-wide search box might be required even though they are not the purpose of the page. Determining what belongs on a page is admittedly not as black and white as these example might lead one to believe.

That said, setting content and feature requirements based on S.M.A.R.T. goals does help to determine the visual hierarchy of information on the page. This is extremely helpful during the wireframing stage.

Pd Wireframe Labelled in The S.M.A.R.T. User Experience Strategy
A wireframe for the product detail page of a fictional e-commerce website. The user goals (UG1 and UG2) and business goals (BG1 and BG2) correspond to those outlined above. Download the complete wireframe for this example.

As we can see in the above annotated wireframe, the content and features that satisfy primary user and business goals (labelled UG1 and BG1) are more prominent in scale and placement than those that satisfy the secondary goals (UG2 and BG2).

Now, having applied S.M.A.R.T. goals across the planning and architectural phases of a project, we can see the benefits of this UX strategy, as follows:

  • Goals are specific, measurable, actionable, relevant and trackable.
  • Because the goals are specific and actionable, we can attach appropriate content and feature requirements to each one. Because the goals are relevant, these requirements are relevant, too.
  • The hierarchy of the content and features is determined by the hierarchy of the goals that they are attached to. This informs the architecture of the wireframes.

With these benefits in mind, we can begin to understand how this positively affects other stages in the project’s lifecycle:

  • Wireframes with well-informed structures and content are solid foundations on which to design higher-fidelity mock-ups.
  • Because the goals are measurable and trackable, we can determine the success of the design during testing, learn from it, and make improvements in subsequent iterations.

Ultimately, these all contribute to our ability to understand the problem and craft an appropriate strategy and tactic to solve it. Our discipline in gaining focus in the earliest stages of a project will determine our ability to maintain focus when designing the functional aspects of the product at the end.


A great user experience is the result of setting concrete goals that meet both user goals and business goals. Unfortunately, I have seen many teams kick off a project with nothing more than a goal of, “Let’s create a great UX!” While a noble thing to strive for, it’s not specific, actionable or measurable. It contributes nothing to the planning or design phases, and it is the UX equivalent of a motivational high-five.

Banksy Flower Thrower1 in The S.M.A.R.T. User Experience Strategy
(Image: Dickson Fong. Original artwork: Banksy.)

Banksy once said:

“Artwork that is only about wanting to be famous will never make you famous. Fame is a byproduct of doing something else. You don’t go to a restaurant and order a meal because you want to have a shit.”

Likewise, a good user experience is the byproduct of many brand, product, design and development decisions. As designers, we must collaborate with our clients and ensure that we thoroughly understand the needs of their business and target audience. Only then can we be empowered to create appropriate strategies and tactics to achieve them.

So, don’t try to “create a good user experience.” Create a S.M.A.R.T. one.

Additional Resources


© Dickson Fong for Smashing Magazine, 2011.

September 06 2011


Building Better Software Through Collaboration: Whose Job Is It, Anyway?

Advertisement in Building Better Software Through Collaboration: Whose Job Is It, Anyway?
 in Building Better Software Through Collaboration: Whose Job Is It, Anyway?  in Building Better Software Through Collaboration: Whose Job Is It, Anyway?  in Building Better Software Through Collaboration: Whose Job Is It, Anyway?

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

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

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

Pyramid1 in Building Better Software Through Collaboration: Whose Job Is It, Anyway?

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

Let’s look at each of these levels.

Level 1: Make Sure Everyone Understands The Problem

Software-front-page in Building Better Software Through Collaboration: Whose Job Is It, Anyway?
Photo credit: TransGriot

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

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

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

Level 2: Empower Teams To Do Great Work

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

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

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

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

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

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

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

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

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

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

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

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

Level 3: Create A Better Design And Development Lifecycle

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

The Design And Development Process

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

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

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

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

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

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

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

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

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

The Prioritization Process

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

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

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

This meeting would have several very positive outcomes:

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

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

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

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

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

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

Pc in Building Better Software Through Collaboration: Whose Job Is It, Anyway?

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

Level 4: Communicate Better

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

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

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

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

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

Level 5: Prove That It Works

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

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

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

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

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

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

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

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

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

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

Go. Make it happen.


© Rian van der Merwe for Smashing Magazine, 2011.

June 27 2011


February 21 2011


Examining The Design Process: Clichés and Idea Generation

Advertisement in Examining The Design Process: Clichés and Idea Generation
 in Examining The Design Process: Clichés and Idea Generation  in Examining The Design Process: Clichés and Idea Generation  in Examining The Design Process: Clichés and Idea Generation

Where do good ideas come from? It’s a question that matters a great deal to designers, yet seems to be curiously discounted in the common perception of graphic design. Any time I talk with, say, an uncle at Thanksgiving about my work, I’m reminded that, in most people’s minds, the job of being a designer is mainly a matter of learning a set of computer applications — programs which, when properly operated, presumably do the work of generating ideas on their own.

If pressed further, most people will offer up some version of the Genius Theory: the idea that certain individuals are simply blessed with a force called ‘creativity’ that (as the theory goes) allows them to summon remarkable visual solutions to problems where the rest of us see only a blank canvas.

In this article, we will look at four examples of successful visual solutions created by well-known designers, and examine the process by which each designer arrived at his final concept. In each case, we will see that the solution did not arrive as a sudden flash of inspiration from out of the blue; rather, a good idea emerged methodically out of a sensible analysis of readily-available ideas and impressions.

In particular, we will zero in on the dual role played by clichés in this process: while clichés can derail the creative process, for seasoned designers they can act as the building blocks for effective solutions by telling them what not to do. In the final balance, we will see that good ideas are not created by magic, nor are they generated by computers — the process of developing them is a skill that can be learned, taught and practiced, and, like a muscle, gets stronger the more it is used.

Exhibit A: Imaginary ‘Drive Safe’ Campaign for Teens

Suppose we are working together at a studio and we receive a job to design a poster for a public service campaign aimed at educating teenagers about the dangers posed by drinking and driving. We meet for our first internal review to critique our initial ideas, and I present the following proposal:

Unicorn2 in Examining The Design Process: Clichés and Idea Generation

In this case, the problem with my work is painfully easy to diagnose: the image simply has no connection to the message. It may or may not be nicely illustrated… but this is somewhat beside the point: unless it’s trying to speak to eight-year-old girls, this poster is not going to make a meaningful impression on its audience. If we imagine a spectrum of all possible design solutions to this job ranging from ‘totally clear’ to ‘totally unclear’, this would rank pretty far in the latter direction:

Graph12 in Examining The Design Process: Clichés and Idea Generation

‘Fine,’ I reply, tearfully storming back to my desk. A week later, I present a revised concept, confident that it speaks to the audience more directly:

Stop4 in Examining The Design Process: Clichés and Idea Generation

This time, the problem is a little harder to put one’s finger on. The image communicates clearly… but it does so at the cost of boring us half to death, with no humor, inflection or engagement. Also disturbing is the fact that I’m using a pre-existing visual symbol from the urban environment — the stop sign — to do my communicating for me.

If we had never before seen a red eight-sided shape with the word ‘STOP’ inside, it might be a powerful and abstract creation; as things stand, however, the symbol has become so deadeningly familiar that it has lost all capability to impact us in a meaningful way. In my eagerness to communicate clearly, I’ve run headlong into the arms of a cliché — which, in the context of graphic design, can be defined as  ‘an image that may or may not have been memorable at one point, but has since been so overused that it has lost all ability to surprise.’

Graph1b1 in Examining The Design Process: Clichés and Idea Generation

The Problem of Clichés

This imaginary case study demonstrates why clichés are such a stubborn problem for designers. In the example above, I didn’t arrive at a cliché because I’m a terrible or uncreative person; I arrived at it because I took the most readily-available solution from the environment around me, and stopped there.

Clichés are hard to banish from our thoughts because their sheer familiarity makes them appealing: they are always at hand, ready to be put into service; and — especially if we are working under pressure — their familiarity offers a certain amount of reassurance, a guarantee that we won’t be misunderstood. Design solutions that employ clichés are the hardest for me to critique in the feedback sessions that I run as a teacher: often, there is the frustrating sense that the student has done nothing wrong exactly, yet the overall design leaves us wanting more.

Most depressing of all is the fact that clients often prefer clichéd solutions to original ones. This is the syndrome of the Chinese restaurant owner who wants us to use the same tired chopstick lettering for her sign because ‘that way, people will know it’s a Chinese restaurant’. Wanting only to be correctly identified, the client is drawn to the universality of clichés: they have, after all, the same meaning for everybody within a particular culture, which — if only they weren’t so hackneyed — would make them an ideal communication tool for designers.

In the haste to fit in, the need to stand out has been forgotten. It is our responsibility as designers to make the case that design can serve both ends at once: it can speak plainly while still leaving a mark on its audience.

Ethnic-signage1 in Examining The Design Process: Clichés and Idea Generation

Every area of graphic design has its built-in clichés. But none more so than images that seek to convey a sense of ethnicity, where the same predictable type choices pop up again and again (shown left to right: Sunamy, Papyrus, Neuland). See Rob Giampierto’s indispensable article New Black Face for more on this topic.

Clichés, in short, are the empty calories of the design world: like junk food, they are available everywhere and easy to consume, but pass through us without leaving nutrition behind. Their prevalence arises from the shared nervousness with which designers often view their clients and their clients view design: satisfied merely to get to the point across in an obvious manner, both sides neglect to create a message that will live in a viewer’s memory and foster long-term recognition and loyalty.

If the above hypothetical campaign has given us examples of two flawed extremes — one too obvious and the first not obvious enough — what does it look like when a designer hits the sweet spot in between? And, more importantly, how did he or she get there?

Graph22 in Examining The Design Process: Clichés and Idea Generation

Exhibit B: Craig Frazier

In 1987, the designer Craig Frazier did a poster for this very purpose, a public service campaign aimed at persuading kids to not drive home drunk from their senior high school prom. His poster:

Frazier in Examining The Design Process: Clichés and Idea Generation

Like Goldilocks’ bowl of porridge, this solution is just right: it communicates its message with appropriate urgency, but the weapon of surprise is also part of the attack. “It has an art quality that removes it from the realm of ordinary public service campaigns,” Frazier noted in a 1996 interview with Critique magazine, in which he also identified it as a personal best. “It presents a visual riddle that’s almost attractive at first glance, but gets more gruesome the more you study it.”

The unconventional presentation of the subject matter requires us to spend a split second visually decoding the image, discerning its story… and, in that moment of cognitive engagement, a connection is formed between viewer and image. The abstract and original treatment of the topic allows the poster to sneak past our defenses — in Frazier’s words, “it proves that you don’t have to be condescending to convey a deadly serious message.” Whereas the Stop Sign approach droned authoritatively at its viewer, this execution lures the onlooker into a perceptual dialogue, and refrains from talking down to its touchy teenage audience (note the quiet treatment of the tagline in the lower left corner).

In sum, by avoiding an overly obvious delivery, the designer cleared the way for a work that leaves a lasting impression: “I still get tingles when I think about the poor guy on the road,” Frazier commented nearly ten years later. “I have a visceral, emotional reaction.” Impactful? Check. Emotional? Check. Clear in meaning? Check. “What makes the poster work is the same thing that makes any good ad or brochure work,” Frazier concludes: “It’s engaging and memorable to its intended audience.”

So how did he get there? Not, as my uncle might assume, by virtue of being a creative genius who effortlessly vaults over commonplace ideas (nor simply by owning a computer). Rather, to judge from his own comments, Frazier arrived at his solution by taking accurate stock of the commonplace and determining in what direction the fresh territory lay:  “These kids had already been hit with plenty of preaching and scare tactics about drunk driving and drug abuse, not only from their parents, but also the media,” the designer recalled, explaining his thought process.

“I knew what I didn’t want to do — a poster that presented the consequences in such a grizzly fashion that the student could dismiss it as another image from a Highway Patrol film. Even though I knew these images could be effective — like the ads of that time by Fallon McElliot — I wanted this poster to be gripping, not scolding.” Put in the simplest possible terms, Frazier came up with his idea by identifying the resident cliché and then setting out in the opposite direction.

Simple as this approach might sound, the tangible benefits are worth taking note of:  “All reports indicated that the students received the poster well,” Frazier recalled, “and many students requested copies for their bedroom walls. The effectiveness of any poster is hard to measure, but the fact that they looked at it, and are still looking at it, makes it a success.” What the reaction to Frazier’s poster, and the process behind its making, point to is the surprisingly transparent nature of graphic design — the extent to which the creator’s subjective experience in making a piece bleeds over into the observer’s reaction to it.

Creative solutions that take no searching on the part of the designer rarely make a mark on the audience either. If the designer is willing to set out in a direction whose end point is not immediately apparent, on the other hand, the journey taken is relayed back to the viewer in the split second of perception, and this experience of distance — of having a message relayed to us in terms that are clear and yet outside the ordinary — can make the experience of seeing memorable. In the next section, we will look at another work whose dramatic impact derives from the fact that its author moved beyond his immediate first impressions in order to create it.

Exhibit C: Art Spiegelman

Best known as the creator of the acclaimed graphic novel Maus, Art Spiegelman was working as a staff artist for the New Yorker magazine on September 11th,  2001. A resident of downtown Manhattan, he lived a short distance from Ground Zero and was grappling with the day’s events when a call came through from the New Yorker office explaining that, incredibly, the magazine would be putting out a special issue at the end of the week and needed a cover from him as soon as possible.

Settling down to a daunting task, Spiegelman started out by painting his most immediate visceral impressions of the day: the vivid blue sky that hung over New York on that day and its incongruity with the smoke, ruin and destruction that had transpired. After a while, he had created an illustration that looked something like this:

110-stories in Examining The Design Process: Clichés and Idea Generation

We know what this image looked like because Spiegelman later used it for the cover for an anthology of writing about the September 11th attacks called 110 Stories. But, for his magazine cover, Spiegelman rejected this direction. Why? “I was barking up the wrong tree,” he later told The Progressive magazine: “It had a blue sky and orange building; it was channeling [René] Magritte, with the thought bubble, ‘It’s such a nice day, what a bummer.’ It was a reasonable cover for a book that came out a year later, but it just wasn’t sufficient, because anything with a nice blue sky and pretty orange building was just too pretty. And pretty outweighed whatever meanings those shrouds had.”

Spiegelman’s use of blue sky here isn’t a cliché in the conventional sense… but in the context of his design process, it was functioning in much the same way that a cliché does: a too-readily-available impression that speaks too literally to its audience and thereby dulls the piece’s potential emotional charge.

Rather than trashing his canvas and starting from scratch, however, Spiegelman simply responded to what he didn’t like: “I kept trying to gray down and dim down the image, so, OK, a less blue sky, less orange buildings. [...] Then I finally said to Francoise that it should just be a black-on-black cover because every time I was walking to my studio from my house I kept finding myself turning around to make sure the towers were not there, as though they were a kind of phantom limb”:

Spiegelman in Examining The Design Process: Clichés and Idea Generation

What binds both Frazier and Spiegelman’s accounts together is the evidence that neither artist could have visualized his final solution from the outset of the process. Both used (perhaps it’s even fair to say needed) the intermediary steps of (a) identifying cliché and (b) reacting to cliché to set them in the right direction.

Exhibit D: Ivan Chermayeff

Our fourth example involves a case where simple associations were not so much rejected as stitched together in an imaginative manner to create a complex and engaging message.

For decades, the office of Chermayeff & Geismar has managed to produce memorable images with a narrative capability, pieces that quickly tell a story in an engaging manner. One such work is Ivan Chermayeff’s poster for a television series called England Between the Wars that covers the diplomatic efforts that transpired between 1914 and 1940. Even more overtly than Craig Frazier’s poster, this work deliberately presents a puzzle to the viewer, whose enjoyment of the piece lies in the process of assembling its visual clues:

Chermayeff1 in Examining The Design Process: Clichés and Idea Generation

The designer did not, however, set out with the intention of being clever. When I emailed Chermayeff to ask about the challenge of England Between The Wars, he replied as follows: “A title which raises many questions. The process of illustrating such a title was the search for images that will immediately answer those questions. Together those images must connect as a coordinated and related whole image.”

“What are possible symbols of World War I and World War II that existed and that are immediately recognized in our time?” Note that, again, the process again begins with the gathering of simple, readily-apparent associations:  ”Maps, armaments, tanks, nationalities and their physical characteristics, trends, battlefields — there are many, many things. Most of them too complex to be a simple, resonating image.” In response to the problem — complexity — the designer sets out looking for its opposite, simplicity: “One thinks and searches, one looks at the available visual records of two world wars, and what comes up —Helmets!”

“Helmets evolved and they changed over the years. But they are always there in the photographs. Once seen, they are seized. One can hold them in one’s hand, and everyone recognizes them. So what remains to fill the gap between 1918 and 1940? What is the image of the 22 years between to match the simplicity of the two helmets at either side? Talk and discourse and ambition all surround the nations engaged in these two conflicts. The common thread is diplomacy. What is like a helmet but not a part of war? A hat! A diplomatic hat of a statesman in the twenties and thirties is the homburg, and it fits between the wars on the head just like a helmet.”

In this case, the final design does not so much refute the clichés of the field as cleverly assemble them. But the thought process behind it works in the same way: it starts with the readily-available information and works methodically, step by step, to react to what is lacking in the first sweep of associations.

Exhibit E: Jesse Bennett-Chamberlain

It seems to be easier to talk about idea generation in the context of print than web. A designer’s success, or lack thereof, in coming up with a good idea shows itself more plainly when the medium is something like a poster (as in the Frazier and Chermayeff examples above) or a magazine cover (Spiegelman), which are only called upon to communicate a single visual message to the onlooker. A typical web interface, in contrast, must balance a host of competing priorities — navigational, functional, hierarchical — the sum of which can frequently obscure our understanding of how successful the designer was in one particular area.

Nevertheless, web design needs fresh thinking just as much as print design, and the role played by clichés can be every bit as detrimental. Jesse Bennett-Chamberlain’s account of redesigning the website for Steinway and Sons explains how a formulaic approach to one issue (in this case, layout) can deprive the design of strength in another key area (aesthetic/emotional impact). Bennett-Chamberlain has a nice write-up of this project in the Notebook section of his site, — the following discussion is drawn from his account and from follow-up questions I posed to him by email.

Having never worked with the client before, Bennett-Chamberlain recounts that he “played it safe” in his initial process and “started off with a design that closely followed a wireframe that they provided”:

Steinway-schematic in Examining The Design Process: Clichés and Idea Generation

This wireframe suggests a classic template for usability — “a layout that was very typical,” Bennett-Chamberlain recalls, “and reminded me mostly of Apple”. (In fact, you can see that this layout is almost exactly that of Apple’s homepage). While there is nothing necessarily wrong with following the lead of an acclaimed site like Apple’s, in this case, the boxy, conventional guidelines proposed by the client’s wireframe led to an initial design that failed to do justice to the subject matter:

Steinway1 in Examining The Design Process: Clichés and Idea Generation

Not a bad design, by any means… and yet if you removed Lang Lang from his piano bench and placed him inside a luxury car, this could quickly become a site for Audi or Lexus. “I thought the initial design was okay,” Bennett-Chamberlain explains, “but it still didn’t feel ‘Steinway’ to me. It seemed a bit underdeveloped, too easy of a solution for such an elegant brand.”

Much of the problem lay with the cookie-cutter wireframe: “Although the image of Lang Lang was dynamic and had some energy, the layout of the site felt pretty linear, boxy, and well… boring.” Lost in the conventional presentation were the aspects of the grand piano that make it truly remarkable: its shape, its contours, and, of course, its sound. “I wanted the piano to be in the spotlight,” he recalls, “and not share the stage with anything else.” Bennett-Chamberlain presented a variant design that strayed a bit from the recommended wireframe by “placing the piano front and centre, and then building the site around it”:

Steinway21 in Examining The Design Process: Clichés and Idea Generation

In the final iteration, Lang Lang has been reluctantly whisked off the stage, and the instrument itself is the star of the show. The piano’s distinctive contours are emphasized by the graceful arc placed behind it, and by the decision to have its lid peek up above the designated promo area into the top nav. The background motif of piano strings has been ramped up to create a semi-abstract, radial representation of sound (indeed, you can almost hear the piano in the final design).

In the nav bar area, the usual ‘logo left’ convention has been discarded here for centered treatment that makes you feel like you’re sitting on the bench itself and gazing at the Steinway and Sons trademark sitting over middle C. Yet nothing has been lost in terms of ease-of-use compared with Bennett-Chamberlain’s original design — it simply took an effort of self-critique and problem-solving to do justice to both the functional and aesthetic possibilities of the project: “I figured that if these guys can spend a year making a single piano, I could probably spend an extra couple hours here and there on refining these details.”

Putting It Into Practice

These works by Frazier, Spiegelman, Chermayeff and Bennett-Chamberlain are classic examples of what designers like to call ‘process work’ or ‘methodology’, terms that refer to a method of drawing ideas, direction and inspiration from the process of working on the design itself, rather than simply having a fixed destination from the outset. No one can write step-by-step instructions on how to do this — the entire point, after all, is to react, rather than obeying fixed directives — but there are certain steps we can take at the outset of a project that help clear the way to let this process happen:

  • Start with a sketchbook, not a computer. There was a time when I once suspected that the teachers who tried to impress this point on me were just cranky technophobes… but over time, I came to appreciate the wisdom of this suggestion. The computer is a bad companion to start with because its particular toolset pushes us in certain directions (towards clearly defined shapes and hard edges) and because it tempts us to focus overly on execution (by offering up sexy drop shadows and whatnot) before our concept has really come together.
  • Using your sketchbook, start by drawing every association you come up with for the subject matter. Draw it quickly, and don’t be critical. At this stage, it’s not about making pretty pictures, and it’s not about evaluating your ideas (in fact, the ability to turn the critical part of your brain on and off is one of the most helpful tricks you can develop).
  • Don’t try to avoid clichés — let them happen. Trying not to think of clichés is like the old joke where someone says ‘Don’t think of a pink elephant.’ It’s best to get them down on paper and get them out of your system.
  • Once you’ve jotted down every association you can think of, take a break, come back and jot down a few more. Then, take a longer break…
  • Come back with fresh eyes and look at what you have in front of you. Now is the time to be critical, but also to be fair. Seeing our own work clearly for its merits, without bias and defensiveness, is one of the hardest things for graphic designers to do. George Orwell wasn’t thinking about graphic designers when he wrote, “To see clearly what is in front of one’s face requires constant struggle,” but he might as well have been.


There is no single answer to the question of where good ideas come from. Some designs actually do seem to come out of thin air, like the Citibank logo that Paula Scher infamously drew on a napkin during an early meeting with the client. But a great many more good ideas come about through the incremental process described in this article, of gathering and making decisions about readily-available information.

The viability of this approach suggests that coming up with good ideas is not a matter of genius, but rather simply a challenge of seeing clearly and thinking sensibly. The good news that this implies is, idea generation is a learnable skill that can be cultivated in many of us, not just in a chosen few. The only disappointing part is that you don’t get to feel like a genius while you’re doing it.

If idea generation is a process that is accessible to everyone, then what accounts for the fact that it can be so hard to pull off? Part of the answer lies in our inability to get out of our own way, a condition which stems largely from our ideas about what it means to be a ‘professional’. The term ‘professional’ is generally used to connote a person who is in control of their work process at all times… and, yet, as we’ve seen in this article, the condition of absolute control is rarely a place where exciting design comes from.

“What is required in our field, more than anything else, is the continuous transgression,” Milton Glaser writes in his wonderful essay Ten Things I Have Learned. “Professionalism does not allow for that because transgression has to encompass the possibility of failure and if you are professional your instinct is not to fail, it is to repeat success.” Graphic design is one of the few fields where it works to our advantage if we can let go of the reins from time to time, a feature that makes it to be an exhilarating place to work if we can manage not to find it unnerving.


I would like to thank Craig Frazier for his assistance in locating a copy of the Critique ‘My Best / My Worst’ interview used in this article, and also Ivan Chermayeff and Jesse Bennett-Chamberlain for taking the time to answer my questions.


  • Neumeier, Marty and Frazier, Craig (1996) ‘My Best / My Worst’, Critique, Summer 1996
  • Siegal, Nina (2005), ‘Art Spiegelman Interview’, The Progressive, January 2005
  • Unicorn illustration by Xploitme, used under Creative Commons license

Other Resources

You may be interested in the following articles and related resources:

(ik) (vf)

© Dan Mayer for Smashing Magazine, 2011. | Permalink | Post a comment | Smashing Shop | Smashing Network | About Us
Post tags: business, cliche, Design, generation, idea, ideation, process

December 14 2010


The process and challenges of a website design

Jon Hicks has a nice process post on his blog about the recent challenges he faced while designing the ShelfTheme. I always enjoy reading others process and Jon’s does not fall short.

September 21 2010


August 03 2010


Thoughts on design processes

I recently posted a new shot on Dribbble consisting of some “process” work, or as Matthew Smith personally labeled DesignLite™ in a recent post. It created quite the discussion on Dribbble concerning usage of terms and thoughts on design processes. Have a read through the varied comments.

“[...] as it uses prototyping for layout, greyscaling for lights and darks and visual importance of elements, typographic hierarchy, typeface selection, balance, structure, flow….etc. Even some of the interactive elements are planned for. I think if there was a “correct” term it would be called “process.”

May 31 2010


Design & Build a Grid Based Web Design with CSS

I’m currently working on a new Wordpress theme called ♥grid, which lives up to its name with a clear grid based design. Follow this step by step walkthrough of the design and build process, right from the initial Photoshop concept, through to writing the HTML structure, styling up with CSS then adding clever functionality with the jQuery library.

View the LoveGrid demo

The ♥grid concept is pretty minimal in its design, using a limited colour palette of light grey, dark grey and a highlighting colour of red. The background of the design makes use of a subtle texture for a tactile feel, but the main feature is the strict grid based layout. The design makes use of a 24px baseline and 6 column grid, which becomes a design feature itself as it remains visible as part of the design.

View the demo

The design concept

The design of ♥grid started in Photoshop. I always begin my website designs with a fairly large canvas of around a 1680px wide, this helps me gauge how the site will look on a typical widescreen monitor.

The background of the canvas is filled with a light grey tone, then given a touch of texture using the Photoshop Noise filter at just 3%.

A new 24×24px document is created, in which the repeating pattern for the baseline grid is created. Just a single 1px line across the lower edge of the canvas is all it takes. This pattern is then defined as a pattern.

The pattern is then filled across a new layer and set to Multiply to render the white area transparent. The vertical grid lines are drawn manually, then duplicated and moved by hand. The cursor keys nudge the lines by 1px, or by 10px while the Shift key is held. Gutters are measured at 21px, and the column widths are 139px.

All the vertical lines are grouped together once six columns are created, then aligned centrally on the document. The basic grid is now ready to be decorated with the actual page elements.

The logo comes first in the top left corner. A selection is made within the first column and filled with red.

The ♥grid logo is then placed inside the logo container, and aligned on the baseline grid.

Navigation elements are then placed on the same baseline, and aligned to the right of each of the five remaining columns. Being links they’re given a red colouring.

Being a theme for a blog the content is made up of sample blog posts. The first post is laid out and spread across columns two to six. Georgia is used for the post titles as a stark contrast against the Helvetica body text. The body text itself is edited so the line height matches the height of the baseline grid.

The first column is reserved for some meta information about the post, such as post date and category. These are laid out in a lighter grey to give less prominence, but at a larger type size. The 24px line height is maintained to keep the consistent leading across the design.

Read more buttons are styled up with a red background and serif Georgia text to give the links extra prominence.

The design begins to take shape as two sample blog posts show the white space and structure across the layout.

The lower portion of the design switches to a darker grey, giving a contrasting footer area. A large selection is filled with a dark grey and given the same noise treatment as the background.

The footer area features a range of lists, these lists begin with two short lists of Categories and Social links. Headers are set in Helvetica, while the links are treated with Georgia at double the line-height.

Links in the lower portion of the design are set in white to give contrast against the dark grey background. The first two lists fit within a single columns, while the second two span across two columns.

Now the design concept is complete, the individual images can be exported ready for the building stage. This starts with the repeating background graphics, taking into account the gridlines so they are recreated when the graphic repeats.

Being a lightweight design, the number of image files is pretty low. Two versions of the background are exported, one with, and one without the grid. This will be developed as a feature at a later stage where the user can toggle the grid lines on and off.

Creating the HTML structure

The next stage of the build is to write out the HTML structure. This begins with a typical webpage layout with Doctype, head and body.

The top portion of the design is contained in a <div> with an ID of upper, this will be a hook for the baseline grid pattern in the CSS stage. The logo and navigation list are written out as <h1> and <ul> elements.

A <div> with an ID of main contains the main content, and each post is separated with individual <div> elements. Inside each post the content is split into two <div> elements, so the post content and post details can be floated side by side. Despite the details coming first in the design, they are written second in the HTML to keep a logical order of information, these can be positioned correctly by floating them with CSS. Post titles are laid out as <h2> headings, following on from the <h1> used in the header. <p> elements with a class of btn are used to represent the read more buttons.

In the lower portion of the design, each panel is laid out in its own <div>, with <h3> elements identifying the lists of anchor links.

After the four list panels, the three credits are laid out in a <ul>. Information is given in the anchors, but the actual logos will be displayed using CSS. Finally a back to top link is placed in a <p> element. This back to top link targets the #header, but will later be enhanced with jQuery so the page scrolls automatically, but it’s important to maintain the functionality using a plain old same-page anchor for those without Javascript enabled.

Styling the design with CSS

With the HTML strucutre in place, the design can now be styled with CSS to match the original Photoshop concept. The CSS starts with a reset to remove any browser defaults, then begins styling up the page body. A global font style of Helvetica is set, followed by a line-height of 24px to match the baseline grid. The baseline grid itself is added as a background-image to the body, whereas the vertical gridlines are set as background images on the #upper div.

The <h1> is given specific dimensions and a red background to match the design. The”Show/Hide Grid” button in the header is styled accordingly with the small icon as a background image, but is set to visibility:hidden;. Being a function that relies on Javascript, this button will be made visible again using jQuery so users that don’t have Javascript enabled won’t see it. Navigation <li> elements in the header are floated side by side and given specific widths and margins to match the size of the grid columns and gutters.

Fonts are styled up in the #main section, with headers being set in Georgia, body text set in grey Helvetica and buttons set with a red background. Each elements also has a 24px bottom margin to bump the following content down an extra line on the baseline grid.

Each post <div> has 48px of bottom padding, this equates to two baselines as well as the 24px margin on the paragraph elements, leaving three lines between each post. The content and details divs are floated side by side, and their contents styled appropriately in accordance to the Photoshop concept.

The #lower and #footer sections of the design are given new background images to generate the darker footer styling. Font styling for the footer is then reset, making headings a subtle grey colour and links in a more legible white against the dark background.

The four links panels are all floated side by side and given left margin to space them according to the grid gutter. The footer already has padding to take into consideration the first gutter, so the margin on the first div is removed with the :first-child pseudo selector. Panels one and two are set at the width of one column, while panels three and four span across two columns so are given a greater width, as measured from the Photoshop document. The list of links in each panel is styled to match the concept, with type set in Georgia at a doubled line-height.

The credits list items are floated and given the appropriate margin, as well as the sprite background image. Each individual <li> is then given specific background-position settings to display the correct logo. Finally the back to top link is floated over to the right, given the smaller font size and treated with a background image to render the small arrow. A small 3px margin helps tweak the text into place on the grid, ensuring the link is aligned by the text baseline, not the bottom of the icon.

Enhancing with jQuery

The design and webpage is now nearing completion, with the HTML and CSS page matching the Photoshop concept exactly. Next up is the extra Javascript functionality. Three Javascript files are reference in the HTML head, the jQuery library, the jQuery Cookie plugin and my own scripts.js file, which will include all the handwritten code to activate everything.

The first function to be added is the auto-scrolling back to top link. This code states that when the #back-top anchor is clicked, animate the body and html to the position zero. return false; is in place to stop the original anchor from working, so the effect relies only on Javascript.

Next, the “Show/Hide Grid” button functionality is created. First, the button needs making visible after the CSS was set to visibility:hidden; earlier. Then the toggle() function gives commands for when the button is turned on and off, these include adding or removing the class nogrid to the body and changing the text of the anchor.

In order for the effect to work, extra CSS styling needs to be added to actually change how the page looks when the page body has the nogrid class. This is where those alternative background images come into play.

The effect works great, when the user clicks the “Show/Hide Grid” button, the grid is toggled on and off, but once the page is refreshed, or a new page is visited the grid comes back. In order to save the setting the jQuery Cookie plugin needs setting. $.cookie("grid", "hidden"); creates a new cookie named grid with the value of hidden when the button is clicked. A couple of lines of jQuery then check if the cookie is present, and if so the addClass() and .html() functions are repeated. Now whenever the user visits the effect will be in the same state as they left it.

View the LoveGrid demo

View the demo

Older posts are this way If this message doesn't go away, click anywhere on the page to continue loading posts.
Could not load more posts
Maybe Soup is currently being updated? I'll try again automatically in a few seconds...
Just a second, loading more posts...
You've reached the end.
No Soup for you

Don't be the product, buy the product!

YES, I want to SOUP ●UP for ...