sub31's shared items in Google Reader

The 10 principles of interaction design

2011-10-19T10:00:00Z

Chad Vavra, interaction design director at The Barbarian Group, rounds up 10 key rules that make good interaction designs and designers and that you need to understand before you can break them

10 Things I Learned In Web School

2010-06-24T07:00:00Z

Last year Matthew Frederick, author of the excellent book 101 Things I Learned in Architecture School, asked me to contribute some things I've learned about the Web for a new book in his series.

The book, 101 Things I Learned in Business School, was just released but with only one lesson about the Web within its pages. So here are all the lessons I wrote up for Matthew in raw unedited form!

1. You can influence your audience on the Web, but you can’t control them.

In management, you can’t control anyone but yourself. But you can influence everyone.
Companies need to give up the idea of controlling a user’s experience on their Web sites & applications
The completion is one click away and people are quite comfortable using the back button when needed.
Instead of controlling a user experience, focus on influencing people’s behaviors toward value creation and activities that meet their needs and your business goals.

2. Web applications are digital products. Design & think of them as such.

The first wave of the Web consisted of digital representations of physical companies & organizations. So the dominant behavior was locomotion: going from place to place.
In the second wave of the Web, the shopping cart showed up everywhere and enabled digital manipulation of physical goods online.
Now the goods themselves are digital. Web applications are products that companies market and sell.
As such, they should be designed with packaging, first time experience, customer lifecycle, and more in mind.
More on this topic: Audio: Packaging Design for the Web and Packaging Design for Web-based Products

3. Whoever can frame the problem best, is the most likely to solve it.

In today’s digital world, getting clarity into the problems organizations face is sometimes more valuable than coming up with solutions.
There are many more people trying to provide solutions than there are trying to clarify problems.
Usually when a group of smart people is at an impasse for a long time, it is because the problem is poorly framed, not because their solutions are not good.
A well defined-and exciting problem (and its associated constraints) is the catalyst that makes design go.
More on this topic: Defining the Problem Summary

4. There are many ways to move pixels around on a screen. Not all of them are designing.

There’s more than one way to make software user interface decisions.
Designing: decisions are evaluated by how well they contribute to an integrated “human-centric” experience. This is the model most designers crave because it leverages their ability to empathize with their target audience and think holistically. Designing focuses on understanding the fundamental purpose of an application and bringing it to life in a way people can understand and use. An experience that “makes sense” to your audience is your yardstick in this model. This approach is probably most common when developing new products.
Optimizing: decisions are made based on explicit testing of isolated variables to drive very specific behaviors. Designers create variations of a control that are evaluated systematically. The elements that perform best likely become part of the user interface. In this model, performance is your yardstick for decisions. Mature products (especially cash cows) frequently employ optimizing models and designers on these teams spend most of their time creating (lots of) iterations for the key elements of the product.
Managing: decisions are reached through discussion or debate. In this model, designers represent the collective decisions of groups within the product by laying out what everyone agreed to. Consensus and buy-in are the yardsticks by which people judge success.
It’s important to note that the processes that define each model can also be inputs to other models. For example, explicit testing can help inform a holistic design or healthy debate can result in variations to test in order to optimize a product. The thing that distinguishes each model is what is used to make design decisions most of the time: holistic customer experience, optimization, or consensus.
More on this topic: Designing, Optimizing, and Managing

5. What defines a user interface?

Information architecture defines the structure of information (which can exist in many forms).
Interaction design enables people to manipulate and contribute to/create that information.
Visual design communicates these possibilities to people and creates affinity to them (desirability).
A user interface is the summation of these considerations.
Some might argue that the term "information" is a bit limiting in this set of definitions and I kind of agree. So anyone who needs a broader purvey for what they work with could simply substitute "information" with "stuff".

6. Don’t just think about the context of your Web site, think about the context of the Web.

In today’s social, distributed, search-driven Web, customers are finding their way to Web content through an increasing number of distinct experiences.
Yet when people arrive at most Web pages, the experience they get isn’t optimized for this context.
Instead, the vast majority of content pages online remain more concerned with their own context than the context of their users: where did a user arrive from and where are they likely to go next?
More on this topic: Content page design best practices

7. Visual design is not just about making things look pretty

While few people literally ask a design team to make things look pretty, there is a long-standing assumption that visual design is the icing on the cake.
Perhaps this belief stems from the general public’s introduction to design during the industrial age. Back then, products began to be styled in ways that had not been possible before, and industrial designers like Raymond Lowey got immense fanfare for their aesthetic approach to designing previously dull products.
While visual design clearly has the capacity to refine a product’s aesthetics, its potential to communicate with people goes beyond good looks.
Through the visual organization of elements, designers can communicate core messages to people that answer key questions: What is this; How do I use it; Why should I care?
Answering these questions is a crucial component of both utility and usability, especially in interactive products.
So when designing Web pages, it’s important to keep the initial functional role of visual design in mind. The visual design of Web pages should: Set initial expectations by communicating what kind of information it provides; Provide a way to quickly scan that information in order to locate something of value.

8. Organization, interaction, and presentation are the top-level considerations for any Web site or application design.

Organization is the way you structure the stuff that makes up an application. Interaction is the way an application behaves to people's actions - its how you make use of the stuff in an app. Presentation is how all that is communicated to people.
So in this model, it's not hard to see how the presentation layer really needs to become the voice of the interaction design and information architecture of an application. It needs to communicate the possibilities and limitations of software. But visual design also plays another (more visceral) role.
A deliberate selection of colors, fonts, images, patterns, and more can elicit an emotional reaction that enforces a specific brand message. In other words, it can help give an application an appropriate personality - fun, safe, caring, or whatever fits best.

9. Be a smart node

In the craft economy of the 1800s, regional markets were filled with individual or family-based craftspeople like blacksmiths or potters. These professions required creativity, were small size (no scale), and did not need a lot of collaboration to get products made.
In the industrial economy of the 1900s, small craftsmen gave way to large factories and the need for tight command and control grew as scale increased. Lots of coordination was required to develop consistent products within the assembly lines popping up across developed nations. As a result, the need for creativity was limited to fewer people. Most workers had a defined role in the system and needed to be reliable above all else.
In the economy of the 2000s, creativity is once again a key driver of value as command and control structures can no longer manage the full set of information and decisions required to operate at a global scale. This creates a need for “smart nodes” across the enterprise that can collaboratively lead aspects of the business. These leadership positions are enabled through access to large amounts of data and technology. Creativity is required to make use of this information and set of tools to advance the goals of the organization.
The importance of creative thinking and “smart nodes” within large organizations plays to the strengths of designers who are adept at recognizing patterns, synthesizing information, and communicating it through visual means.
More on this topic: Smart Nodes in An Organization

10. Design provides unique value to strategic decision-making

These skills define a unique perspective that designers can bring to strategic work
Pattern Recognition: allows us to identify relationships within information. (the data).
Story Telling: gives us a way to organize data into something meaningful by focusing on a big idea and supporting messages (the synthesis).
Visual Hierarchy: gives us a way to tell the story effectively (the means).
Empathy: allows us to make the story memorable and impactful (the meaning).
More on this topic: Influencing Strategy by Design

Tags: user experience, visual design, decision making, design vision, form|function, strategy

Dave Meslin on designing for intentional exclusion

2011-05-03T09:37:53Z

Here’s a brief excerpt of Dave Meslin’s TEDx talk on The antidote to apathy:

“You ever see one of these before? This is a newspaper ad. It’s a notice of a zoning application change for a new office building so the neighborhood knows what’s happening. As you can see, it’s impossible to read.”

“You need to get halfway down to even find out which address they’re talking about, and then farther down, in tiny 10-point font to find out how to actually get involved. Imagine if the private sector advertised in the same way — if Nike wanted to sell a pair of shoes and put an ad in the paper like that. (Applause) Now that would never happen.”

“You’ll never see an ad like that, because Nike actually wants you to buy their shoes. Whereas the city of Toronto clearly doesn’t want you involved with the planning process, otherwise their ads would look something like this — with all the information basically laid out clearly.

“As long as the city’s putting out notices like this to try to get people engaged, then, of course, people aren’t going to be engaged. But that’s not apathy; that’s intentional exclusion.”

(via Steve Spyrou of Foviance.)

Tech Weekly podcast: Evgeny Morozov on the web as a force for good

2011-01-18T16:05:28Z

