Category: design

Dec 09

Five UX Research Pitfalls

I wrote this for UX Mag a while ago and it remains one of my all-time favorite writing projects. However, I never posted it in its entirety on my blog so here it is now. Enjoy!

More and more organizations view UX as a key contributor to successful products, connecting teams with end-users and guiding product innovation within the organization. Though it’s fantastic to see this transition happen, there are growing pains associated with becoming a user-driven organization. These are the pitfalls that I see organizations grappling with most often.

Pitfall 1: It’s easier to evaluate a completed, pixel-perfect product so new products don’t get vetted or tested until they’re nearly out the door.

Months into a development cycle and just days before the release date, you realize that the UI has serious flaws or missing logic. If you’re lucky, there is enough flexibility in the schedule to allow grumbling engineers to re-architect the product. More likely, though, the PM will push to meet the original deadline with the intent to fix the UI issues later. However, “later” rarely happens. Regardless, everyone wonders: how could these issues have been caught earlier?

The UI is typically built after the essential architectural elements are in place and it can be hard to test unreleased products with users until the very last moment. However, you can gather feedback early in the process:

  • Don’t describe the product and ask users if they would use it. In this case, you are more likely testing your sales pitch rather than the idea itself. If you ask users if they want a new feature, 90% of the time they’ll say yes.
  • Test with the users you want, not the users you already have. If you want to grow your audience with a new product, you should recruit users outside your current community.
  • Validate that the problem you are solving actually exists. Early in the design cycle, find your future users and research whether your product will solve their real-world problems. Look for places where users are overcoming a problem via work-around solutions (e.g., emailing links to themselves to keep an archive of favorite sites) or other ineffective practices (e.g., storing credentials in a text file because they can’t remember their online usernames and passwords).
  • Verify your mental models. Make sure that the way you think about the product is the same as your user. For instance, if you’ve been pitching your product idea to your coworkers as “conversational email” but your actual users are teenagers who primarily use text messaging, then your email metaphor probably won’t translate to your younger users. Even if you don’t intend to say “conversational email” in your product, you will unconsciously make subtle design choices that will limit your product’s success until you find a mental model that fits that of your users, not of your coworkers.
  • Prototype early. Create a Flash or patched-together prototype internally as soon as possible. Even if your prototype doesn’t resemble a finished product, you’ll uncover and develop confidence in the major issues to wrestle down in the design process. You’ll also have an easier time seeing the areas of the product that need animations or on-the-fly suggestions which often go unscoped when the product is only explored in wireframes and design specs but can require significant engineering time.
  • Plan through v2. If you intend to launch a product with minimal vetting or testing, make sure you’ve written down and talked about what you intend for the subsequent version. One of the downsides of the “release early, release often” philosophy is that it’s easy to get distracted or discouraged if your beta product doesn’t immediately succeed. Or upon launch you might find your users pulling you in a direction you hadn’t intended because the product wasn’t fully fleshed out or dealing with weeks of bug-fixing and losing sight of the big picture. Once the first version is out the door, keep your team focused on the big picture and dedicated to that second version.

Pitfall 2: Users click on things that are different, not always things they like. Curious trial users skew the usage statistics for a new feature.

Upon adding a “Join now!” button to your site, you cheer when you see an unprecedented 35% click-through rate. Weeks later, registration rates are abysmal and you have to reset expectations with crestfallen teams. So you experiment with the appearance of your “Join now!” button by changing its color from orange to green, and your click rates shoot up again. But a few days later, your green button is again performing at an all-time low.

It’s easy for an initial number spike to obscure a serious issue. Launching a new feature into an existing product is especially nerve-wracking because you only have one chance to make a good first impression. If your users don’t like it the first time, they likely won’t try it again and you’ve squandered your best opportunity. Continuously making changes to artificially boost numbers leads to feature-blindness and distrustful users. Given all of this, how and when can you determine if a product is successful?

  • Instrument the entire product flow. Don’t log just one number. If you’re adding a new feature, you most likely want to know at least three stats: 1) what percentage of your users click on the feature, 2) what percentage complete the action, and 3) what percentage repeat the action again on a different day. By logging the smaller steps in your product flow, you can trace the usage statistics within all of these points to look for significant drop-offs.
  • Test in sub-communities. If you are launching a significant new feature, launch the feature in another country or in a small bucket and monitor your stats before launching more widely.
  • Dark-launch features. If you are worried that your feature could impact site performance, launch the feature silently without any visible UI and look for changes in uniques, visit times, or reports of users complaining about a slow site. You’ll minimize the number of issues you might have to potentially debug upon the actual launch.
  • Anticipate a rest period. Don’t promise statistics the day after a release. You’ll most likely want to see a week of usage before your numbers begin leveling.
  • Test the discoverability of your real estate. Most pieces of your UI will have certain natural discoverability rates. For instance, consider adding a new temporarily link to your menu header for a very small percentage of your users just to understand the discoverability rates for different parts of your UI. You can use these numbers as a baseline for evaluating future features.

Pitfall 3: Users give conflicting feedback.

You are running a usability study and evaluating whether users prefer to delete album pictures using a delete keystroke, a remove button, a drag-to-trash gesture, or a right-click context menu. After testing a dozen participants, your results are split among all four potential solutions. Maybe you should just recommend implementing all of them?

