• •Reciprocation: the idea that people give back to you what you give to them. Evidence for this rule abounds in human culture; Cialdini cites several sources that suggest it exists in cultures around the world.

• •Commitment and Consistency: our almost obsessive need to appear consistent with what we’ve already decided to do, particularly commitments made in public. Our need for consistency, while often a good and valued part of being human, also seems to get us into the most trouble; for example, the smoker who knows full well the risks of smoking, but still manages to minimize his vulnerability to those risks (Gibbons et al, 1997).⁠
• •Social Proof: the idea that we look at what those around us are doing to guide our own behavior. This is another key area where, when we are mistaken in our search for the right action in a given situation, the impact can be dangerous. The so-called “bystander effect,” in which an increase in witnesses to an event actually decreases the likelihood that the person in distress will receive help, is well demonstrated in the chilling example of Catherine Genovese, a young woman murdered in 1964 New York City while 38 of her neighbors watched, each believing that someone else must have called for help (Influence, pp. 112–118).
• •Authority: the way that we often defer to people who are perceived to have authority or knowledge on a topic. Note here the use of the word “perceived;” the most interesting facet of this principle is that simply having the appearance of authority—for example, a uniform—can have the same effect on our behavior as a legitimate authority figure. Con artists, Cialdini notes, make use of this principle often.
• •Scarcity: the idea that the more limited the availability of a given opportunity, the more we want that opportunity. This is often seen in retail sales, where customers are warned that stock of a particular item is “going fast!”
• •Liking: this principle states, quite simply, that we tend to want to help people that we like and trust. This one seems almost a no-brainer; what’s interesting about it, however, is the many ways that influence practitioners can facilitate the liking process, or use our relationship with friends to get something from us. Cialdini opens the chapter with the example of home Tupperware parties, where the attendees are driven to buy more often on the basis of their friendship with the host than a genuine need for the product (Influence, pp. 141–142).

The thing to remember, Cialdini argues, is that in most cases these tendencies are actually good for us; they help us make sense of an increasingly complex world, and prevent us from spending each day in a state of analysis paralysis. The problem lies in the ways that these otherwise adaptive strategies can be used against us by forces who want to get something from us; those that Cialdini describes, in an interview about the book with business blogger Guy Kawasaki, as “Smugglers:”

Smugglers, on the other hand, do know—quite well—what the principles are and how they work. But they import these principles into situations where they don’t naturally exist. An example would be a salesperson who pretended to be an authority on a particular computer system in order to get a customer to buy it. Although the smuggler’s approach often works in the short run, it’s deadly in the long run. Because only one person—the smuggler—wins. The customer, who gets fooled into buying the wrong system, will be unhappy with it and will be unlikely to ever return to that salesperson or dealer for future business.

Cialdini identifies a variety of influence smugglers throughout the book. These range from advertising agencies who use actors to pose as “regular customers” of their products in order to make others think people just like them love the product (demonstrating the principle of social proof), to Hare Krishnas, whose recruitment tactic of giving a small gift to pedestrians plays into the reciprocation principle so effectively that people go out of their way to avoid coming into contact with them. Each chapter cites a wealth of examples, both anecdotal and academic, describing how these principles can impact our behavior; each chapter ends with a reader anecdote on the chapter’s subject.
Another key feature of Cialdini’s book is a section in each chapter called “How to Say No.” In this section, he not only shows readers how to recognize influence principles at work, but he also offers ways to counteract them. It is here that Influence is most useful, but it’s also where Cialdini tends to lapse into a cranky long-windedness that hurts his message more than it helps. In his chapter on the theory of social proof, Cialdini calls for a mass boycott of products advertised with actors representing customers—what he calls “phony ‘unrehearsed interview’ commercials.” But far beyond simply suggesting the reader stop buying these products, he recommends launching an aggressive counter-attack of the company’s “bad social proof:”

“Moreover, each manufacturer of the items should receive a letter explaining our response and recommending that they discontinue use of the advertising agency that produced so deceptive a representation of their product.”