Evgeny Morozov, author of The Net Delusion explains how the use of Facebook and Twitter in recent protests in Tunisia and Iran might not have been as effective as first thought

Time-Saving and Educational Resources for Web Designers

2011-01-18T17:48:11Z

Web design community is strong and hard-working. We have plenty of useful resources, tools and services created, developed and released every single day: apart from goodies such as free fonts or icons, there are also many educational resources and little time-savers that can significantly improve designer’s workflow. We permanently look out for the new projects and support them by presenting them on Twitter, Facebook, in our e-mail newsletter and, evidently, in Smashing Magazine’s posts.

Today we are glad to present one of such posts: an overview of handy new resources for web designers; most of them were released recently, but some of them are a bit older. Still, they were included to supplement the overview, making the post more comprehensive and complete. Please feel free to discuss the featured resources in the comments to this post. And, of course, thank you guys for creating and maintaining all these useful resources. Your efforts are deeply appreciated.

Useful Resources for Web Designers

Fonts in Use
This site presents a catalogue for real-world typography samples and innovations in branding, advertising, signage and publishing. The regularly updated collection of trends and case studies is commented on by typography experts and gurus from around the world. The sharp, interesting comments and discussions will keep you engaged, all backed up by real examples.

Note and Point: Keynote and PowerPoint Gallery
Note and Point highlights the most beautiful Keynote, PDF and PowerPoint work on the Web, which happens to be mostly Web design-related, although various topics are covered. No doubt these presentations — which really do look that much better — might surprise you by the attention given to color, illustrations and typography.

Free High-Quality HTML Email Templates
The page presents 38 free HTML email templates (including PSD and HTML files), created by talented professional designers. Every template has been tested in more that 20 popular email clients, including Outlook 2010, Gmail, Lotus Notes, Apple Mail and the iPhone. All of the Photoshop documents are layered and ready to be tweaked. You can download all of the templates for free (320 MB) and use them for any private or commercial project. In case you use Campaign Monitor to send out newsletters, you’ll also get Campaign Monitor’s templates as an extra goodie. Mailchimp users can choose from the professional templates for Mailchimp.

The Grammar Cheat Sheet
Never mix up your dashes again, learn how to set quotations marks and remind yourself to keep paragraphs short and topical. Overall, this article is a nice little overview of suggestions that would help you improve the quailty of your copy. For a closer examination of what else might go wrong, check out “The Trouble With EM ‘n EN (and Other Shady Characters)” by Peter K Sheerin.

FPO: For Print Only
For Print Only is a blog that is dedicated to everything related to pint design. FPO celebrates that print is not dead by showcasing the most compelling printed projects. Print is alive and well as witnessed by this well organized and inspirational resource.

Graphic Atlas: History of Printing
The site is a virtual study collection that showcases printing processes from early woodcuts to modern digital print. The print-identification tool guides you through a number of explorations that replicate the experience of identifying prints using common tools. Among other things, you’ll learn about such printing techniques as relief, letterpress, gravure, silver-dye bleach, dye sublimation and direct thermal. The object explorer allows you to view two images side by side to compare traits across processes. Characteristics such as size, format, color, texture, sheen and layer structure are explained as well.

Smarthistory
Smarthistory.org is a free and open, not-for-profit art history textbook. The website covers a wide variety of the artwork usually found in art history classes, ranging from ancient cultures to post-colonialism. In addition to the audio and video, Smarthistory contains articles and images organized by style and chronology. As a bonus, the user interface itself is worth looking at. The appealing design and intuitive navigation (which allows you to browse by era, style, artist and theme) makes this experience not only educational but enjoyable. A comprehensive overview of the seeds that helped sew the graphic design field.

The Photoshop Etiquette Manifesto for Web Designers
This site lays out a number of guidelines for creating Photoshop files and workflows that are conducive to productivity and team collaboration. By following these guidelines, you make it easier for others to work with your files, and more likely that your project will go smoothly. Some of the things included are common-sense (proofread before exporting), but others aren’t necessarily something you’d think of if you’re not used to collaborating or working on big projects (use folders, keep logos as vector smart objects). It also includes helpful illustrations for each example, so there’s no confusion.

Desks Near Me
This site features places all over the world that designers and developers might like to work in, be they offices or cafés. The website provides detailed information, including hours of operation and reviews. Some places charge a small fee for use, and many throw in a few goodies like food, drink and access to equipment.

Dark Design Patterns
Dark Design Patterns aims to expose these black-hat designs whose sole aim is to misdirect and deceive visitors. Anti-usability design patterns that are currently identified on the website include the “Roach Motel,” “Bait and Switch,” “Privacy Zuckering” and “Forced Information Disclosure,” among others. Examples of each are included, and visitors can add their own in the comments on each page. It’s a great website to show clients when they ask you to implement a questionable “feature” on their website.

The Anatomy of a Perfect Landing Page
Formstack explains how design translates to users and ten key landing page features that draw them in. A useful breakdown of elements to include in your designs and things to keep in mind during your design-work.

100 Principles for Designing Logos and Building Brands
Inspiration can come from anywhere, but sometimes the simpler the better. From Brand Identity Essentials, here are some principals for designing logos and building brands. These cover example shapes, consistency, voice, meaning and flexibility.

Design Is History
A wonderful reference site for all designers and provides brief overviews of a wide range of topics — for us, designers, it is improtant to understand where design originates from.

NounProject
NounProject provides a huge collection of highly recognizable symbols, available for free download and use. The designers are committed to quality in what they do, and so the icons are indeed designed very well.

Ethics for Web Designers
Robot Regime is dedicated to ethics and Web design, and it discusses what our ethical obligations are — to ourselves, our colleagues and our clients. The site already features some nice pieces, including posts about fair pricing, misrepresenting yourself as a designer and giving clients what they want.

Politely Decline Speculative Work
“I won’t do free design work to win your business — here’s why” is a Web page that offers a stock letter you can send to clients explaining why spec work is bad for everyone involved. It’s concise and professional, and it presents clear arguments against spec work, with links to additional information. Plus, you can personalize the letter by adding the recipient’s name to the end of the URL.

Type Tips
A nice short overview of quick useful tips on all things related to Web typography by Harry Roberts from CSS Wizardry.

OnTwik
The website brings together lectures, screencasts and conferences from around the world. Both expert and novice developers and designers should be able to find topics of interest, whether it’s CSS and HTML5 or start-ups and creativity. Ontwik is free, and anyone can suggest content for the website; you can even submit your own lectures.

Design Moo
“Join together and share valuable free Web design resources.” This could be the slogan of this design community, created and curated by front-end developer Chris Wallace. The project is a network of designers and a high-quality collection of free design resources: fonts, icons, illustrations, patterns, textures and Web layouts. All goodies are tagged for easy navigation, and you can follow new releases on Twitter. You might want to check Boxtuffs and Premium Pixels as well, another websites featuring free high-quality resources.

Design Kindle: Free High-Quality Design Files
This site offers a ton of free high-quality design files that you might actually want to use, all without restrictions on personal or commercial use. Everything from design elements to images to full themes is included. Design Kindle doesn’t have a big library of files just yet, but more are sure to be added soon.

365psd: A Free PSD Every Day
Every day, this site offers a free PSD file for you to download. These files are almost all design elements that you can use in Web and application designs, including buttons, progress bars, navigation elements and more, and they are well designed. Currently, there are more than 300 days worth of freebies, all tagged, browsable and searchable.

Guidelines for Mobile Web App Design
This article presents a comprehensive list of links to official user interface and user experience guidelines from various manufacturers. The guidelines include samples, tips and descriptions of common weaknesses for mobile platforms such as iPhone, iPad, Android, BlackBerry, Symbian, webOS and Mee Go. Many of the guidelines focus on native application development, but they can be applied to design of mobile applications in general, too.

List of Freely Available Programming Books
Here is a list of programming books on programming languages or about computers in general with open-source licenses and others. If you’ve been searching for some freely available programming books on the Internet, this list will surely give you some good tips.

Secure Password Generator
The tool lets you enter parameters, including the length of the password, whether to include uppercase and/or lowercase letters or numbers or punctuation and whether to eliminate characters that resemble each other (such as i and l, 1 and I, and o and 0). Then, just select the number of passwords to generate, and it returns a list. It even includes phonetics for each password to make it easier to read out loud (in case you’re giving a password to someone over the phone, for example).