It’s unrealistic to expect users to understand the full context of our design decisions. A user might suggest adding “Apply” and “Save” buttons to a font preference dialog. However, you might know that an instant-effect dialog where the settings are applied immediately without clicking a button or dismissing the dialog allows the user to preview their font changes immediately and saves the user from opening up the dialog repeatedly to make small font style tweaks. With user research, it’s temptingly easy to create surveys or design our experiments so study participants simply vote on what they perceive as the right solution. However, the user is giving you data, not an expert opinion. If you interpret user feedback at face value, you typically end up with a split vote and little data to make an informed decision.

  • Ask why. Asking users for their preference is not nearly as informative as asking users why they have a preference. Perhaps they are basing their opinion upon a real-world situation that you don’t think is applicable to the majority of your users (e.g., “I like this new mouse preference option because I live next to a train track and my mouse shakes and wakes up my screen saver”).
  • Develop your organization’s sense of UI values. Know what UI paradigms (e.g. Mac vs. Windows, Web vs. Desktop, etc) and UI values (e.g. strong defaults or lots of customization, transparency or progressive disclosure) your team values. When you need to decipher conflicting data, you’ll have this list for guidance.
  • Make a judgment call. It’s not often helpful to users to have multiple forms of the same UI. In most cases it adds ambiguity or compensates for a poorly designed UI. When the user feedback is conflicting, you have to make a judgment call based upon what you know about the product and what you think makes sense for the user. Only in rare cases will all users have the same feedback or opinion in a research study. Making intelligent recommendations based upon conflicting data is what you are paid to do.
  • Don’t aim for the middle ground. If you have a legitimate case for building multiple implementations of the same UI (e.g., language differences, accessibility, corporate vs. consumer backgrounds, etc.), don’t fabricate a hodgepodge persona (”Everyone speaks a little bit of English!”). Instead, do your best to dynamically detect the type of user situation upfront, automate your UI for that user, and offer your user an easy way to switch.

Pitfall 4: Any data is better than no data, right?

You are debating whether to put a search box at the top or the bottom of a content section. While talking about the issue over lunch, your BD buddy suggests that you try making the top search box “Search across the Web” and the bottom search box “Search this article” to compare the results between the two. You can’t seem to place your finger on why this idea seems fishy though you can see why this would be more efficient than getting your rusty A/B testing system up and running again. Sensing your skepticism, your teammate adds, “I know it’s not perfect, but we’ll learn something about search boxes, right? I don’t see a reason not to put it in the next release if it’s easy?”

The human mind’s ability to fabricate stories to fill in the gaps in one’s knowledge is absolutely astounding. Given two or three data points, our minds can construct an alternate reality in which all of those data points make flawless sense. Whether it’s an A/B test, a usability study, or a survey, if your exploration provides limited or skewed results, you’ll most likely end up in a meeting room discussing everyone’s different interpretations of the data. This meeting won’t be productive and you’ll either agree with the most persuasive viewpoint or you’ll realize that you need a follow-up study to reconcile the potential interpretations of your study.

  • Push for requirements. When talking with your colleagues, try to figure out what you are trying to learn. What is the success metric you’re looking for? What will the numbers actually tell you? What are the different scenarios? This will help you determine the study you should run while also anticipating future interpretations of the data before running the study (e.g., if the top search bar performs better, did you learn that the top placement is better or just that users look for site search in the upper left area of a page?).
  • Recognize when a proposed solution is actually a problem statement. Sometimes someone will propose an idea that doesn’t seem to make sense. While your initial reaction may be to be defensive or to point out the flaws in the proposed A/B study, you should consider that your buddy is responding to something outside your view and that you don’t have all of the data. In this scenario, perhaps your teammate is proposing running the search box study because he has a meeting early next week and needs to work on a quicker timeline. From his perspective, he’s being polite by leading with a suggestion without realizing that you don’t have the context for his suggestion. However, after pushing him for what problem the above study will resolve, you can also help him think through alternative ways of getting the data he needs faster.
  • Avoid using UX to resolve debates. UX might seem like a fantastic way to avoid personal confrontation (especially with managers and execs!). After all, it’s far easier to debate UX results rather than personal viewpoints. However, data is rarely as definitive as we’d like. Conducting needless studies runs the risk of slowing down your execution speed and perhaps leaving deeper philosophical issues unresolved that will probably resurface again. Sometimes we agree to a study because we aren’t thinking fast enough to weigh the pros and cons of the approach, and it seems easier to simply agree. However, you do have the option of occasionally saying, “You’ve raised some really good points. I’d like to spend a few hours researching this issue more before we commit to this study. Can we talk in a few hours?” And when you do ask for this time, be absolutely certain to proactively follow-up with some alternative proposals or questions, not just reasons why you think it won’t work. You should approach your next conversation with, “I think we can apply previous research to this problem,” or “Thinking about this more, I realized I didn’t understand why it was strategically important to focus on this branding element. Can you walk me through your thinking?” or “After today’s conversation, I realized that we were both trying to decrease churn but in different ways. If we do this study, I think we’re going to be overlooking the more serious issue, which is…”

Pitfall 5: By human nature, you trust the numbers going in the right direction and distrust the numbers going in the wrong direction.

Hours after a release, you hear the PM shout, “Look! Our error rates just decreased from .5% to .0001%. Way to go engineering team! Huh, but our registration numbers are down. Are we sure we’re logging that right?”