In most cases, the advice given in each “How to Say No” section is useful—particularly in the context of putting these theories to practical use. However, in this case, as well as in his imagined response to the “stunning young woman” who duped him into buying an overpriced entertainment package by playing on his desire to impress her (Influence, p. 94), the advice Cialdini gives seems reactionary, and overblown for the issues that he’s describing.
Despite these flaws, Influence remains a valuable work, particularly for those who work in industries—such as sales, marketing and design—that depend on the ability to use the principles Cialdini outlines in an effective, yet ethical, manner.
References
Kawasaki, G. (2006, April 26). “Book Review: Influence—Science and Practice.” How to Change the World: a practical blog for impractical people. Retrieved from: http://blog.guykawasaki.com/2006/04/book_review_inf.html#axzz1aOW5Edgh.
Cialdini, R. (2009). Influence: the Psychology of Persuasion, Adobe Digital Edition. New York, NY: Harper Collins E-books.
Gibbons, F., Eggleston, T. & Benthin, A. (1997). Cognitive Reactions to Smoking Relapse: The Reciprocal Relation Between Dissonance and Self-Esteem. Journal of Personality and Social Psychology, Vol. 72 No. 1, 184–195.

Dani: Talk to me about web type. How do you find that web type plays into this whole Design for Drupal thing?

Jason: very easily, actually. One of the things that led me to go back to working on my own, which now is over a year and a half ago, was being stuck in too technical a role in this agency I was working at in Providence, and not being able to deal with the design and strategy side of things as much as I enjoyed. I think that’s honestly what I’m better at. And that coincided with Typekit being launched, and I had been following what was going on with that, and ended up getting a subscription to it and playing around with it. I’d always really loved type, but never really was taught a whole lot about it. And this was one of my first real chances to play around with it, so I got into it right away.

At first, I just dropped a line or two of Javascript in my theme file and was fine, but then I had this idea that I’d never made a module before, but there really ought to be a Typekit module. Turns out this guy had sort of started one, but had left it sitting in a state that was really, really rough. I saw that as my opportunity, so I picked it apart, I rebuilt the whole thing and figured out the things that were and weren’t going to work, like automatically setting it to load the https script if it’s on a secured page, and adding an external Javascript call — this was for Drupal 6 at the time, so Drupal was a bit finicky about that. So again, there was this sense of figuring out how Drupal worked in order to get this stuff in there in the right way, and it really wasn’t all that hard.

So the module got much better; it was much more flexible and easy to use, and Typekit was a great service to work with and had a lot of really neat stuff. That was my first real effort at doing any amount of community work to make that thing better. But it sort of made me think about both the use and the shortcomings as well; so I started researching that a lot more — how to use web fonts better. How to deal with the things that might not go right. With all the performance enhancements in the service, I started using it more and more, even for body type. It was just this really liberating thing to be able to design with all of these fonts and not have to ever look at Arial on a web page again.

Dani:  you really don’t like Arial, do you?

Jason: you know, it’s nicer than having to pick on Helvetica all the time.

Dani: That’s true.

Jason: but I have to say, there are a few that are really just no better. We have a project at SchoolYard currently that specifies Univers for the body type; it’s a utility font. That’s the thing that really underscores this web font thing: these fonts are there, and they’re used, because they have no impact. They’re easy to use in any scenario because they don’t lend anything to the design.

Dani: I also think that one of the things people look for is something that is universal, I guess. It’s a readability issue.

Jason: well, sure, but there’s a ton of great fonts out there that are extremely readable.

Dani: I agree.

Jason: and yes, I understand that the Helveticas of the world have their place, but when presented with the option to do something different after 15 or 18 years of having to do everything in Arial or Helvetica, it’s time to do something different. And what I enjoy about that is that it shifts the entire tone of the design when everything is different instead of just headers or accents being different; and that’s what makes web design a lot more fun again.

And then extending that to mobile devices and other platforms, and still being able to bring that consistency, makes it even better. So then extending it further into the Drupal world, there’s Scott Reynen with the @font-your-face module[1], which actually blends all the different services together. So then you can use one font from Typekit, one font from Google, and all these different services together without then having to do anything in your theme if you don’t want to.

There’s some interesting possibilities there. I was just having a conversation with him last night about it, and it’s headed in a really good direction. Hopefully we’ll be able to see some really need stuff soon.

[1] http://drupal.org/project/fontyourface

Intro to LogoGarden

The interesting thing about this video, and about the various things that have been written about the aforementioned site (mostly by its owner), is this:

While the various “cheap logo sites” claim to have professional designers, but more often than not use untrained designers who actively steal other people’s work, logo garden basically admits to ripping off the work of professional designers directly in their advertising.

