Blog

Gearing up to write

As I may have mentioned on this here blog (but also have been oddly quiet about), this summer is a Writing Summer. I’m in the middle of writing Drupal for Designers, a series of guides for O’Reilly geared towards designers who want to work with Drupal but don’t need yet another recipe book telling you how to download a module. It’s a great project, and one that I’m psyched to be doing. But I am noticing that the experience of writing a book, from a project management standpoint, is far different from the experience of creating a website. 

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. 

In which I vent with Leisa Reichelt, about UX and Drupal.

It was a dewy, slightly drizzly day on the Internets. I was on my third latte. 

Serenaded by the sounds of a bustling coffee shop in Prague, I chatted over Skype with Leisa Reichelt, part of the UX team that is responsible for the overhaul of both Drupal.org and Drupal 7. What follows is a rather incomplete summary of our conversation, which centered around the challenges inherent in doing, communicating and selling quality UX work. 

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.

Usable vs. Poetic Interactions

In Thoughts on Interaction Design, author Jon Kolko talks about “poetic interactions.” The thrust of his essay was that a truly poetic interaction went well beyond simple “usability” - whether a task is easy or efficient to perform - and that too much of interaction design, especially in the digital realm, focuses on usability to the exclusion of other factors. As Kolko writes in his essay,

“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. 

How to get customers not to opt out of your e-mails

Today, I made an important decision for the benefit of my sanity and mental wellbeing.

I decided, after receiving my third marketing e-mail from a random company instead of the important e-mails I've been waiting for, that it was finally time to opt out.

That's right. Today, I'm opting out of every single marketing e-mail that I receive. And I think that you should, too.

There's a good chance that I'll catch a bit of hell for this. After all, I have been a member of the sustainable design and "green" marketing community for a while, and the green marketing community loves to recommend the e-mail newsletter. As does the SEO community, and the folks who tell you that social media is all about providing "useful content" to your audience.

I'm not saying those folks are wrong. I'm saying that it's really easy to step over the line from "wow, this is useful!" to "damn, this is annoying." And many marketers, especially from bigger brands, cross over that line repeatedly. For example, during the unsubscribe process, I discovered that AAA had me signed up for no less than seven e-mail lists. Citrix (who makes GoToWebinar and other products) had me signed up for eight. I have no recollection of signing up for any of these lists, and the couple of lists I did sign myself up for (DailyOm, Self Magazine), send me 2-3 e-mails daily that end up in my trash bin.

So, let's say you are a marketer, and you do want to send an e-mail newsletter? How do you make sure that you don't end up with a bunch of fed up customers unsubscribing from your list? Here's a couple of things I noticed about the e-mails that I actually read:

1. They're personal. Not necessarily personal as in directed towards me, but personal as in they share something of the person I'm getting it from.

2. They're occasional. My friend Colleen, the Communicatrix, sends her newsletter maybe once a month. It's a long one, but always entertaining, and always has some interesting perspective on life, business, and Everything. If I got this every week, I'd probably get overwhelmed (as would she!), but once a month or so it's nice and digestible.

3. If they come more than once a month, they're mercifully short. Let's face it. We're all busy folks. Who has the time to read a weekly, or even daily, e-mail? As a small business, who has time to write that? If you do want to send something more than once a month, try doing 2-3 times a month at most, and keep it short. Marketing Mentor's newsletter has been a staple in my inbox for years now, and it's because she keeps it short, focused and useful.

4. They involve things I actually want to read about or see. This is where subjective preference comes in. As much of a yogi as I am, I find Gaiam's products expensive and rarely worth the price (and the constant spam, both digital and paper, has been a hot button for me for a while now). But Modcloth can send me as many e-mails about clothing specials as it wants to. I may not buy anything, but I always have a moment to ogle retro-inspired dresses.

While you can't control all of the responses that your users have to a campaign, there are some things you can control. Keep it short, relevant and occasional. Most of all, show respect for people's time and energy. There's a lot of information out there, and the last thing you want to do is contribute to the overload.

Article first published as How to Prevent Customers from Opting Out of Your E-Mails on Technorati.

On Making

This week, as I was sitting down for a chat with Jeff Freedman, founder of Small Army, he asked me one of the most interesting questions I've heard in a while. We had been talking about the agency's unique approach to advertising, and the challenges inherent in getting clients and designers to think beyond features, benefits and pictures and into the story behind what we're doing. I shared my experience as a theatre major in high school and college, and how that shaped my approach to design and collaboration - and the ways I used that experience to help clients make that shift in thinking.

Then he asked, "What do you like more - the art, or working with clients?"

My instant answer was, "Depends on the day, really." I followed up with a couple of clarifying thoughts, but I don't know that any of them really pinned down what I love about what I do. What I really love is the act of making. How I make depends on the day, and what I'm making.

Some days, I'm taking a deep dive into code, or working with a client to evolve their web strategy. Other days, I'm playing with colored pencils and bookmaking supplies. Still others, I'm helping a client think through their business's vision so we can figure out how to communicate it. It all feeds the same thing - helping someone make something that's worth making.

What's been interesting to observe, particularly in the last few months, is how often the methods I use for making shift - and how important it is to let them shift.

Right now, I'm on a letterpress and bookmaking kick; the sheer physicality of it appeals to me, as does the notion of taking raw/found materials (metal type, paper, etc.) and turning them into something beautiful. But I'm also thinking through a strategy for upgrading the zen kitchen's site to Drupal 7, and restructuring the content to make up for 6 years of throwing way too much into it.

Both of these things require a very different set of skills, but there are certain commonalities. Both need a certain amount of careful planning up front, but they also need room for things to "just happen." There's also a heavy amount of craft in both. While bookmaking is much closer to what you'd commonly think of as "crafting," working with Drupal, and the web in general, requires an intense level of craftsmanship to do it well. With the push towards HTML5, and the increasing prevalence of the mobile web, the need for craft in web design will only intensify.

So yes. Short answer: what I love depends on the day. Slightly longer answer: what I love is the act of making - how I make depends on what I'm making, but it all feeds the love.

By the way, I've been uploading some of my letterpress and bookmaking fun on Flickr. You should check it out if you're interested.

Pages

Subscribe to Blog