Even with well-maintained scripts, the most talented stats team, and the best intentions, your usage statistics will never be 100% accurate. Because double-checking every number is unrealistic, you naturally tend to optimize along two paths: 1) distrust the numbers that are going in the wrong direction and, more dangerously, 2) trust the numbers that are heading in the right direction. To make matters worse, data logging is amazingly error-prone. If you spot a significant change in a newly introduced user activity metric, 9 times out of 10 it’s due to a bug rather than a meaningful behavior. As a result, five minutes of logging can result in five days of data analyzing, fixing, and verifying.

  • Hold off on the champagne. Everyone wants to be the first to relay good news so it’s hard to resist saying, “We’re still verifying things and it’s really early, but I think registration numbers went up ten-fold in the last release!” Train yourself to be skeptical and to sanity-check the good news and the bad news.
  • QA your logging numbers. Data logging typically gets inserted when the code is about to be frozen. Since data logging shouldn’t interfere with the user experience, it tends not to be tested. Write test cases for your important data logging numbers and include testing them in the QA process.
  • Establish a crisp data vocabulary. Engagement, activity, and session can mean entirely different things between teams. Make sure that your data gatekeeper has made it clear how numbers are calculated on your dashboards to help avoid false alarms or overlooked issues.

One of the main tenets of user research is to constantly test the assumptions that we develop from working on a product on a daily basis. It takes time to develop the skills to know how to apply our UX techniques, when our professional expertise should trump the user’s voice, or when to distrust user data. As a researcher, you are trained to keep an open mind and to keep asking questions until you understand the user’s entire mental picture. However, it’s that same open-mindedness and willingness to understand the user’s perspective that makes it easy to assume that because their perspective can make sense, that it should also justify changes within our product design. Or, because we are so comfortable with a particular type of UX research, we tend to over-apply it to our team’s questions.

While by no means a complete list, I hope these five pitfalls from my personal experience will be relevant to your professional lives and perhaps, provide some food for thought as we all strive to become better researchers and designers.

 

December 9th, 2012 · · design, entrepreneurship 4 comments
Mar 08

why the symphony needs a progress bar

(photo courtesy of Santa Barbara Choral Society)

About three years ago, my work-life balance started to improve – start-up sleep deprivation was no longer a constant norm. I didn’t have enough time to restart violin lessons but season tickets to the San Francisco Symphony? Yup, I could swing that.

I bought tickets for myself and my husband, Todd, a relatively new concert-goer. But after a few shaky experiences, I was worried that Todd would back out of a subsequent season subscription. I started doing anything I could to avoid the, “Oh my god – is this only the first movement?” mid-concert terror. Seeing the experience from a newbie’s perspective, my UX instincts kicked in and I started jotting down the, “If only the symphony had…” moments. Three years later, here’s my list:

If Only the Symphony Had…

1. A Progress Bar

Even the most devout classical music listener has, “OMG is this over yet?” moments. When you’re not responding to a performance, the experience becomes torturous if you don’t know whether you’ve endured 5% or 95% of the piece. A progress bar would make a world of difference. Nearly every other performance genre has accompanying scoreboards, screens, tickers, or subtitles to track the event’s progress. A JumboTron might be inappropriate but a few progress lights on the conductor’s podium would really help.

MTT Talks

2. People Who Talk

Half of the fun of following a sports team is getting to know the players. At the symphony, you regularly have a two-hour experience with over a hundred performers with absolutely no words exchanged. I love encores because the artist announces the piece they are about to play and I can suddenly match a voice to a performer. Then they become real. I’d love for the conductor or soloist to provide a 3-4 sentence introduction, “Thank you for joining us this evening. Tonight we will be performing…” It’s only natural that the audience feels more engaged when they hear a performer’s voice. In the three years I’ve attended the San Francisco Symphony, I’ve never heard Michael Tilson Thomas talk!

quiet candy

3. Quiet Candy

The symphony season is almost perfectly aligned with head cold season – fall through spring. No one wants to cough during a performance but when that annoying tickle happens, you can only hold your breath and writhe in agony. I’m sure Ms. Stewart would endorse a hospitable offering of wax paper-wrapped candy in the entryway as both a welcoming gesture and a potential quick-fix to hold you over until you can make a mad dash to the water fountain.

4. A tl;dr opener

My typical symphony experience started with leaving Meebo a little early without dinner and finding myself starving in a 101-N traffic jam with a spouse who is thinking, “Wait a second, if we miss the symphony, we can skip the concert and get pizza instead!” We have never missed a performance but we sprinted from the parking lot on a few occasions. With seconds to spare, I’d see Todd crack open his program to find a dense Ph.D. thesis on the first piece. Two-three sentences in, the lights would dim and suddenly Todd was grasping his dark, useless program notes with no idea of what he was listening to.

Here’s a San Francisco Symphony program written for Messiaen’s Oiseaux Exotiques (click to read the 11-page version):

In all of the 2,000 words, the title, “Exotic Birds”, is never translated! Assuming Todd made it through the first paragraph before the music began, he’d know the commissioner, dedication, and all of the locations and conductors who have played this piece of work since 1956. This is not helpful information for someone who is going to listen to Messiaen for the first time!

The first paragraph needs to be oriented to a 30-second, the-lights-are-dimming panic scan. Here’s what I wish preceded the lengthy write-up:

Oiseaux Exotiques (“Exotic birds”), 1956
Duration: 16 minutes (no movements)
Composer: Oliver Messiaen (1908-1992), France
Period: 20th century
Influences: Roman Catholicism, birds, colors, Japanese music, landscapes
Instruments: Piano and small orchestra
Listening notes: Forty-eight birdsongs are played throughout this piece. Messiaen was not familiar with American birds so many of the birdsongs such as the Cardinal, Wood Thrush, Prairie Chicken, Oriole, and Finch were exotic to his ear.

concert notes

5. Program notes on the fold

While I’m harping about program notes, I’ll also mention a personal pet peeve. I dread the moment when I accidentally close my program and realize that I’ve lost the position to the concert notes. I’ll need to carefully open and flip through pages to locate the notes again without squeaking a chair or elbowing my neighbor. I know that it might make economical sense to bury the program notes amidst diamond cocktail ring advertisements but I’d really appreciate a program that naturally falls open to the concert details. If the advertising dollars can’t be missed, then offer a lightweight $.99 iPhone app that has white-on-black text (to avoid glowing screens) that can be flicked in the dark.

6. Programming for beginners

When you launch a new product, you inevitably have a few crazy, very vocal early adopters (why don’t you support Opera’s browser yet?) that you have to selectively ignore if you want a product that appeals to a wider audience. The symphony is the same. About half of the audience attends for a pleasant symphony-going experience. A small minority will be hard-core educated symphony folks who needle, “Why haven’t we heard more atonal music by post-Ján Valašťan Dolinský Slavic composers this season?” The remainder are the musically tepid spouses and children who have been dragged to the hall and are just trying to stay awake and to clap at the right times.

To sustain the symphony, there needs to be beginner programming at every concert – even if it’s just a 3-minute warm-up to perk up newbie ears with a, “Oooh – I’ve heard of this!” moment. Pre-concert talks are fantastic but I’m battling hectic schedules and a seatmate who (though he’d graciously never admit it) probably wants to spend less, not more, time at the symphony. However, it’s these seat-mates who determine whether I repurchase symphony season tickets and who will probably determine whether the symphony thrives longterm.

I can imagine that in two hundred years people will attend rock concerts performed by historical cover bands and wonder, “Why do they require that we stand for the entire concert?” Or, “If the concert really begins at 11pm, why do they print 10pm on the tickets?” The symphony was intended for entertainment and our rigid adherence to its nineteenth century form has made it increasingly difficult to appreciate. A progress bar is long overdue!

March 8th, 2012 · · design, life, music 11 comments
Feb 16

armed and dangerous in silicon valley

Last weekend I took an Adobe InDesign course at BAVC and was surrounded by Sales & Marketing start-up folks taking classes so they didn’t have to bother their busy design and engineering teams with small requests. I had to restrain myself from recruiting every single one of them (especially the one who brought donuts in the morning).

Becoming armed and dangerous in Silicon Valley is easier than most people realize. There are amazing tech classes in the Bay Area that don’t require technical degrees or taking a sabbatical – they are just a little hard to find:

  1. BAVC – offers an exhaustive selection of video production courses as well as Adobe, HTML, CSS, JavaScript, Flash, color, and typography workshops. If you’re a start-up, you might even qualify to take classes for free.
  2. TechShop – offers electronics, machining, and other workshop classes. Right now, Autodesk provides Autodesk Inventor workshops for free (for members). Or prototype that electric gizmo you’ve been dreaming about with the Arduino series. The TechShop’s laser cutting and etching course is far and away their most popular course. The TechShop also has three locations in San Francisco, Menlo Park, and Mountain View.
  3. Stanford Continuing Studies – offers nearly everything from language development, liberal arts courses, writing workshops, lecture series, to professional development. The Personal & Professional Development Series offers financing, leadership, PHP, entrepreneurial, public speaking, and Web design courses. I took a public speaking course with Matt Abrahams. The writing workshops are also highly regarded. It’s also worth mentioning that many of the Art and Archaeology instructors offer international trips to excavate or study art in-person.
  4. UC Berkeley Extension – offers back-end computer science courses such as System Administration and Networking as well as front-end classes like Web development and graphic design. Some classes are available online.
  5. California College of the Arts – offers Web and graphic design classes such as Adobe Creative Suite bootcamps plus other hard-to-find courses such as creating interactive ePubs for your iPad, Cocoa Touch programming, or a how to use a Wacom tablet.
  6. BioCurious – this up-and-coming Biotech workspace in Sunnyvale offers a complete working laboratory. Learn how to do genome sequencing and cloning with their weekend workshops and then start your own genomic experiment – no prerequisite experience necessary!
  7. SFSU Extension – SFSU’s quarterly programming and design classes include jQuery, HTML5, Mobile UI design, ActionScript, and WordPress. Many of the classes are available in weekend workshops.
  8. Digital Media Playground – teaches digital photography and video production so you’ll no longer feel guilty about carrying around a camera you don’t know how to use. It’s also one of the few places that regularly teaches food photography.
  9. The Crucible – prep for Burning Man in no time. These friendly folks offer every Industrial Arts class you can dream of including welding, hula hooping with fire, neon sign making, blacksmithing, and electronics.