A few of my friends in the design community, including Jeff Fisher and Von Glitschka, have already spotted several of their logos being ripped off by the site; in fact, both of them seem to have found at least 20 of their logos, if not more, being offered to customers of the site.

This is all horrible, and clearly the dude who runs this site is irresponsible, if not actively malicious. But the more I read about it online, the more I wonder if actual legal action is being (or even can be) taken against these guys. Below is a conversation I had about the subject in response to Jeff Fisher’s discovery of yet another logo of his that had been ripped off by this service.

Dani Nordin: Are you and Von planning on delivering Cease and Desist letters to these guys?

Tom Stephan: Von did one better — he tagged the WWF and asked them if they’d seen their logo ^_^

Dani Nordin: +Tom Stephan That’s great, but I don’t see it as “one better.” Frankly, we can bitch and moan about stolen designs as much as we want on the internet; it’s not going to stop these idiots in their tracks until there’s real legal action behind it.

Tom Stephan: I think hitting them from all angles is best. One flashlight scares a cockroach. Floodlights stun it and make it easier to squash. I’m certainly not saying this situation is funny or amusing; I’ve had my own work stolen (not in this scope or scale) and I’m aware that it’s invariably who has the money to fight the thievery. The WWF certainly does, and that may turn the tide in favor of the ‘good guys.’ That being said, LogoGarden will shut down and reopen in a few months or weeks as “LogoForest” or something, and start again…it is what it is, and one of the unfortunate downsides to a tech-enhanced world.

Dani Nordin: +Tom Stephan I don’t disagree with that, actually; I just find myself jaded when I see several days of angry Internet conversation about something without any kind of formal cease and desist letter… of course, seeing it from the outside, it’s very possible that there has been one, but that fact hasn’t been shared. The sad thing is that these types of idiots will never go away; and at least this LG site doesn’t pretend that their competition is professional designers; in the intro video I saw online, they were pretty clear that LogoWorks, etc. was the alternative for this market. They even called out several of the key reasons that professional designers advise against sites like that; the cheap labor, the dude who knows Photoshop (sorta) and throws things together quickly.

Ultimately, the market for all of these sites is the cash-strapped “entrepreneur” who has a “million-dollar idea” but doesn’t know what’s really required to get something like that launched. In other words, the types of clients that most professional designers (especially independents) find crazy-making.

Todd, if you’ve never met him, is one of the founders of Austin’s Four Kitchens, a team that works on big websites for great clients. They’re also the people who co-created Pressflow, a Drupal distribution built especially for large-scale websites, and they also run DrupalCamp Austin, which is happening in November.

The following conversation happened a few weeks ago, and covered a huge range of topics — mostly grid systems, design for Drupal, responsive design and various snarky tangents. In this bit of it, Todd and I go off on restaurant websites, and we also talk about working with clients who don’t understand the cost of creating a good web presence.

Todd: I have noticed that the #1 factor in project success from a design standpoint is: has the client done this before?

If this is a client who has tapped three or four people who are junior-level, or are new to this, and they’re communications or marketing people or something, and the CEO says “hey, we need a new website — you’re sort of in charge of that…”

Dani: yes — “you’ve done HTML before, right?”

Todd: exactly, and the person is thinking, “I’ve never done this, I’ve never built a website before,” they come to us and they say, “hey — I’ve never been through the process of building a website before and I don’t know what to expect.” There are two possible outcomes that come from that. Either they have full faith in us, and their bosses have full faith in us, or they listen to us, and they have full faith in us, but their bosses don’t. Or their bosses are saying “we’re a non-profit that has never really done a serious website, and we don’t really get project management — I don’t really understand why UX is necessary. It seems like a lot of extra fluff to me.”

They don’t take us quite so seriously, or their attitude is, “that looks good enough. I don’t want to spend any more money on design. I just need the website to ‘do’ certain things. I don’t really care how it looks.” Those are typically the people who have never been involved in a web project before.

Dani: I also find that part of dealing with non-profits, especially in the client intake/sales process, is reading between the lines, and listening to how they *say* “we’re a non-profit.” I’ve done a lot of work with non-profits, and I find often in conversations with fundraising/development managers that if you hear them say, “well, we’re a non-profit,” in a certain tone, that it’s often a cover for a host of things that they don’t want to deal with.