Keyonary
This tool is a nice little application for finding shortcuts in Mac OS X, Photoshop and so on. Currently, more than 300 Photoshop shortcuts are available. Simply type the name of application in the search box, and it spits out a long shortcut list.

Let’s Swap
A place where artists and designers can swap art for free. The site is an experiment: if you are an artist or designer, you probably have something hanging around and you’ll be willing to swap it for something else. The site gives you the opportunity to do exactly that; just put out an open invitation and see what happens. Very interesting idea.

Starting with Git: Cheat Sheet
After freshening up her git skills, Loma Jane Mitchell shares her ‘cheat sheet’ — the commands that she uses on a day-to-day basis when working with git. Also note that GUI tools and IDE plugins are available for Git, so it is worth taking a look at what is available for the development environment you use.

Rails 3 Cheat Sheets
The site provides Rails 3 Cheat Sheets for Activemodel, Actionmailer and Actioncontroller, XSS protection and UJS, Activerelation, Bundler and Routing API.

Bounce Rate Demystified
If you are doing business on the web and have Google Analytics set up for your website, it’s very likely that you know the bounce rate for your website. But, do you know anything about how it’s calculated, what your industry’s average bounce rate is or even what factors affect your bounce rate? Inspired by common questions, KissMetrics created this infographic to give you answers and some tips to help you improve your bounce rate.

InspireUX
User Experience quotes and articles to inspire and connect the UX community.

Quotes on Design
A growing collection of useful quotes by designers for designers and developers.

IA TV
Information Architecture Television features a collection of videos from around the Web that all focus on information architecture. Hundreds of videos dating back to 2008 offer a great wealth of information on everything from design thinking to usability.

The Bazaar
On this site you can create galleries, upload your artworks and specify your products which you would like to sell. Once the buyer has checked out and has made the payment, your artwork is printed, wrapped and delivered.

A Collection of Materials Related to Interaction Design
This IxD library provides you with an ultimate collection of posts, articles, PDFs as well as videos related to interaction design for you to read and gain more knowledge and inspiration.

Pinterest — Catalog the Things You Love
Pinterest is a social catalog service. Think of it as a virtual pinboard — a place where you can post collections of things you love, and “follow” collections created by people with great taste.

WordPress Snippets
WP-Snippets can come in handy when you’re designing a WordPress theme. Rather than start from scratch when building some functionality or another, why not grab a snippet of code that has already been tested? The website includes many useful snippets, from highlighting author comments to listing random posts to filtering the loop. Make sure to read the comments for each snippet because they could contain helpful information on whether the code works in certain WordPress versions.

CSS Terms and Definitions
This article discusses the consistency in the use of terms with reagrds to CSS.

CSS Vocabulary
“I realized quite late that to say something meaningful about CSS, I would have to know exactly what the terms used means. Often, I have asked for help in forums, and have got stuck wondering how exactly to describe my problem. So I thought it would be a good idea to describe all the common terms of CSS.” A nice overview of common CSS terms and definitions and a good addition to the article “CSS Terms and Definitions” described above..

Bagcheck
BagCheck lets you share your personal collections and also lets you browse through other ‘bags’ to find out common hobbies or activities that helps you connect with people and their interests.

ManyBooks: Repository of Free E-Books
This site offers a huge collection of public domain e-books, as well as other newer books that have been released in the public domain or under Creative Commons licenses, in a variety of formats. You can download classics such as Pride and Prejudice, as well as newer books such as The Gospel of the Knife, in formats such as ePub, Mobi, PDB and even PDF and plain text. Books are also browsable by genre, author and title. And of course, there is a search function.

Last Click

Should I Work for Free?
Who’s ready to stop working for free? Hopefully you are! If you have any doubts, consult this handy chart below. Start in the middle and work your way to your answer.

Email Etiquette for the Super-Busy
In a recent blog post, venture capitalist Fred Wilson talked about his ongoing struggle with email management and the various solutions he’s tried, concluding: “Every time I make a productivity gain, the volume eventually overwhelms me.” It’s a familiar problem. We’re all extremely busy, and we all get too much email. So what to do?

The Future of Advertising
An article on advertising; stating that advertising is on the cusp of its first creative revolution since the 1960s brings us to a new prespective. This involves the ad industry that just might get left behind. Click here to read and find out more. Very interesting read.

Why Your Form Buttons Should Never Say ‘Submit’
When you see a ‘Submit’-button on a form, what comes to your mind? One could easily reason that clicking the button submits the user’s information into the system for processing. A ‘Submit’-button describes what the system does well, but it doesn’t describe what the user does at all. The article suggests to stop using the wording ‘Submit’ on buttons and provide more meaningful, task-specific names instead.

Cleaning Up The Mess: How To Keep Your Coding Workflow Organized

2011-01-20T00:09:29Z

Oops, we used the word “organized” in the title. Time to switch off — is probably what many would think. Being organized is a somewhat dull, though important, subject. Perhaps it would help to give it a bit of context.

Let’s keep it classy, and imagine we’re building a website for a trendy restaurant / café called “bEat”, catering to the arts community. It’s an atmospheric place with 1920′s art on its interior brick walls, live jazz, and rich patrons. But they don’t have a great website, so they’ve called you in to save the day. As a talented designer, you’re confident you’ll be able to pull a fantastic design together that they’ll love, but they’ve got a lot of clever ideas about the website’s functionality, and you’re not quite so confident about how to organize all the files that your website will need.

They need to be able to edit content themselves, upload pictures for their weekly blog posts and new content. Pretty normal so far. They also need to hook in with Twitter, so their blog posts are automatically tweeted. They need a mobile app for iPhone and Android, because their customers are using a smartphone, and they want to offer specials & menus direct to their smartphones. Down the track, they’d like to have reviews submitted by their customers, with possible pictures, links, etc. Lots of cool interactive social networky stuff, friends, online user-submitted video.

‘Facebook for restaurants’ they say, by way of making it easier for you to get your head around. Ok, by that stage, you’d probably tell them to go waste someone else’s time. But you get the idea.

Perhaps in the past you’ve tried to build a more complex, cutting-edge website like this, and the project started off with great enthusiasm, but ended up in a nightmarish mess that you couldn’t maintain. Your client lost interest when new features started getting too hard to add, and you started having to work late at night, tracking down bugs that you couldn’t even find the relevant file for.

After a project like that, it’s not hard to see the relevance of a well-organized website project.

General Principles

Structure is the essence to the project. Image by Chris Halderman

Keep everything simple and clear. Don’t over-organize — some websites & frameworks out there seem to have a masochistic need to make everything a theoretically perfect abstraction. In practical terms, that usually means it’s impossible to work with.

If you start creating tens (or hundreds) of tiny files, each containing nothing more than a small class or function, you’re definitely overdoing it. If your files and folders have names that are too abstract or generic, then things are probably starting to get a bit silly. For example, if the code to check the login for a website administrator is stored in a file called WebsiteData/Items/GenericUser/AdminUser/Code/Auth.php then you’ve committed both sins. Why not just a function called check_login() in the file code/users.php?

Don’t mix different aspects of your website. Keep modules of functionality separate, and keep different languages in separate files. I’ve recently helped out on a project where some poor, misguided programmer mixed CSS, ASP VB Script, JavaScript, HTML and SQL in a big jumble, all throughout a single, huge, poorly indented file. I’m not exaggerating. Enough said.

One Size Does Not Fit All

Reflection prior to starting helps. Image by Andy Mangold

The depth of your folder hierarchy and the number of individual files should make sense for the size of the website. Keep it in perspective.

Here’s a quick list of some typical approximate website sizes, and how you might structure things accordingly.