If someone’s snickered at your purple comic sans e-mail signature, consider a typography classes. If you are a Project or Product Manager who isn’t totally fluent in geekspeak, look at the Berkeley, SFSU, and Stanford computer science courses. If you are a Sales or Marketing professional who wants to tweak brochures for conferences or start a company blog, take a WordPress, HTML, Photoshop, or InDesign classes. And if you’re a hardcore computer geek, maybe you crave working with something tangible – you’ll love the TechShop and Crucible.

Enjoy!
-Elaine

February 16th, 2012 · · design, tech 4 comments
Jan 01

News Round-Up

Todd and I had two holidays goals that couldn’t be more different. After a month of late nights at the chocolate factory, Todd wanted to zone out on a beach. However, beach chairs make me twitchy. We ended up relaxing on Vieques Island during the day and then kayaking around the BioBay at night – perfect. I charged my mobile batteries to 100% before donning flip flops and then headed to the beach where Todd plugged in his headphones and got to his sunny meditation. Occasionally, the beach surf sounds were interrupted by Todd’s iPhone buzz. He’d pull his iPhone out of his pocket only to say, “Wait a second… this email is from you!” as I’d just sent him all of the news articles that I thought he was missing. Needless to say I had a lot of reading time this week. Here are some of the interesting articles I want to share for anyone interested. Happy reading!

1. The Touchy-Feely Future of Technology (NPR)

If you haven’t heard of Bill Buxton, read the above. And then, head over to see all of Buxton’s papers and research here: Bill Buxton Papers. Buxton is one of the most prolific HCI researchers out there and has been a pivotal figure since the 80’s. Looking through his research is like looking into the future and waiting for technology to catch up.

2. What Does Your Brand Say About You (Washington Post)

A brand is more than Marketing veneer. It’s felt throughout the entire culture and operation.

  • Long lines = “They don’t care about my time”
  • Rush off the phone = “They rush product dev too”
  • Strict policies = “Inflexible”
  • Outdated website = “Outdated ideas”
  • Unexciting messaging = “Boring product”

3. Volkswagen Silences Work Email After Hours (Washington Post)

To help employees maintain a better work/life balance, Volkswagen and others have agreed to stop sending company emails outside work hours.

I love this. There are definitely people who handle their email best at midnight or 5am which means that it’s inevitable that some unlucky recipient is going to feel stressed before falling to sleep or while getting ready to head out the door. Most of the time an email isn’t even that stressful in the longrun but receiving the email in a setting where you can’t do anything immediately makes it worse. There are always exceptions but I love the idea of preventing email after normal work hours so team members can officially decompress out of the office.

4. Online Shopping: Better for the Environment? (LA Times)

Whew – I feel a tinge better about ordering my recent fix of gummy bears via Amazon prime now. Just make sure you recycle the box.

5. Outsourcing Resolutions (WSJ)

“Having someone you love tell you how to become a better person could be terrifying… Who better to tell us how to improve than someone who knows us well?”

Years ago, Todd floored me when November 1st rolled around and he said, “It’s November? I only have 60 more days to complete my resolutions!” I’ve kept New Years resolutions ever since. This year, inspired by this article, we wrote each other’s New Years resolutions to share on December 31st. Then, I decided I wanted to jot down what I would have said for my own New Years resolutions to compare with Todd. It resulted in good dialogue and further goal refinement.

In the end, I realized that this is how performance reviews and personal annual goals should feel. A boss/mentor/trusted peer thinks about their three goals for you based upon their perspective, you come up with your three, and then there’s a conversation to reconcile and brainstorm together. Which leads me to the next article…

6. Everything That’s Wrong with Performance Reviews (Washington Post)

Performance reviews fail because they are heavy-handed, bureaucratic, and a “dysfunctional pretense” that is an obstacle to having a real conversation. (Also see WSJ’s Get Rid of the Performance Review from 2008). By pairing performance reviews with pay, the employee thinks their review determines their pay when it is likely governed more by the market and internal budgets. In addition, performance reviews reinforce the manager and subordinate relationship and focus on past mistakes instead of planning for performance in the future.

7. How To Have a Tough Conversation (Chicago Tribune)

Just a few good tips on having hard conversations: reverse your thinking, help the conversation feel safe, define goals for conversation. It’s intended for the professional setting but I probably need it most for coping with phone chains. AT&T and airlines customer service bring out the very worst in me. If they can’t locate my lost luggage or understand my issue within five minutes, oh! my blood boils!

8. Haters Are Going To Hate This Story (NPR)

Quick rundown of haters online and in music including, “if you have haters, you’re doing something right” and advocating for a “don’t like” button.

9. Creating Magic Moments for Customers (Washington Post)

Craft the story you want users to tell that differentiates you from your competitors. Unexpected + delight = magic.

January 1st, 2012 · · design, tech No comments
Mar 04

design survey for south by southwest

I’m preparing for a South by Southwest panel I’m moderating next week: Design across Disciplines (March 12th at 3:30). We’ll be comparing the creative processes and design guidelines across different design disciplines (speech writing, architecture, event planning, to interaction design) to see what Interaction Design can learn from other fields. I’m joined by four brilliant designers including: Matthew Robbins, Ben Yarrow, Brett Lider, and Stephen Atkinson.

I originally wrote the survey just for the five panelists. But if you are a speech writer, architect, event planner, interaction designer, or from another creative field, feel free to participate in our creative process survey. It’s a short five-minute survey (via Zoomerang). It’s not especially scientific but I’m happy to share the results later and I’m sure it will lead to some interesting discussions next Saturday!