Todd: Yes, that ends up becoming code for “we’re a non-profit, so we do everything bare-bones.”

Dani: Yes. We do everything bare-bones, we don’t have a lot of money, and to put a sort of New Age spin on it, it’s sort of a “lack” vs. “Abundance” mentality; you think that because you’re a non-profit, you basically have to spend almost no money on your marketing; meanwhile, if you look at the list of biggest, most effective non-profits with the largest reach in the Boston area, most of them spend about 5-6% of their revenues on fundraising efforts — including their website. They’re spending that money, and as a result, they are getting more donations, and they’re able to do more work, than perhaps 100 smaller non-profits in that space combined.

Todd: it’s surprising, too, how many people don’t seem to understand that the most effective dollar they can spend is on a better website. It’s sort of like, when you go to a restaurant’s website, what do you care about? Phone number, address, menu. That’s really all you care about. Who’s the chef? That’s an afterthought — that’s what you might get into when you’re starting to dig around and learn more about the restaurant.

Chances are, when you’re at a restaurant website, you’re about to leave the house and go out to eat, you need the number for reservations, you need the address so you can look it up on a map, you need a menu to make sure that your friend who’s gluten-free can actually eat something there. Or you’re looking at it — which is even more likely — on your phone, and that address is locked into an image, and you have to somehow put that address into your memory long enough to switch apps on your phone and type it all in to find the restaurant — or the menu is locked into a PDF, and you don’t have a PDF reader on your phone.

This is all super-basic stuff, and yet restaurant websites, more often than not, tend to be about the show, not about the information. That sort of conflicts with what I said about advertising dollars, but I suppose it depends on the industry. In the case of a restaurant, chances are that you’re not going to learn about the restaurant on their website, but on Yelp, or some other thing that is gauging its value. It’s not like a non-profit, where you do have to learn about the non-profit and what they do on their website. I don’t think there’s a real “rating system” for non-profits. You’re going to their website because you want to a) donate, or b) learn more about them.

I find that so many websites just assume that the website is little more than a brochure, or a television commercial, or it is some thing that is not a website.

A website has to do what the users of that site expect it to do. And restaurant websites are a good example of how many websites *don’t* do that, because they’re so egregious. They, on the whole, entirely miss the mark. You arrive on the website, and it’s a fashion show. It’s this Flash thing with all the dishes fading in and out, and all this sliding stuff, and you’re like “no. I don’t need this. I just need your address.”

Dani: well, I also think that, at least in the restaurant world, that you’re going to find all that other information on Yelp. So you don’t “need” to have it on your website.

Todd: perhaps.

Dani: The other problem, I find, with restaurant websites — I’ve actually done quite a few, and while I was able to talk them out of Flash slideshows, I’ve done my share of downloadable PDF menus — the biggest problem with creating a good restaurant website is actually updating the menu. The reason is that most restaurants don’t actually have a marketing person. The person updating the website is often the owner of the restaurant, or the owner’s son/daughter/whatever. They’re a chef, they often don’t have very much tech savvy, they usually work 12 hours a night or more.

If you’re a chain with a big marketing department, or you’re a hometown diner with 20 things on the menu that never change, it’s not a big deal, but if you’re like any of the restaurants that I’ve worked with, where you’re a relatively small place with a focus on local, seasonal food, you’re constantly changing your menu. With one of my clients, I basically just set up a Pages template and showed him how to upload a PDF. Because his menu changed every week, and he didn’t have the time or ability to figure out how to update the code of his website. Another client calls me every time he has to change his menu because it’s written completely in HTML and he can’t figure out how to make changes.

So yes, you’re probably just looking for the menu, or the contact information, but the problem with a lot of restaurants — and the reason I think so many of them are horribly bad — is simply because either they’re sort of “fashion” websites, where it’s not so much about the food as it is about the atmosphere, or they are restaurants where you have someone in charge of the website who doesn’t have time, knowledge or interest in maintaining this website.

Todd: Right.

Dani: So really, either way you’re screwed.

Todd: Yep. I imagine that partly, this is — and I think this speaks to all types of industries, and all types of websites — that so much of it requires buy in from the owner of the website, or the owner of the business it represents. In the case of restaurants, you need the owner or chef/owner to not only update the document where they update their menu and print it out — because no chef, no matter what, would not announce the menu in some way; whether they put it on a black board, write it on paper, or maintain it in a Word Document. Because, duh, you can’t not have a menu.