1 page website
Make a folder for images, a single file for CSS, another for JavaScript, another for content, and another single file for code. It’s definitely not worth separating template and content, unless you have specific requirements.
5 pages website
A folder for images, one file for CSS, JS, code. Consider putting your content files in a separate folder. Again, not much need for templates here, usually. By this stage, make sure you have a template for the header and footer of your page (and any other common elements on all the pages).
20 pages website
A folder for images, another folder for uploads and other business-related files (“assets”), another folder for content (or you might be using a database-based CMS by this stage). Your JavaScript, code, and stylesheets are probably getting complex enough by this stage to consider putting them in a separate folder. Name the folders something immediately obvious, e.g. css/, javascript/, code/.
Make sure that all files go into their relevant folders. You shouldn’t have a stray .js file sitting, say, in the content/ folder, just because it’s convenient. If your templates or code don’t allow you to organize your files the way you need to, then do a quick code refactoring to make it work.
Avoid putting CSS, templates, layout and design images, or JavaScript into assets/ (or uploads/ or resources/, depending on what you call it). These files are effectively code that your client should never have to think about, and the assets/ folder is for business-related files and media. Make it a golden rule for your workflow and stick to it.
20 pages web application
Much as above, but by this stage you should definitely be putting all your code in a separate folder. Make sure it’s not inside a folder where Apache might accidentally serve up the plain files when some script-kiddie has a tinker.
100 pages website
You should be using a good CMS for your content by this stage. It doesn’t matter if it’s a database- or file-based CMS, but if it’s the latter, make sure the content files are well-organized, and make sure you can define metadata for individual page titles, descriptions, etc, or your SEO efforts will be very difficult.
You’re probably also starting to have a number of different sections on your website by now. You’ll likely need to start factoring out the stylesheets, JavaScript, design images and templates into separate files and folders. Make sure these folders match each other, and match up with the sections of your website — or whatever makes most sense for your particular website. Using a CSS language like Sass or LESS is also a really good idea by this stage.
2,500+ pages website
You should definitely think about hiring some people dedicated to certain aspects of the website, such as a content editor, designer, programmer and SEO expert. You’ll also want your content to be in a database-based CMS by this stage, if it’s not already. You’ll start being the manager, and having the bulk of the work done by other people. Make sure you have smooth-running systems in place to allow you to review their work, and edit it before it goes live.
100,000,000+ pages website
You’re Microsoft. You should know what you’re doing by now.

Most small websites very quickly grow to over 20 pages, if they’re being actively maintained — by the time you’ve added a couple FAQ pages, a few little tidbits of content to explain something in more depth, and a product or two, it adds up quickly.

In that light, consider making all your small websites structured like an (approximately) 20-page website, unless you know the project is a quick, one-off website, such as an information site for an upcoming event, or a page for your wife’s birthday. Plan for growth, but don’t plan for a hockey-stick growth curve.

Your Client

Communication with the client helps clear things up. Image by Andy Mangold

You should have a folder for each customer, unrelated to the actual project you’re working on for them. Inside this folder, you’ll have a folder for each project. Initially, there’ll just be a folder called website/, but before long, you might have other folders called logo/, reports/, competitive analysis/, etc. It also makes sense to put your design files in this folder, perhaps in design/ or graphics/.

Don’t make this folder accessible by Apache. It will contain sensitive information.

Depending on the framework you use, you might like to put the code in this folder, to keep it outside of your website folder. You could call it code/, or, if you think there’ll be separate code for other projects, website-code/. If most of your other projects are design or business-related, then they probably won’t have any code, other than the odd script which wouldn’t need a separate folder.

In addition to the customer’s work folder, you might like to have a completely separate folder for documents that you don’t want your customer to see. You might find yourself regularly sharing work-related documents with your customer, and it’s quite likely that at some point you’ll want to give them access to their whole folder (and some customers will ask for it: “Can you zip up all my files and send them through? I just want to make sure I have a copy of everything”). Rather than risk accidentally sending them the file “10 things I hate about these guys.doc”, put it in your customer’s private folder.

To recap quickly, here’s an example of structure we’re currently looking at:

YourBusiness/
  Accounts/
  Documents/
  Customers/
    bEat/
      Minutes/
      10 things I hate about these guys.doc
      Proposal.doc
    CustomerProjects/
      bEat/
        website/
            ... this is the bit we'll be discussing ....
        code/
            ... and this ...
        reports/
        graphics/

So, What’s In A Website Like This?

From here on in, we’re talking about the “code/” and “website/” folders listed above.

Images

There are (almost always) two sorts of images: those that are part of the design, and those that are part of the content provided on the website. The latter should go into your assets (or uploads or media) folder, perhaps in a pictures/ subdirectory. For design images, you’ll rarely need to stray from the beaten path: put them all inside images/.

If your design is a little more complex, you might have images for buttons, icons, navigation, page background, etc. In that case, you’ll quickly get above 10 or 20 images in this folder, so consider breaking it up into subfolders. It’s still fine to have general-purpose images in the top-level, but the subfolders will help to keep control of all your zillions of little files. Name the files sensible, easy-to-remember names like form-warning-icon.png.

Stylesheets

For most sites, your stylesheets don’t need to get very large. For a small site, or even a larger site, without many different sections (each with a different design), you’ll often get away with only one file for your CSS. If this is the case, just name it main.css, or styles.css.

Even so, a lot of people like to break their stylesheets up into multiple files. There are different ways to do this. A popular option is one stylesheet for layout, another for typography, another for colors. This is a nice idea, but it gets tricky to manage in practice — you end up defining many of your classes 3 (or more) times, and tracking down bugs can be a nightmare.

I believe a better option is to separate out “layout” and “content” styles. “Layout” includes things like navigation, header & footer, sidebars, boxes, sections. “Content” includes things like paragraphs, headings, blockquotes, lists, floating images, links. If you carry this a bit further, it also makes sense to have a file for “forms” styles. However, as content on the web becomes much more interactive, the line between forms and content (no pun intended!) is quickly being blurred.

Again, call a spade a spade, and name these files layout.css, content.css and forms.css. If you give them somewhat vague names like presentation.css, model.css, page.css, you’ll always have to think first before deciding what file to look in.

Sometimes it’s useful to have an individual CSS file for special pages that have their own design requirements. This can be more trouble than it’s worth, depending on the complexity of the page. If you find yourself flicking between tabs in your editor, trying to find the right CSS file for a particular element, then it might be better to simplify your CSS. Also, seriously consider using Sass or LESS to make your CSS much more beautiful and clean.

You probably also will have separate stylesheets for different media, and these absolutely need to go in separate files. As usual, name them something sensible, like print.css.

If you have multiple CSS files, that’s great, but make sure you use an automated tool to merge them all into one file before serving them up, or your website’s download speed will suffer. Don’t merge your beautifully factored CSS by hand. That’s using a Mechanical Turk for a job that computers do easily. You could use Minify (PHP) or Juicer (Ruby) for that.

JavaScript

Image source: dmitry-baranovskiy on Flickr

There’s a lot in common between organizing the JavaScript and CSS files for many websites. They both serve similar (but different) purposes, they’re both served up to the browser to interpret, they both interact with the DOM (when used appropriately), they often interact with each other. JavaScript is often used to add functionality to exactly the same set of elements that the CSS is used to style.

You’ll usually end up having your JavaScript library file (jquery.js, mootools.js etc.), a couple of widgets (say datepicker.js and dropdown.js), and some site-specific code (eg my-image-slider.js). It definitely makes sense to keep these in separate files, although you’ll often have so little site-specific JavaScript that it makes sense to just have one file for that part of it.

Put all these files into a folder named javascript/. Assuming you use a 3rd-party library like jQuery, you’ll very rarely build a site complex enough to sub-divide this folder any further.

Templates

Your templates are just skeletal outlines for your code to flesh out with content, and for your stylesheets to paint with beauty. Image source: dorena-wm on Flickr

Templates are not content, are not code, and are not presentation. Templates can have certain aspects of all those things, but only the barest hint, when used properly. It might help to think of your templates as skeletons. Your server-side code fleshes out these templates with content (content from the database, error messages, form-field values, etc), and the browser applies an aesthetic skin to acheive the end result.

Of course, your templates might have the odd piece of human-readable text, for a button, dropdown, or whatever. That’s fine — that sort of text tends to be closely associated with the function of the page, rather than the content.

Put the templates in a templates/ folder. In spite of what I said above, templates are really server-side code (they’re sensitive), so make sure they’re not publicly accessible.

If your website sends out emails, then have a couple of subfolders in this folder for plain-text and HTML email templates. If your website is more than just a brochure website, you’ll need many templates, for the different pages and screens of your application. If you have a smartphone version of your site, have a subfolder for it. Structure these subfolders appropriately. Here’s a good example:

templates/
    blog/
        sidebar.tpl
        post.tpl
        comment.tpl
    emails-plaintext/
        subscribe.tpl
        change-password.tpl
    emails-html/
        subscribe.tpl
        change-password.tpl
    social/
        twitter-feed.tpl
        facebook-sidebar.tpl
    mobile/
        base.tpl
        contact.tpl
        customer-profile.tpl
        friend.tpl
        homepage.tpl
        reviews.tpl
    base.tpl
    contact.tpl
    customer-profile.tpl
    friend.tpl
    homepage.tpl
    reviews.tpl