Creative Process Survey

Thanks!

March 4th, 2011 · · design No comments
Sep 02

a design book recommendation in tomato season

When I was in senior in college, I grew tomato plants illegally from our dorm roof by climbing out the window to step to a small row of potted cherry tomatoes just out of sight. A few months later, I graduated and moved the tomatoes to my first apartment’s tiny balcony space. However, now the tomatoes were clearly in sight and the hodgepodge of plastic pots just weren’t cutting it. I headed to the nursery for a plant and pot upgrade.

I must have spent an awful amount of time deliberating over terra cotta. At some point, an observant sales person introduced herself and asked about my project. I said I wanted my balcony garden to look better. Expecting to be upsold to a premium glazed terra cotta, she instead said that my current approach was entirely wrong – my dozen pots were too small for the balcony. Instead, I should invest in one or two big, big pots. Then, I should focus on contrasting textures and colors such as pairing the pointy leaves of a yucca tree with a tall and round ceramic pot and spiky grasses.

The nursery assistant I met that day probably had decades and decades of container and landscape gardening experience and it showed in her clear-cut visual language. Since then, I’ve been surprised at how hard it is to find any resources that outline logical, systematic approaches for design evaluation — whether it’s in the garden, in art, or online.

But about six months ago, I stumbled across this book that did just that — attempted to move beyond vague, intuitive language such as “appealing” and “well-balanced” to a systematic, logical description of compositions like, “When two distinctly different objects are isolated from everything else and positioned side-by-side, the impulse to compare and contrast is almost an automatic reflex.”

Arranging Things: A Rhetoric of Object Placement by Leonard Koren is pretty niche (you probably guessed that by reading the title already). And the low Amazon ratings might scare you off a bit. However, after reading it a few months ago, I keep recommending it to product-oriented people I know and thinking about it when I’m looking at wires or mockups at Meebo. The exact premise for the book goes like this…

2,500 years ago, Greek politicians created systematic communication techniques such as style, memorability, and delivery to convey their message, get loyalty, and win votes. However, communication is not just limited to writing and speaking. Today’s florists, set designers, and visual merchandisers know that arrangements are not just about aesthetics, they are also communicating information through cultural references and symbolism (e.g. wilted flowers and rotting fruit convey deterioration, alcohol and desserts mean sensual indulgence). However, while communication has been a field of study for thousands and thousands of years, object arrangement remains a largely intuitive and untaught discipline today. Koren suggests that if arranging objects is tied to communication, then we should be able to leverage the previous knowledge and apply a tried-and-true rhetoric to object arrangement today.

Even if you aren’t entirely sold on the premise of object composition as a strong form of communication, the collection of still-life compositions is really amazing. I’m guessing that Koren spent years and years collecting the example compositions for the remaining two-thirds of his book. Each painted composition has a one-page analysis where Koren practices what he preaches — specifically dissecting each the object arrangement into eight dimensions such as metaphor, alignment, coherence, and hierarchy.

I recognize that this isn’t going to be a best-seller book any time soon, it’s not even fantastic bedside reading material. However, it is definitely one of my favorite resources on my design bookshelf and I think it is worth sharing, especially if you are working with a team of designers on a day-to-day basis.

September 2nd, 2010 · · design, life 2 comments
Apr 11

baroque trappings of today’s web applications

I had the unexpected opportunity to present at the February BayCHI event a few months ago. For a year, I’d been mulling on a presentation that is a mouthful to say, “What Web Applications can Learn from the Harpsichord.” It’s not the typical “What you should know about HTML5/CSS3/JavaScript” presentation and I knew I couldn’t assume it would ever find an appropriate audience. However, when Christian Crumlish asked me if I had anything I’d want to talk about at BayCHI, it felt like an extraordinary stroke of luck.

If you’re wondering how someone starts pairing harpsichords with web application design, it might help to know that I started playing the violin when I was five and continued playing throughout school. I don’t consider myself an expert in classical music (and my former music theory teacher would undoubtedly agree) but I do know that most classical music pieces can be categorized into one of about seven historical periods and that most household composer names come from the Baroque, Classical, and Romantic musical periods.

Interestingly, most of those musical period labels weren’t applied until the mid-19th century, after Beethoven’s death. It’s not often that musicians, designers, or architects have the foresight to declare the arrival of a new stylistic period. In reality, styles evolve more organically and it’s usually the duty of future historians to argue about these divisions.

Ten years ago, we talked about the Internet boom followed by the bubble. Five years ago, we started calling ourselves Web 2.0. Now we talk about social media. And in my head, I keep wondering whether these divisions will still be applicable in future Web Application Design museums hopefully 20-30 years away.

It was this thought process that led me to wonder what would happen if you compared the development of classical music with the evolution of today’s web applications. I’ve spent the last few weeks mulling on how to translate and visually represent this thought within a coherent blog post.

I’d like to propose that today’s web apps are stuck in a Baroque-like era and that by looking at the similarities between the evolution of classical music and web applications, we can break free of our Baroque trappings and progress forward to the next Internet period.

Before diving into the particulars of what a Baroque era looks like, here’s what I recall from my high school music theory classes up through the Romantic period with a few audio snippets. The most important take-away is to note the steps leading up to the Baroque music explosion fueled by public demand, an instrumental boom, and an abundance of musicians.

Classical Music between 400-1820
Medieval (400-1400)