It should be, in my opinion, and I think that this will change over the next several years; it’s changing now, in fact — it needs to be just as “duh” that you have to update the website when you change the menu. Or maybe, you change the menu on the website and print it off from there. Maybe keeping the menu in a Word document or something similar is doing it backwards. Why not kill two birds with one stone and have a good printable template that’ll print directly from your website?

Dani: See, now that sounds like a Drupal distribution that needs to be made, there, Todd. I think we need to work on that.

Todd: [laughs] That would be be cool.

Dani: I think we’ve figured out what we need to do next.

Todd: You’d need one “menu” page node with a good, printable template.

Dani: Absolutely.

Todd: I like this idea. 

My mother, because my niece is now officially a Middle Schooler, decided in a fit of generosity and proudness, to buy my niece an iPod Touch, which she’d been begging for for MONTHS.

She didn’t, however, do any research into actually *owning* an iPod Touch, which meant that she didn’t realize that owning it required my 12-year-old niece to create an Apple ID, which requires her to put in somebody’s credit card information.

So when the niecelet told Grandma that they needed a credit card in order to let her set up an account, Grandma said, “hell no,” and thought no more of it.

Then she got her credit card bill. And lo, the niecelet did FIND her credit card, and go more than a little bit crazy on the App Store. With two separate cards.

So now, the tech-savvy aunt gets called, and I get to spend my weekend cleaning up a big old mess.

Here’s my problem with all this:
When I called the Apple Store, to complain about the fact that there’s no actual option to CONFIRM that an Apple ID belongs to a child and set restrictions on it, I was advised to simply get her an iTunes gift card instead of using a credit card (and where in the UI for setting up an account is that even mentioned?). Or, alternatively, I could set her up with a pre-paid credit card that I keep adding money to as rewards for good behavior. Good idea, if she was 13; most pre-paid cards require the user to be at least 13.

Both of these are excellent suggestions, and ones I had thought of when I was planning on buying her a Touch (before Mom decided to do it herself). However, there’s still a single, epic fail at work here:

Apple does not bother checking to see whether you are a CHILD before you set up an Apple ID. Or rather, it does, but it makes it way too easy to lie about your age.

And if you are a parent, setting up an Apple ID for a child, it does nothing to help you monitor and create restrictions on the account. For example, if I set up restrictions on the Touch (which, believe me, I have), all I can do is disable the ability to access iTunes or the App Store altogether; there’s no way to, for example, allow her to download all the free apps she wants, but require a passcode that I set up to download any paid apps. And they sure as hell don’t make it easy to figure out how to remove your credit card information from a given account, which is evidenced by the over 5 million results for “removing credit card information from iTunes.”

Really, Apple. This is serious s***

I have no problem admitting that I’m a rabid Apple fangirl. But on this topic, they have majorly, epically failed. I love the idea of changing the way that we buy music and apps; but really, if you’re going to do that, it’s pretty much common sense to recognize that kids are consumers too — and give parents a way to easily (note, I said easily) prevent their kids from bankrupting them on Justin Bieber mp3s and multiple seasons of a TV show you’ll never watch.

Here’s a simple way to do it:
The moment you enter your date of birth into the Apple Store, and it shows that you’re less than 16 years old, don’t require a credit card.

Their current practice — simply telling you that you “don’t meet the minimum age requirement,” is the same kind of stupid cop out that Facebook uses. Both of them want to pretend they don’t have to take responsibility for what tweens do on the service. There’s nothing that will prevent a kid from simply lying about her age, or that requires someone to actually verify their age somehow. So, my 12 year old niece simply pretends she was born a couple of years earlier, and hilarity ensues.

Let’s face it: if you make a fun product, parents will want to buy it for their kids. And not all parents have the technical prowess to deal with all the crazy wrenches Apple throws you to simply use their products. Yes, it’s easy(ish) for someone who is used to everything that Apple makes, but for someone who just wants to own an iPod, there’s a ridiculous, and DANGEROUS, learning curve that Apple has decided to throw in the works for any kid who gets one of these things for Christmas.

And yes, I’m COMPLETELY fired up right now.