Assets

This is a name I really don’t like, though the alternatives aren’t necessarily much better. This is the folder where you put all the audio, video, documents, pictures, and anything other non-textual (or non-HTML), usually business-specific, content, which you want to be publicly available on your website.

Some alternatives for names are uploads/, resources/, files/, media/. Or you could break it up into separate main folders, called pictures/, audio/ etc — but that gets messy pretty quickly. However, it is often good to have sub-folders for different types of file.

I tend to use resources/, personally, but it’s a bit abstract. Not a very good name, though better than assets/ (what are we, accountants?). However, assets/ is almost an industry standard, and if I were to start fresh, that’s probably what I’d use. So for the sake of this article, lets go with that.

If this is just a small business website without massive content management concerns, then the security of these documents isn’t a concern. If it is, then you should have those sensitive documents in a completely different folder.

If you have a larger-scale website with needs for permissions-based access to different available content, then you should use a document management system of some sort.

In light of that, it’s perfectly safe to make this folder publicly accessible from your website. Your client should be able to upload items to this folder themselves, and link to the items via the CMS.

If you don’t have many non-web documents, then there’s no point in sub-dividing this folder any further. However, if you have a lot of these files, it makes sense to have subfolders with names like photos/, pdfs/, videos/ etc.

The Database

This article isn’t really about database design, so we won’t deal with this much here. But it is important to keep your database well-structured. You’d do well to use an ORM in almost every situation — very few websites have unusual enough data requirements to need anything an ORM can’t acheive. Any good ORM can acheive virtually anything the underlying database can, anyway.

SQLite is a great option for most websites, because it’s easy to deploy, exists as a simple file on your file system (but is a full-featured relational database), and it’s simple to backup (no fancy import/export, unless you want to — just use a standard file backup solution. Of course you already have one, right?)

Name your database the same as you’ve named your project folder. Don’t have a separate database for each aspect of your website, but do have a separate database for each website you develop. As always, keep it simple, use short, full words as names, and don’t clutter things up with all sorts of extra prefixes and suffixes.

The Content Management System

These babies generally take care of organizing themselves. But do use a CMS that’s decently structured and well-coded. If you use a file-based CMS, put all of its content in a subdirectory, say content/.

The Administration Section

Almost everyone puts the administrative files under admin/, when it’s needed. If you have an admin section, do the same. Don’t have duplicate code, images, JavaScript, etc. for the admin. Obviously, for the parts of the admin section that are different, you’ll need to have additional code etc. But it should be part of the same codebase, and factored such that you can use the helper functions from any part of the website.

Food for thought: you may not need an admin section at all. For example, if your client needs to upload and edit photos, why not provide an “edit” link right there next to the photo? Similarly for posts, comments, etc. Of course, be sure that you still have robust authorization and authentication.

The Code

Whew. Where do I start? Software development is a complete field of knowledge in itself, and software is among the hardest things in the known universe to keep organized. I won’t even begin to cover all the ground here.

However, the rules stay the same: don’t hide files deep inside a hierarchy if possible, name your files using short, concrete nouns. Do use subfolders when necessary — but for most websites you shouldn’t have that much code. Stay on top of it. Make sure you use the same names for the same things — if you’ve called the database table users, don’t name the relevant file members.php. Name it users.php.

Good factorization is by far the most important aspect of keeping software organized, and it covers all levels of your code — from the folders right down to the names you choose for your variables. It’s is the single biggest deciding factor that separates competent programmers from the inexperienced ones. Go learn all about it.

Some things to keep in their own separate files and folders:

Your data model. If you have a lot of logic attached to each type of object, you’ll probably want to have a separate file for each major class.
Your “views” (as Django calls them). These are “controllers” in MVC language. Briefly, a “view” is any code specific to a particular URL.
General-purpose classes and functions.
Your library code. This should probably not even be inside your project or client’s folder — you should have a system-wide collection of library code you use, so you don’t have to manage multiple copies of the same thing.
3rd-party libary code.

Use a version control system, such as SubVersion. To learn about version control, take the time to read the guide to version control for web designers.

The files here will often have corresponding files in your templates folder, although there won’t always be a one-to-one match. Where there is, though, use the same name for both files.

Keep your code well outside of any publicly-accessible folders. Do you really want everyone finding all the inevitable security holes in your code? Don’t mix HTML, CSS, or Javascript in with your server-side code, or vice-versa.

The Final Folder Layout

Of course, you should consider the given situation to determine what’s best for the project. The example below is by no means complete, and exists solely to give you an idea of what we’ve discussed.

    bEat/
        website/
            images/
                boxes/ /* often still necessary for IE... */
                    red-bottom-left.png
                    red-bottom-right.png
                    red-top-left.png
                    red-top-right.png
                navigation/
                    navigation-sprite.png
                    background.png
                logo.png
                page-background.png
                twirly-list-dot.png
            css/
                layout.css
                content.css
                print.css
                mobile.css
            javascript/
                jquery.js
                datepicker.js
                site.js
            assets/
                pictures/
                videos/
                pdfs/
            templates/
                blog/
                emails-plaintext/
                emails-html/
                social/
                mobile/
                *.tpl
            content/
        code/
            *.php
        reports/
        graphics/

The same, in a shorter form:

    bEat/
        website/
            images/
            css/
            javascript/
            assets/
            templates/
            content/
        code/

Admittedly, it looks pretty basic, when you reduce it to that. But the fallout from getting it wrong can cost a lot of time and effort. You can download the sample project folder template (.zip), a skeletal PHP website, with a single content page, based upon the H2O template library.

Perhaps you like the following alternative better. It has the advantage of keeping everything for a single project inside a single project, at the cost of putting all the static files one level deeper. If you spend a lot of time working with CSS and JavaScript, that may be not so useful for you, but it’s a question of what’s important for your project and for your business.

    bEat/
        website/
            static/         /* name it "public/" if you prefer */
                images/
                css/
                javascript/
                assets/
                content/
            templates/
            code/

Quick Recap