Long period of research and development
A slow Medieval simmering of musical development primarily confined to the Church who develops the first handwritten musical notation system for Gregorian chant. Music generally consists of religious vocal chants.
Renaissance (1400-1600)
First craftsmen and instruments
The printing press makes it easier to reproduce music and instructional books for playing musical instruments. Instrumental music is no longer limited to just accompaniment and new demand develops to design instruments with a fuller range of sounds.
Baroque (1600-1750)
Mass adoption and experimentation
The Baroque period emphasizes broad experimentation with the goal of creating emotional impact through complexity, ornamentation, and textures. Baroque fugues (like Bach) and ornamented harpsichord music are characteristic compositions of this period. Formalized teaching methods arise to develop new musicians and composers.

Classical (1750-1820)
Restraint and principles, craft to art
The Classical period aims to understanding underlying order and hierarchy for compositions. Instead of the melody and harmony sharing an equal role, composers prefer a single, audible melody with a secondary harmony accompaniment.
Romantic (1820-1910)
Artistic maturity, full expression
Finally, the art form reaches full maturity in the Romantic era as more composers and musicians master how to flout Classical rules for the desired effect. More formalized compositional structures develop. The Romantic period achieves what the Baroque period sought out to do – achieve emotional impact through compositional grandeur. However, it needed the rules of the Classical period to do so.

 

With that background, here’s how the classical music timeline might parallel the development of the Internet.

Medieval – Long period of research and development
Music400-1400
Internet1940-1991
– In 400 AD, the Church is the only organization with the money and resources to support music
– In the 1970’s, the government, more specifically DARPA headquarters, is the only organization who can afford computing technology research for defense, not entertainment, purposes
– Like Medieival music was initially limited to religious devotion, the Medieval Internet was initially intended for military research
Renaissance – first craftsmen and instruments
Music1400-1600
Internet1991-2005
– During the Renaissance period, music development breaks away from the Church and as more Europeans are exposed to music, music-making becomes an industry craft. Similarly, the development of the Internet moves from academic and government institutions to predominantly industry in the 1990’s.
– Developing music becomes less expensive with the development of the printing press. Similarly, the lowering cost of personal computers provide the general public with a new opportunity to have a presence on the web. Venture capitalist fund a startup land grab.
Baroque – mass adoption and experimentation
Music1600-1750
Internet2005-current
– The Baroque musical period represents the longest and broadest period of musical experimentation in European musical history ever with an emphasis on exerting an overwhelming emotional impact through ornamentation, a texture of voices, and a variety of instrument ensembles. With the Internet, web applications see an explosion of pixel treatments, mashups, api’s, and social media widgets. In both cases, there’s a sense of doing things because you can, not necessarily because you should.
– In both genres, technology continues to develop and best practices are formalized.

 

Personally, when I listen to harpsichord music from the Baroque period, not too much time passes before I start to think, “I think this harpsichord piece is just trying to play as many notes as possible.” Similarly, after browsing the Internet for a bit today I start to think, “I’m not sure I can withstand another mashup, rounded corner, or headline announcing a breakthrough platform.”

It’s easy to think that today’s Internet baroque period is confined to the glossy Web 2.0 style. For instance, if I look at this personalized MySpace page with its glitter tags, purple background, widgets, and musical embeds, it’s hard to argue that it doesn’t have Baroque leanings. It’s not so dissimilar from this 1777 Baroque San Cristobal Cathedral where the emphasis is on the amount of ornamentation, materials, and architectural techniques for emotional effect.

However, you see the same types of mashups happening at the UI level. Consider this Amazon.com book previewing UI. In this image, you’ll see a modal litebox preview with a drop-down menu (with expandable accordions) that can be dismissed by an ‘X’ close button. All of this is encapsulated with a next/previous photo viewer. And judging by the buttons at top, you can zoom too. I’m really not sure what to expect when I click on the “Expanded View” option in the top right-hand corner.

How many more interactive elements can we fit within this UI? This montage is fairly daunting considering this UI’s primary intent is just to flip the page of a book.

In the musical Baroque period, the emphasis shifted from developing instruments to developing ensembles like the Opera and string quartet. The ultimate Internet homepage was a very Baroque endeavor that aimed to create the best one-stop-shop with stock quotes, feeds, and personalized services though not necessarily doing any one individual service particularly well.

Now, the focus has evolved from ultimate homepages to social media integrations with the aim of making sharing and communicating easier. When you click on a sharing service in your favorite news site, it’s dizzying to watch your browser load a zillion icons to display the matrix of services eager to announce you’ve read (and perhaps liked) an article. It’s amazing that copying and pasting an article is still such an attractive alternative to most of these services. Again, just because you can connect with all of these services, does that mean you should?

So where do we go from here? Personally, I want to live to see the Classical and hopefully the Romantic phase of web application design. I hope that our craft will continue to evolve and that with enough Baroque trial and learning, we will develop enough confidence to exercise restraint and present more compelling experiences to our users.

April 11th, 2010 · · design, music, tech 5 comments
Jan 18

an ethnographic analysis of ux professionals

As a manager, you strive to see 6-12 months beyond what your team is currently working on. In addition to roadmaps, you’re also thinking about aligning projects with their professional careers. A while ago, I wanted to make sure that I was doing a service to our Meebo UX team and that I understood what career paths looked like for designers (it was also around annual review time). I started initiating coffee conversations with any design professional my schedule could withstand (it doesn’t hurt that Red Rock Coffee is just around the corner). And truthfully, I love talking about Web application design so it was a treat to break outside the technical community and meet people that I probably should have known years ago.