In some ways, it’s remarkably similar to what I do in my consulting/UX work. There’s a huge amount of research, and user interviews (I’ve done about 12 interviews thus far, and still haven’t talked to all the people I want to), and the book is basically the result of that research and interviews. But I’m still working on the flow of writing; getting to that state where I can accept that writing and research is what I do all day.

This is, I think, a problem of being self-employed for as long as I have been. I get so accustomed to wearing several hats that wearing any one of them for too long feels foreign. While this is a pattern I’m looking to change in the future, once I find the right team, I imagine that there’s still a bit of unlearning I have to do in order to feel truly comfortable focusing my attention exclusively on the aspects of my job that I love. The temptation to retreat back into code and implementation – which is often easier, but less interesting to me – still catches up to me now and again.

None of this is really a complaint, per se. But it is an observation that being a writer seems to have a different character, and a different set of requirements, than being a site builder or a coder. Because writing is something I love doing, it almost feels like I’m taking a break; I couldn’t possibly be doing this because I’m paid for it, or because it’s my job. This is what I’ve always done just to get things off my chest, or to share information that I’ve learned. Having it as my job, at least temporarily, almost makes me feel like I’ve been given a free ride to goof off. So while I’m making headway on the book day by day, I almost feel guilty having to step away from code and clients for a few hours a day.

And then I remember that there’s a book deadline looming, and I have a lot of research to compile, and I get back to it.

The best UX design comes from collaborative effort, not working in a silo.
Traditional “waterfall” projects, where the entire design process is siloed and done prior to development, often leads to work being hacked up in the development phase. As a result, many UX designers end up feeling embarrassed by projects after the fact. As Leisa notes in a recent blog post, it’s not uncommon for UX designers to accompany their portfolios with an embarrassed “don’t look at the site; it’s awful.” By engaging developers early on in the process, and ensuring that you’re creating things that can actually be implemented, you reduce those risks.

Say you’re a UX designer on a corporate team; too often, your job amounts to working away at a desk, headphones on, creating a stack of wireframes that you then present to stakeholders. Two things will usually end up happening here:

1. Because you did the design on your own, regardless of the stakeholder input or user interviews that went into the design, your instinct will be to defend the design against a perceived onslaught of criticism. This shuts down stakeholder input, which can only make your life more difficult.
2. Similarly, because this design was done in isolation, stakeholders may feel that they haven’t had enough input in the design, which will lead either to strenuous objections that derail your design, or worse – unwillingness to comment at all, which keeps you from making the design better.

This doesn’t just happen on corporate teams; it happens in Drupal shops, Agile environments, and all sorts of tech development teams. In an artifact-centered environment, much of the actual thought that goes into good UX design can get overlooked or devalued; many a designer has heard feedback that stakeholders don’t want to “waste too much time” on activities such as user flows, concept diagrams, and other things that help us frame the design challenge before us. As designers, an important part of our job is communicating to clients the importance of just those activities, and encouraging clients to get on board in helping to create them.

We’re not designing pages, we’re designing interactions. At its most basic level, a website is a collection of web pages. But underneath that collection of pages is a series of interactions that a user will have with a given system. Even something as simple as a newsletter signup – something that’s often thrown into a webpage at the last minute – carries with it a series of questions that need to be answered:

• What information do you need to collect?
• What information will the user be willing to give?
• Why would they be willing to give that information?

Keeping design purely at the level of wireframes – or pages – prevents stakeholders from understanding how those interactions play out. Information Architecture is not just about understanding Drupal’s menu systems and taxonomy – it’s about understanding how users expect to access information on a given website. It’s about creating an interaction that makes sense – and stripping out the things that don’t.

Good designers are facilitators as much as they are craftspeople. Let’s face it. This is an industry that favors tangible artifacts over process. It’s easy to talk about the craft of design – and to judge its physical output. We’re used to doing it. But design is not just the creation of artifacts. More often than not, a designer is facilitating collaboration among stakeholders from varied backgrounds – all of whom have a stake in the final output. We’re asking tough questions, and creating patterns and use cases. How, then, do you sell that? What does a wireframe, for example, tell you about all the non-tangible elements that went into creating that wireframe? When your role in a project is to act as facilitator, what in the physical output of that process can you claim as “your” work?