Keep it tidy. Don’t drive everyone insane with your need to have a perfect folder layout, but avoid putting files in convenient but incorrect locations.
Use sensible filenames. Concrete words that bring up a (relevant) picture in your mind’s eye are best. Where possible, use single words to name your files, but not at all costs.
Often (but by no means always) when you need to use two words to name a file uniquely, it’s a sign that you should make a subfolder. Instead of images/navigation-*.png, you might be better off with images/navigation/*.png.
Avoid cluttering your filenames up with all sorts of extra prefixes and suffixes.
Managing your own time effectively will help you find time to organize your website files — remember, quadrant 2!

Of course, we’re not perfect, and the suggestions here are definitely not the only (or best) way to do things. How do you organize your own website files? Let us know in the comments!

(vf)

Tagging Human Knowledge

2011-01-11T10:42:20Z

"A fundamental premise of tagging systems is that regular users can organize large collections for browsing and other tasks using uncontrolled vocabularies. Until now, that premise has remained relatively unexamined. Using library data, we test the tagging approach to organizing a collection. We find that tagging systems have three major large scale organizational features: consistency, quality, and completeness. In addition to testing these features, we present results suggesting that users produce tags similar to the topics designed by experts, that paid tagging can effectively supplement tags in a tagging system, and that information integration may be possible across tagging systems." (Paul Heymann ~ Videolectures.net WSDM 2010)

From Wireframes to Code (1/2)

2010-12-20T09:54:38Z

"Within many companies, the use of wireframes in user experience design can be a contentious issue. People typically think of wireframes simply as artifacts designers create when generating design concepts, then later discard. Why not create a design artifact that is not disposable, but instead, one your team can convert to actual production code? Is this Holy Grail of the design process a good idea? Is it even possible? Or does the answer depend on the project, the team, and its agility? This first part in a two-part series takes an in-depth look at the process of converting wireframes to code." (Bill Schmidt ~ UXmatters)

The Essence of Interaction Design—Part I: Designing Virtual Contexts for Interaction

2011-01-05T12:26:10Z

By Pabini Gabriel-Petit Published: January 5, 2011 “Interaction design is absolutely central to the design of application user experiences —whether for the desktop, Web, mobile devices, or other handheld devices….” I’ve referred to the work I do as user experience design ever since Don Norman introduced the term at Apple in 1993—when I was a Human Interface Engineer there. But interaction design is absolutely central to the design of application user experiences—whether for the desktop, Web, mobile devices, or other handheld devices—and it is the core skill of application designers. With this column, I’m introducing a multipart series on what I consider to be the essence of interaction design for application user experiences. First, I’ll lay the groundwork for this series by describing the role of interaction design, then I’ll embark on my exploration of the essence of interaction design by discussing the design of virtual contexts for interaction. As I began thinking about this series, I realized I should describe the process of design first—or I’d end up constantly revisiting the same process issues—so I wrote my column “Design Is a Process, Not a Methodology.” Throughout this series, I’ll refer you to that column for details about steps of the design process that are especially important in solving particular types of design problems.

Power or Collaboration—What’s Most Valuable to a UX Leader?

2011-01-05T12:23:37Z

By Jim Nieters Published: January 5, 2011 “Designers increasingly have the opportunity to facilitate strategy dialogues among stakeholders within our companies and, ultimately, to align product teams around a powerful design-led vision.” In October 2010, I was fortunate to participate in a panel discussion at the Mobile HCI conference in Lisbon Portugal titled “Guru’s Views,” [1] with moderator Bruno von Niman, who is a long-time UX visionary in the mobile space. In my opening statement, I pointed out that designers increasingly have the opportunity to facilitate strategy dialogues among stakeholders within our companies and, ultimately, to align product teams around a powerful design-led vision. In response, Josh Ulm of Vodafone pointed out that trying to gain support for design efforts through collaboration was no longer worth his time. If his design team did not have the sponsorship and support of senior leaders, including the CEO, it just took too much effort to make progress, so he would rather find a company where he could more easily make a difference. In this column, we’ll explore these very questions: Do UX leaders need to acquire and wield power to ensure their organizations can produce game-changing design? If they don’t already have executive support, can they can collaborate their way to success?

The Future of User Interaction

2011-01-05T11:59:06Z

By Demetrius Madrigal and Bryan McClain Published: January 5, 2011 “We must keep in mind the new technologies that are currently under development and could influence the fundamental ways in which people interact with the products we design and develop.” We think it’s appropriate to kick off the new year with an examination of what the future holds for user experience and product development. To stay ahead of the curve when it comes to user research and UX design, we must keep in mind the new technologies that are currently under development and could influence the fundamental ways in which people interact with the products we design and develop. We’ve seen the advent of such disruptive technologies repeatedly throughout time, including automobiles, telecommunications—radio, telephones, and television—and the personal computer. In this column, we’ll describe several new technologies that have the potential to change how we interact with technology and the world. Some of these technologies may be many years away from maturity, but they are definitely going to have massive impact in years to come.

Essential and Desirable Skills for a UX Designer

2010-12-20T09:21:01Z

By Janet M. SixPublished: December 20, 2010 Send your questions to Ask UXmatters and get answers from some of the top professionals in UX. In this edition of Ask UXmatters, our experts discuss what skills are essential and desirable for a UX Designer. Each month in Ask UXmatters, our panel of UX experts answers our readers’ questions about a broad range of user experience matters. To get answers to your own questions about UX strategy, design, user research, or any other topic of interest to UX professionals in an upcoming edition of Ask UXmatters, please send your question to us at: ask.uxmatters@uxmatters.com.

An interview with Bill Verplank

2010-12-15T20:00:47Z

Back in the late 1980s, Bill Verplank, when working at what would become IDEO, stopped calling what he did ‘user-interface design’, and instead coined a new term: ‘interaction design’. His work over the years has included Xerox Parc, IDTwo/IDEO, and collaborations with design schools such as the RCA, MIT and Carnegie Mellon. Steve Baty talked with him about interaction design.

You’ve been working as an interaction designer for three decades: how has your approach to your work changed over that time?

Bill Verplank

After my PhD from MIT in “Man-Machine Systems”, I went to Xerox and spent three years testing systems that had taken ten years to invent; then after the Xerox Star was introduced, we spent five years refining and extending it. So in my first decade, I did “human factors” testing and “user interface design”. This is also the decade that ACM started SIGCHI and I started teaching “graphical user-interface design”. (‘70s ‘80s)

In the next decade, I was hired by Bill Moggridge at IDTwo to move the insights from computers to products of all sorts. We called what we did “Interaction Design” and saw what we were doing as the key to modernizing “Industrial Design”. As consultants, we were dependent on clients, so for me it was a scramble to keep up with the variety of problems. When IDTwo merged with David Kelly Design and Matrix to become IDEO, we had established a new kind of multi-disciplinary design consultancy. (‘80s ‘90s)

In the third decade I have returned to invention and teaching. At Interval Research, we enjoyed the freedom to develop technologies (e.g. haptics) and methods (e.g. “body storming”). Also, we encouraged educational programs at RCA, MIT, NYU, Stanford and finally at the Interaction Design Institute Ivrea (IDII). My favorite post-graduate program now is a spin-off of IDII: the Copenhagen Institute of Interaction Design (CIID). Also, at Stanford, I have been teaching Computer Science and Computer Music with a focus on the tangible aspects of interaction. (‘90s ‘00s)

Over that same period, how has the practice of interaction design changed generally?

What do we think a “computer” is? I like to contrast three dominant metaphors or paradigms: PERSON, TOOL, MEDIA.

In the ‘50s, we called computers “electronic brains” and many were motivated to make them intelligent, language processors. There are still people pursuing these “anthropomorphisms”; they call it “artificial intelligence” or “robotics”. Interaction is a verbal dialog. A computer is an “agent” or “assistant” – autonomous and intelligent. Think of the computer as a “PERSON”.

In the ‘70s, rather than replicating or replacing people, Englebart proposed “augmenting intelligence” – thinking of the computer as a “TOOL” which extends and empowers us. We became “users” not just programmers or operators. Anyone who asks “Who is the user?” and “What is the task?” is very much in the business of “interaction design”. Good interaction is useful and efficient.

In the ‘90s, with ubiquitous networks, mobile, graphical and dynamic interfaces, computers are “MEDIA”. Televisions, phones, games are all computers that we watch, connect, play and mostly enjoy. A good interaction is engaging, immersive and persuasive.

PERSON, TOOL and MEDIA are sufficiently established as metaphors, we can call them paradigms; they define our business, schools and conferences. What will the next paradigms be? What will we call what we do?

Here’s a sketch I did in 2000 on Metaphors for Computers: PERSON, TOOL, MEDIA – each one a robust “paradigm”. Beyond those three, I predict LIFE, VEHICLE, FASHION.

Bill Moggridge's Metaphors for Computers diagram

In your “Interaction Design Sketchbook” you write: Interaction design is a profession that will mature in the 21st century. Where do you think interaction design is currently immature, or is this more a reference to the emergence of embedded and ubiquitous computers? Implicit in that section of the IxD Sketchbook is the idea that interaction design concerns itself with computers and computer-driven interactions. Do you see a place for the practice of interaction design in non-computing environments such as services?

Interaction Design in the 21st century will be a challenge because almost everything (and everybody) we interact with will have computers in it or on it. Services and systems will be autonomous and only ask for guidance (think of automated cars and guideways); tools will be augmented and powerful; even the most mundane artifact might have far-flung connections and consequences; media will be interactive and engaging and we will all become fashion designers.

We’ve recently seen the principles of interaction design applied to situations where the aim is to shift individual or group behavior in social, economic or environmental activities. Do you see this a logical extension of the work you were doing in the 80s and 90s or a shift away from interaction design’s foundations?

Interaction Design as I practiced it, is very much in the “TOOL” paradigm; the principles were “consistent conceptual models, direct manipulation and WYSIWYG”. If the “aim is to shift individual or group behavior” then use the “MEDIA” paradigm. Advertising, education, persuasion, are at the core of ancient practices. Making media more interactive may or may not get your message across. Media can mystify and intrigue. All I know about media is that “the medium is the message” – a technocrat’s rant.

You’ll be speaking to nearly 600 interaction designers in February at the Interaction conference in Boulder. What is the one thing you’d like them to take away from your lecture?

I would like them to take away my enthusiasm for metaphors and engage in the search for metaphors that help us organize the various paradigms of professional practice.

What will the next metaphor be in your practice? Is your design motivated and organized as a form of LIFE? Or as infrastructure or VEHICLE? Or as the latest FASHION?

Verplank's professional practice metaphor simplified for Designing Interactions

Interaction 11

Bill Verplank is one of the keynotes at Interaction 11 . It has sold out, but workshop places are still available. It is the fourth annual conference hosted by the Interaction Design Association (IxDA). Each year, IxDA aims to gather the interaction design community to connect, educate, and inspire each other. This year it is held in Boulder, Colorado (USA).

——-

Picture of Verplank: Mayonissen with CC

UX at Year X: An interview with Jesse James Garrett Jesse James Garrett about service design, UX rock stars and...
Interview with iA’s Oliver Reichenstein Recently I got a chance to interview none other...

Related posts brought to you by Yet Another Related Posts Plugin.

Design Research and Innovation: An Interview with Don Norman

2011-01-11T13:22:45Z

Last week I got the chance to interview one of my heroes: Don Norman. This May he will be one of the keynote speakers at UX Lisbon in Portugal. I spoke to him about innovation, design research, and emotional design.

Jeroen van Geel: Earlier this year you wrote that design research doesn’t innovate, technology does. This caused quite a discussion. What were the main counterexamples you got back?

Donald Norman: No, that’s not what I said. And indeed, that is the main problem with the reaction I got: many people never read my post or listened to my talk: they simply reacted. (The people who did consider it thoughtfully were very favorable; in fact, I was invited to give it at several places, like Delft and the Copenhagen Business School).

Innovation is a very complex topic, very thoroughly discussed in academia, which is not something most designers follow. The important points are these: There are many forms of innovation–process, product, radical, incremental, and so on. I considered two forms of product innovation: radical (e.g., the invention of the telephone) and incremental (e.g., releasing a new version of a mobile phone, automobile, or kitchen appliance). Radical innovation in the products, I argued, always comes from the works of inventors, excited by some new technology and anxious to explore its potential. I do not know of a single radical innovation that has come from the people who do design research. Not the telephone or automobile, not Facebook or Twitter. Not 3D television nor, for that matter, high-definition television. Not hybrid autos. Not the Internet itself. Market studies, market research, design research, field observations (ethnographic studies), etc., do not yield radical innovations. They are very important in finding new uses of and improvements to existing products, but these are incremental innovations, not radical ones.

Incremental innovation is very important. Over 90% of the radical innovations fail (some of my friends say 99%). Yes, when they happen they change lives, but think about it: how many radical new product innovations have you experienced in your lifetime? One? Ten? Even if it was 100 that is still relatively infrequent compared to the thousands of incremental product innovations every day.

Moreover, radical innovation almost always starts off being inferior to what already exists: it takes good design research to transform that radical idea into something that is appealing to the world.

Alas, we train our design students to do radical innovation, even though in the real world, these radical ideas will almost certainly fail, even though they will be asked to do incremental innovation in their practice, and even though the evidence says that the radical innovations come from anywhere, and often take years or even decades before their worth is understood and appreciated.

In other words: we are not facing facts. We shy away from truth. We are delusional.

One of your points is that there is a gap between research and practice. What did you mean? Do you see any way of changing this?

Don Norman

Unfortunately, the term “research” has two very different meanings in design. One is the way it is interpreted by practitioners: design research is the early studies of the needs and characteristics of the people for whom the product or service is being produced. Let me call this “Design Studies.” The other is the interpretation by the university academic community as well as industrial research laboratories, where research is an activity aimed at increasing our fundamental knowledge in a field or of producing new concepts, ideas, and realizations. Let me use the term “research” for this activity. Both have gaps.

Design studies are often clever, engaging, and entertaining. But the relationship between the knowledge gained and the design of the product is often forgotten. Those who do design studies are often applied social scientists–not designers–and they often fail to frame either their studies or their results in ways that are meaningful to the design team. Many design teams simply ignore their reports. Now, I hasten to add that in many design firms, the design studies are done jointly with the design team, so this gap does not exist. But I find this to be the exception, not the rule.

Research, on the other hand, is aimed at the development of new knowledge and concepts, new ideas, and realizations of those ideas. Researchers often push technology to the limit, demonstrating compelling, engaging prototypes. But they are seldom practical. Here the gap between research and practice is fundamental: I do not believe it can be bridged easily. This is because the goals, motives, and even personalities of the research teams differ from those of the practitioners. One wants deep understanding, the other wants to know what to do next. One is happy as soon as an idea has been demonstrated, even if it is held together only by tape, string and mirrors–that is, even if it only works on special cases and requires careful attendance and repair by the research group. The practitioner wants something complete, robust, and reliable. Researchers are incapable of delivering this; they are too curious, too driven to learn new knowledge. The practitioner is too practical.

The design studies-practice gap can be overcome by better training of the design studies people, better integration of design teams, and better attention to the needs of the product team. The research-practice gap can only be overcome by an intermediary: a translation team that translates the research knowledge into practical realizations that the product teams can develop and deploy.

ON EMOTIONAL DESIGN

How far can we take the concept of “emotional design” in the nuts and bolts of a product? Do you believe it can infuse every aspect of the design process?

Emotion is so fundamental to human behavior that the answers are: “all the way” and “yes.”

While product designers have been designing personality into products for quite some time, it’s still very new in web design. Do you think we can design websites with a personality?

Don Norman: Not only is the answer “yes,” but we already do so. Everything has a personality: everything sends an emotional signal. Even where this was not the intention of the designer, the people who view the website infer personalities and experience emotions. Bad websites have horrible personalities and instill horrid emotional states in their users, usually unwittingly.

Everything has a personality: everything sends an emotional signal. Even where this was not the intention of the designer, the people who view the website infer personalities and experience emotions.

We need to design things–products, websites, services–to convey whatever personality and emotions are desired. Sometimes these might be negative. Mostly they should be positive.

You know about personas? Well, in design we should always create a persona for the product and ensure that everything in that product is consistent with that persona.

ECOSYSTEMS & DESIGN THINKING

In your book Living with Complexity, you state that products become stronger when they are part of an ecosystem. One of the obvious examples here is Apple–why do you think they were so early in adapting the model of an ecosystem? What makes them different?

Because Apple has always had a mission: to make technology understandable and easy to use. It has always put this first. (There was a period when Apple lost its way and stumbled badly in the jungle of ill-conceived products, but fortunately for all of us, Apple got back on track and now leads the way for others.)

When a company or design team wants to start working on an ecosystem, where should they start?

From the beginning: think through every single aspect of a product or service, from when the person first hears about it, to the advertisements, sales, and purchase experience. to the packaging and installation, to usage, service and updating, and to the products and services with which it must interact. Make sure everything fits the proper persona –the proper image. Finally, think of the end-of-life experience. Updating and/or replacing the item so that the transition from the old to the new is painless: no settings lost, no data, no personalization. And make it kind to the environment.

Think systems.

A lot of people, including many designers, believe that “design thinking” has become too detached from reality and too cocky. What are your thoughts? Do designers really have something different to offer from anyone else? If so, what?

Here I refer you to my Core77 essay on the topic.

As one of the pioneers of our field, where do you get your inspiration from? What is for you the best way to stay energized?

Stay curious. Always be learning new topics. I make it a point to learn a completely new topic every year. And I talk mostly with my critics. When people agree with me, it may feel good, but I don’t learn anything. I learn from those who disagree–that is, if they are intelligent and cogent, with good reasons for the disagreement. When the reasons are good enough, I’ll change my mind. But even if I remain unconvinced, i will have learned through the process.

Or as the old saying goes: Take your work seriously, but never take yourself seriously.

So let’s end with some light stuff. What book did you last read?

Ian Morris, Why the West Rules–for Now: The Patterns of History, and What They Reveal About the Future. This is an extremely important book: read the first chapter, then Section 3, then section 1. Skip Section 2, unless you are a deep history buff.

This year you’ll be a keynote speaker at UX Lisbon. Could you share with us what your talk will be about?

I never know what I am going to say until the night before. I get energized talking with the conference attendees. Quite often I change my mind at the last possible moment. What will I talk about at Lisbon? I don’t know. It might say in the program, but I never pay attention to whatever I told the conference organizers because they insisted even though I didn’t have the slightest idea. I want the audience to be surprised: actually, the person who is often most surprised by what I end of saying is me.

Thank you so much for your time. We look forward to seeing you in Lisbon.

You are quite welcome.

UX Lisbon 2011

Don Norman will be a keynote speaker at UX Lx: User Experience Lisbon, one of Europe’s premier user experience events. The second annual UX Lx conference takes place May 11-13, 2011 in Lisbon, Portugal.

Connecting Research and Innovation With Synthesis Thinking about complicated, multifaceted problems...
The Strange Connection between Entitlement, Social Innovation, and Interaction Design After teaching at Savannah College of Art and Design...
Mark’s UX clippings: Books and Research This week we dive into books and research. I...

Related posts brought to you by Yet Another Related Posts Plugin.

UX Project Documentation: Answering Why, What and How

2010-12-14T13:30:39Z

Many people don’t see the importance of gathering the necessary explanatory documents that define what you did all throughout your project development. Either that, or they treat the documentation process as a simple putting-together of all the sketches and wireframes generated. We should, nonetheless, give more relevance to this final, whole-project document.

For the record, it doesn’t mean a 500 page document or something of the sort. It means something more on the lines of a compilation of the strictly necessary documentation generated by your design process, in an orderly fashion.

Why does it matter so much?

There are a number of reasons that can be mentioned to answer this particular question:

Future projects reference

Be it as good or bad example (what we did right or what we should not repeat), you have a permanent record of what happened during the detailed development of your past projects to go back to. It’ll help you constantly improve your working process and, gradually, your results.

Organizing ideas throughout the development

It’s easier to maintain order with the necessary documents at your disposition to answer questions throughout the process about previous stages, what has been done and how much has been done of it.

Introducing new members to your team

It’s easier to help a new member of your team in the understanding of your working process when you have previous documents, because then he has something to look at and you won’t have to keep reminding him of essential points afterwards. Of course, this won’t eliminate your need for a formal introduction, but later on it will make the need for further questions a lot lesser.

Selling new projects

If you want to sell new projects to future customers, your presentations can include some portraying of your design process. If your client is requesting to know how you’ll be working and which deliverables he can expect to see (also so he can understand why you take certain decisions), your previous documentation can become a very good tool in this regard.

Improving your working process

Looking back at what was previously done, do you think you’re missing a step? Are you being too unclear and messy at some point? Are there misscomunications among your team members from one stage of the process to the other? A document can help you answer all of these.

What, then, should this document include?

It actually depends on the type of project you’re working on and the steps that project includes. Considering, thought, the hipothetical scenario that you’ll be working on a project that starts from scratch (meaning to say that you already have a product/service idea, we won’t get into marketing details) and finishes with the complete development of the website, the document should ideally include the following:

Project introduction

Basically, just answering the following questions gets you all the way across:

Who’s the main client?
Which is the main objective?
What’s the client’s vision of the project?

Written briefly and to-the-point, to have as the background of the whole project.

Identified users and user research

This means getting down to creating personas. And of course, the document will consist of all the created profiles after identifying the users and their needs. Having clear and complete persona profiles will support later stages in the design process.

Website content requirements

After deciding on the personas, what should the website have to offer them? Keeping in mind that we have now both, the users’ and the client’s needs documented, we can list requirements as a checklist to be later on verified and revised. There are many ways we can do this in an organized way to suit our needs at the moment.

Concepts to apply

How will these requirements be met? A great idea for this part of the process is given by the independent consultant and speaker Stephen Anderson, with his introduction of user behaviour concepts through cards that can be selected accordingly. This stage basically answers the question ‘What will we do to meet the previously established requirements?’, considering the issue in terms of user reactions and the concepts to apply in order to generate these reactions.

Information Architecture

A formal or informal diagram of the information architecture map is a must, as it’ll be an important guide throughout the later stages of the design process. A proposed method for doing it is explained by Jesse James Garrett, including the elements used to create the diagram and their relationship connections.

Interactions

This stage in the documentation process includes basic diagrams of the main interactions that will be applied in your website. Such interactions might include basic error notification, success notification, link behaviour, drag and drop interaction behaviour, among others. Make sure to have your feedback clear on each interaction diagram.

Navigation

A very interesting proposal by Hagan Rivers can help you get easily through this specific part of the design process. She brings the following idea with her:

Example of how to handle Navigation diagrams as stated by Hagan Rivers.

The navigation can be considered an application on itself. Its objective is to take you to the right screen.

Hagan Rivers

Based on this premise, you can use her approach of working with application diagrams to map your whole navigation system. If you are, of course, more comfortable with site maps, you can work on something like that.

Concept designs and prototypes

It is important not just to include the final, clean wireframe, but also some of the sketchy beginning ones, the ones in lower qualities with representative elements and some of the rejected ideas to illustrate your process.

Usability testing on prototypes

Example of a heatmap generated through usability testing.

Trying to keep it as lean as possible, usability documentation can include the final results and statistics. You may include the scripts you created as guides for you and your team if you tested it through focus groups or personal interviews, too. But you may have tested using a device such as eye-tracking or mouse-tracking, in which case you could just include the resulting generated maps, like the example shown on the picture of a heatmap.

Development plan and technical specifications

With the previous documentation and research, development decisions can be made. These decisions involve the technologies that will be used to create the application that has been designed, justified by the requirements that need to be met.

Style guidelines and patterns

The final specifications about colors, indentations, images, among others. These have to be well established and justified, too, in order to serve as a guide throughout the development process to maintain the visual design standards.

To sum up

Even though you don’t need to generate a bible out of every project you work on, the right amount of documentation can help you keep some order in the messy chaos that creative work generates.

Getting More From Analysis

2010-12-16T18:26:11Z

By Jared Lewandowski and John Dilworth

Analysis is a key part of design process that ensures the right problems are accurately solved.

Analysis is a crucial part of any design process. Without it, it’s impossible to know if the right problem is being solved and if it is being solved in the right way. It’s also a part of the design process that tends to be neglected or ignored. When integrated tightly into design processes and teams, analysis can improve understanding of the problems that project teams are challenged to solve. It can also bring clarity to the detailed and often complex requirements that solutions must meet.

About the author(s)

Jared Lewandowski resides in Salt Lake City with his wife and five children. In 1997, he began his career as a graphic designer in central Nebraska. Over the last 12 years, he's built many successful medical and financial websites, as well as presented on accessibility and usability to large and small businesses around the US. He currently manages JL Design Group and works as a UX engineer and interaction designer for the LDS Church.

John Dilworth has been working in interactive media and design for over 15 years. He has a strong background in fine arts and visual communications, and holds an MFA in Computer Arts. He currently manages an interaction design team for the LDS Church, teaches university courses in interactive design, and maintains his own fine arts studio. More information can be found on his personal website: http://www.johndilworth.com

Is the Sitemap Losing Its Client-Facing Steam?

2010-12-22T18:19:23Z

By Vincent Au

Keeping the sitemap useful and relevant as the complexity of sites increases.

Lately, I have found myself questioning the effectiveness of the traditional sitemap as a stakeholder-facing deliverable. The main goal of a site map is to provide a holistic look at a site’s (or application’s) structure—that is, to answer the big question of “What goes where?” These days, however, site structures are not as simple as they were in the early days of the Web, and the “positions” of pages, functions, etc., are not so cut and dry.

UX Design and Agile: A Natural Fit?

2010-12-27T09:42:08Z

"Generally speaking, as an interaction designer you don't want to invest a lot of time programming something live, since what you really want is to keep iterating on the fundamentals of the design quickly. That's why working with paper prototypes is so commonplace and effective early in a project." (Communications of the ACM 54.1)

Kathy Sierra - Creating Passionate Citizens

2010-11-22T05:00:00Z

Kathy Sierra examines how to create passionate citizens by inviting people to understand the dynamics of passion. Drawing on an interest in the brain and artificial intelligence, developed during her days as a game developer (Virgin, Amblin', MGM), Sierra explains what is necessary to instill and excite passion. From the perspective of an engineer she applies the formula and provides a solution to develop not only the product of passion but a passionate end user as well.

danah boyd - Transparency Is Not Enough

2010-11-16T05:00:00Z

Data transparency is not enough; danah boyd powerfully argues that the character of data depends on its interpretation and states her case for data literacy. If people are ignorant about how data is generated, selected and interpreted, power accrues to those who can 'spin' the data to support their opinions and biases. Using the example of publicly available sex offender data, released under Megan's Law, boyd shows that understanding the complexity of data is just as important as making it transparent.