My take-away after 40-60 hours of caffeinated conversations is probably a bit controversial but here it goes. I would posit that:

UX professionals are some of the most professionally unhappy folks I’ve ever encountered.

Before reactionary sparks fly, I should clarify that professional unhappiness is very different than emotional happiness. Despite my upbeat and engaging conversations, it was clear that designers have fewer growth opportunities and are less valued than their engineering counterparts. If you are currently a UX professional, it’s pretty likely you work in one of these types of organizations:

“Just make it pretty“: This is the easiest organization to identify. This organization equates design with pixel eye candy. Design is the varnish that pulls everything together. Since you are the last one to touch a product, your influence is more limited, and your hours get squeezed when the engineering schedule slips. This type of organization could have contracted out its design service but perhaps it was more economical to have someone like yourself in-house. Hopefully, you’ve found yourself designing an amazing product with a team you love. However, it may be more difficult to see growth opportunities in the near future (especially outside of visual design). Or you may find yourself constantly trying to prove that it makes strategic sense to include UX earlier in the development cycle. Regardless, at some point you’ll have enough confidence and work in your portfolio to head to the next type of organization…

“A Tried-and-True Monolith” Most of the largest consumer-oriented design teams in Silicon Valley were founded by engineers 10-15 years ago. At the time, HCI was just emerging as a respected industry discipline. It wasn’t until a few years after the company’s inception that the respective UX teams were inserted into the organization, well after the DNA of that company’s organizational structure and values were solidified. A decade later, these companies have the resources and millions of end-users to do amazing things. It’s a fantastic place to gain perspective and seasoning, especially in a contributor role.

However, a professional ceiling appears once someone progresses from a contributor to a lead role. To be a good leader, you need to create strategic goals to align your teams. However, there is no VP or C-level UX role at the head of these organizations. UX is frequently aligned with pre-existing Marketing or Engineering teams and as a result, there’s no place to grow strategically. As a manager or principal, you might find yourself in a lot of meetings saying, “My job is just to offer the existing data and my interpretation. It’s up to <other team> to incorporate it.” Perhaps you even create a UX board of advisors to counteract the non-UX organizational structure. However, after enough meetings, you start to realize that as much as you wish it weren’t so, UX still feels like a service instead of a strategic voice.

After a few years, you’ll most likely have the resume (maybe even a book!), professional network, and product breadth to turn to consulting where your contracting relationship presupposes that your client values what you are doing. Even though you might not be part of a long-term project or enjoy daily team camaraderie, at least your years of experience are appreciated. You might stay in consulting; you might satisfy your entrepreneurial itch to do your own start-up. Or you might find yourself craving stability but within a team that values UX. In which case, you could find yourself here…

“Team of UX Workhorses”: This UX team is building user scenarios, wire-framing, placing metrics on decisions, and participating in all levels of the development cycle. It sounds like Silicon Valley heaven. However, when the UX team is strong and talented, there is a tendency for non-UX teams to misuse its UX resources. Instead of resolving a decision at a meeting, someone might propose, “Let’s A/B test it!” and after the meeting, the UX team is off and running. Should we go with a 2-step or 3-step registration process? “Let’s run it through usability!” and now days are lost to scheduling and moderation. Someone have a new idea that just might work? “Let’s ask our ID team to spend a week or two creating new wires!”

Execs love the ability to go so quickly from idea to exploration. However, the exploration just leads to more data collection which, in turn, postpones critical thinking and decision-making. Soon, projects are canceled unexpectedly, other teams are complaining that their projects aren’t getting attention from your overtaxed UX team, and it’s hard to make gigantic strides forward when your designs are hung up in A/B testing micro-steps. Not only are you getting discouraged that only 20% of your projects see the light of day, it is especially disheartening that design issues are resolved through usability participants and other team members inaccurately interpreting data. You were hired for your expertise, it’s incredibly clear that the right answer is “the blue button,” and you can’t figure out why no one trusts you to make a call.

Experienced folks who suggest eliminating UX cycles are deemed illogical (why wouldn’t you do A/B testing?). Junior designers might suspect that an idea isn’t worth exploring but feel compelled to push forward in case perhaps the idea is good, but their creativity is lacking. Without an exec or a process to keep everything in check, the team is constantly spinning and being accused of not being strategic because their efforts are difficult to map to the bottom line.

But from my conversations, it certainly wasn’t all bad news. Almost everyone was optimistic that things were getting better. The stereotype of UX teams comprised of unapproachable design divas is being replaced by the concept of well-rounded teams that successfully partner business expectations with end-user experiences. Ten years ago, it was difficult to find someone seasoned who could step into a Director/VP of UX role. However, through my coffees alone, I met several professionals with many, many more years of experience than I have who would bring amazing perspective to a willing organization. Finally, the organizational placement of UX professionals is becoming more clear. UX folks want to be close to the action. They think about the UI and want to be beside the people who build the UI – the engineers. And finally, I’m especially excited about the somewhat controversial conversations popping up about UX hybrids and how that can influence team dynamics.

I’m still compiling my notes on UX hybridization… but more on that later.

January 18th, 2010 · · design, tech 19 comments