The confusion of physical artifacts versus process is one of the key reasons that many teams don’t understand what good UX design actually entails. Too often, as mentioned above, the focus is on tangible output – wireframes, user flows, etc. – and often, the processes that truly make up the design of a successful interaction have more to do with conversation, conflict, and being up and away from the computer. How do you communicate that process, and its value, in an environment that is still obsessed with what they can see?

This is a challenge that Leisa is starting to work on. The idea, still in development, is to create short video portfolios that document a given design process. And yes, she’s prototyping it in Drupal.

Start prototyping as early as humanly possible. One way to ensure both that you’re capturing the interactions that need to take place in a given system, and to ensure that what you’re designing can actually be implemented, is to start prototyping as soon as possible. This is one of the key benefits of Agile environments – whether you’re working on your own or in concert with a developer, putting ideas into code not only makes developers happy, but it allows you to see what issues come up with your designs early in the process.

This doesn’t mean that the classic Drupal approach of “there’s a module for that” is correct, either; starting to prototype early in the process doesn’t excuse you from putting thought into how interactions might play out, or spending time sketching out ideas before you jump straight into code. One of the biggest challenges that site builders face – whether they’re designers or developers – is leaning too heavily on Drupal to create interactions for you. Design patterns are useful, but it’s just as important to make sure that the patterns you’re choosing are the right ones for the job.

Drupal needs designers. But it doesn’t just need designers to enter the community; designers come into Drupal all the time. Getting them to stick around? That’s a bigger issue. Recently, when discussing my path as a Drupal designer with a colleague, he asked me, “Why Drupal?” My immediate answer was, “because I enjoy an uphill battle.” Yes, things are getting a bit easier for designers in the Drupal community. People get that we’re doing good work, and they’re starting to understand why we need to be here. But too often, the design conversation in the Drupal community isn’t a design conversation at all. It’s a theming conversation. At the last two Design for Drupal Camps, the feedback I saw from designer friends of mine – people I had specifically invited to the camp – was that for a design camp, there was surprisingly little in the way of design sessions.

This is one of the challenges inherent in a developer-centric culture such as Drupal; while theming and front-end development is vitally important to successful Drupal projects, calling it “design” is one of the things that prevents designers – many of whom are very skilled, but not coders by any stretch – from feeling welcome in the Drupal community.

There’s much more to cover here. It feels like this post barely scratches the surface of all there is to say about good design in the Drupal community, but to use a phrase from my dad, it’s a big nut to crack. Constructive comments are warmly welcomed.

New things:

1. We discovered that, in Prague, there seems to be such a thing as a Tourist Dungeon. At least, that’s what we’re calling it. The first night here (after we fell asleep for several hours due to OMGJETLAGWTF) we went to a brew pub called Pivovarsky Düm. Excellent beer, okay food, but the service – well, let’s just say that once the host realized we were tourists, we were very politely pointed to the basement, where we were delivered English menus. This, after being told off by a waitress and the bartender for asking if we could grab a beer while we waited for a table. Fortunately, this hasn’t been my experience with every place we’ve been, but it was still uncomfortable for our first time in the city.
2. Why did we stay, you might be thinking? BEER. Delightful, unfiltered, wonderful beer. The fruit beers were not really my thing, but I will say that they were the best of the genre I’ve tried. My favorites were Coffee beer (OH MY GOD GOOD), and Nettle beer – which was green, with a very herbal thing going on. If they had it in the US I’d buy it by the case. It’s a much better St. Patty’s Day alternative than the Budweiser with green food coloring we serve in bars around Boston. Nick tried a Wheat beer that, speaking as a Harpoon UFO fan, absolutely blew UFO out of the water. It was fresh, lemony, and the best of the bunch that we sampled.
3. Speaking of Budweiser, apparently it’s also the name of a Czech beer that’s entirely different from Budweiser, but has exactly the same logo. Our hotel, in fact, serves it.
4. I have decided that there are entirely too few sandwiches that involve sliced hardboiled egg. Part of this was decided based on Clover’s Eggplant and Egg sandwich (one of my favorite things). But in the Amsterdam airport, I was delighted by a sliced egg and bacon sandwich, and there’s a deli near our hotel that serves slices of bread with sliced egg, a bit of cucumber, tomato or pepper, a slice of ham and pickle. It is the most wonderful thing ever. I have a feeling I just found my new summer staple meal.
5. I’ve also learned, thanks to a Drupal buddy of mine, who introduced me to a local Drupal designer, that there’s a Coworking space less than a mile from my hotel! I plan on heading over there on Wednesday to work for the day, and I’ll be heading to a Drupal meetup that evening – which will likely be all in Czech. I’m fascinated to see how that works out for me (I know very little Czech).
6. Most things here are surprisingly cheap. The best, though, was massage – through the hotel, I got an hour-long, and desperately needed, massage for about $60 American, which included tip. I can’t tell you how much I needed that – I can, however, say definitively that it will be happening again on Thursday.

And, just a touch of snark:

1. I didn’t realize until I came to Prague exactly how much Rhianna or Celine Dion I could listen to in a sitting. Thanks to the hotel, and the local coffee shop, I’ve learned that the answer is “quite a bit.” I’d like to unlearn that.

I’m trying to view Prague as both a bit of a much-needed vacation and a writing expedition. The first draft of the project management guide for The Designer’s Guide to Drupal is due on June 1st, and I’m much further along in writing than I am willing to believe I am. It’s interesting, once you start getting things down on paper, both how much you actually know and how little you *think* you know. No matter how much material you have, it never quite feels like enough. Fortunately, things are going along pretty well, and this trip offers a good opportunity not only to get out of my normal way-too-busy schedule, and organize the vast amounts of research I’ve been collecting into something cohesive for the publisher.

What’s been delighting you lately?

“Some practicing designers balk at the idea of designing poetic interactions. One early reviewer of this text was as blunt as to say, ‘I have other things to worry about – like shipping a working product that isn’t awful.’ Yet if designers focus only on the low-hanging fruit of functionalism or usability, the human experience with designed objects is destined to a level of banality. As ideological as it may appear, what if that piece of enterprise software offers – for a fleeting moment of use – a poetic or soulful experience?”

This dichotomy of usable vs. “poetic” interactions is something I’ve often come across as a designer, before and after the transition to UX. When I talk to clients and hiring managers, user experience is far too often discussed in terms of usability testing, to the point where the terms are interchangeable. When asked what kind of user experience activities a team might do in a course of a project, often the answer is wireframes, a few user flows, and user testing – in fact, the ability to write and execute a test plan is the most often requested attribute of UX designers in job postings, aside from knowing a whole bunch of front-end coding stuff that many UX designers don’t touch.

This got me thinking more and more about the author’s discussion of poetic interaction, and the idea of creating something that isn’t just usable, but can actually shape behavior. Whether we want them to or not, the interactions that designers create can help shape behavior, for better or worse. Facebook, for example, has changed the way that we think of social interaction on the web. Is the interface “usable?” Yes, once you get used to it. But the point of Facebook isn’t an easily intuitive interface; it’s about getting you to interact with people in a new way.

Likewise, the RMV isn’t necessarily “usable.” But it does have some poetry to it. When you arrive at the RMV, you’re sorted according to what you’re there to do, and then you get a number that corresponds to the task you’re there to perform. By separating the tasks with a letter (as they do in Massachusetts), and giving you an approximate wait time up front, you’re prepared for the task of waiting. You know what to expect. So you bring a book, or your iPod, or you find some other way to occupy your time.

This is the difference that exists between things that are “usable” and things that are “poetic.” You may not understand the poetry, you may not appreciate the poetry, but it exists. And subtly, it changes you.

To that end, a couple of changes have taken place:

1. In January, I contributed several chapters on design and Drupal foundations for the Definitive Guide to Drupal 7, which is being released sometime in the imminent future (so I’m told) by Apress.
2. I just wrapped up one of the most challenging projects of my career – working on a team doing UX and prototyping for a site redesign that will be launched later this year. The project (and my contributions to the Apress book) gave me a huge opportunity to get over some enormous learning curves with Drupal 7 (not to mention UX deliverables and working on multidisciplinary teams), and I can’t wait to do more of it.

Speaking of getting over Drupal 7 learning curves, I’m also in the process of writing a series of books for O’Reilly Media, tentatively titled Drupal for Designers. The series is intended to provide a designer-friendly guide to working with Drupal, estimating and planning projects, managing client relationships, and all the other knowledge I’ve collected over 6+ years of running my own design studio. It’ll be released online a bit later this year, with a print edition (hopefully) planned for 2012 sometime.

In the meantime, I’m still open to new opportunities. If you know of a great team looking for some UX love, drop me a line anytime.