UX Boston -- I'm Speaking June 26

The newly created UX Boston group is having their first meeting. I've been asked to give my talk on designing online community; I'll be updating it with a few more concrete examples of interaction design for community and sample metrics.

WHAT?

UX Boston Kick-Off Meeting AND presentation: "Design for Online Communities: Past the Hype!" by Lynn Cherny, PH.D. (User Experience Consultant & Author)

WHEN? 7 to 9 p.m. Tuesday, June 26th

• 7 p.m. 7:45: Conversation, networking, refreshments.
• 7:45 to 9:00 p.m.: Presentation and discussion.

RVSP by Friday, June 22nd required: please send an e-mail to: [redacted due to spam] with your name and your company information.

WHERE?
One to One Interactive
Schraft Center | Suite 209 (2nd Floor)
529 Main Street
Charlestown, MA 02129
There is a free public parking lot at the Schraft Center.
DIRECTIONS

MORE ABOUT THE PRESENTATION:

Successful online community creation requires an understanding of both social and technical design challenges, as well as skills you may not realize you need in your organization. Face-to-face study of community predates the Internet by at least two centuries, and has been done within sociology, anthropology, and linguistics. I will review some academic background on what makes a "community," whether online or offline, and then show how these notions apply online in the form of useful design principles. I'll wrap up with some metrics for evaluation based on your choice of definitions, taking you beyond simple page views and number of members.

Bio: Lynn Cherny's books Conversation and Community (1999) and Wired_Women (1996) were classic web 1.0 studies of online community that were used in many graduate classes. Since her research days, she has been a designer and manager at Excite.com, TiVo, Adobe, Mathworks, and Autodesk.

ABOUT UX BOSTON:

UX Boston is a new local branch of the User Experience Network, (Uxnet.org.) Our goal is to foster cross- disciplinary conversations and create connections across UX-related disciplines in the Boston area, including design, information architecture, usability, and technology development. We also serve as a bridge between other local and national UX-related groups. Membership is free and open to Boston-area UX professionals. For more information, and to help influence our meeting content, please visit: http://tech.groups.yahoo.com/group/uxboston/

Stephen King on Writing -- And Design

I like this no-nonsense essay by Stephen King, Everything You Need to Know About Writing Successfully - in Ten Minutes. I think it applies to doing good design as well.

Here's my remapping to design:

• "Be talented" should go without saying. Design is an art, too, even if it's data-driven. There is still creativity involved in knowing how to ask the right questions and take insight from the data.
• "Be neat" may be my own weakest point -- I'm a sketchy ideas person, and struggle for the pixel perfect after the big insights. But I keep trying and see it as a self-improvement challenge.
• "Be self-critical." If you haven't thrown away a bunch of ideas, and can't show that you have, you're probably not talented. The same goes for photography or any other art that takes practice to do well. Idea generation is easy, choosing the right ones for the right reasons is the skill part.
• "Remove every extraneous feaure." That's my redoing of King's "extraneous word." It's about clean design -- it's harder to get to the core than it is to throw in everything you thought of. It's also braver, faced with the "featuritis-sells" mentality that even some (most?) customers have in saturated markets.
• "Never look at a reference while doing the first design." Hmmm... In the spirit of letting creativity run free, I like this. But I need to think some more about its applicability here.
• "Know the market." Know the users, know the competition, know the business. Don't work in a creative, monk-like vacuum. Your work won't be very smart and your clients/company will stare at you funny when you present it.
• "Design to improve someone's life." King had "write to entertain," and I lean towards keeping it at the same sentiment even for a professional product -- but instead I think this is about more, like elegance, and beauty, and that "wow" moment that people get from using something that works well and does exactly what they didn't know they wanted it to do!
• "Don't design if you've stopped having fun." If you've turned into one of those hurt, tired people who feels like no one gets it and you're wasted there, you can't be Jonathan Ive at Apple. (I don't know if he's tired, but he did stick it out and it eventually paid off.)
• "Take usability input and use the design or start fresh." King's point is about how to weigh feedback: if you hear different things from everyone, you can probably ignore it safely; otherwise, take it seriously even if you don't like it.
• "If it's bad, kill it." Too few companies can do this; designers themselves need to be able to do it with authority to their own ideas. You're a hack if you don't know how to filter your own ideas. Remember, ideas are cheap! You are paid to be creative, right?

Successful people are generally also practical, and King really brought that home to me. In fewer words than I would have done, to be sure! His introduction story makes a few other good points: Even people who are talented need critique and input from more experienced people to get better at what they do. They need to be receptive to that. And not everything they design will be for a domain they know something about. It's part of the talent of a good designer to get into the heads of potential users, to do the research to understand them as input to the design process.

Berkun on Innovation Myths

Another book recommendation: Scott Berkun's new Myths of Innovation. I'm a big fan of Scott's earlier book, Art of Project Management, and his new one does not disappoint. I think it stands apart from other books by consultants and design agencies on building innovative organizations. (They're now a dime a dozen.) It's short but still condenses a huge amount of material from both business lit and historical research in a way that even someone who once wrote a dissertation can be amazed at. (Note: I was not as successful as Scott was at this trick.)

One of my favorite parts is on the myth that "good ideas are hard to find." Why, no, they're not, but execution is hard. Which segues nicely to his other book; in my experience, a lot of organizations have grand product plans and grand business goals, but execute very, very poorly. The customer only ever sees a fraction of it, and often the worst fraction.

Some of the sentiments that kill good ideas before they even get to fail by execution include: "We don't have time," "That never works," "We don't do that here," "We tried that already," "That won't make enough money." A longer list lives here on Scott's Blog. I'd add the question: "Who are you, again?" Or the related, "You're here to listen, not talk" (which I've actually heard).

The issue of time is the biggie, from what I've seen in my past few companies. The execs may be reading books about innovation (for whatever reason), but at the operational level, everyone is signed up for way too much work. They can't succeed at what they've agreed to do, but they're trying anyway. Why would anyone want to sign up for more, regardless of how cool the idea is?

I have the same feeling about brainstorming; as a concept it's all warm fuzzies, considered obviously valuable, although it's often poorly or incorrectly executed (as Scott points out). In practice, though, not everyone's ideas ARE considered equivalent, precisely because of this economy of time available to the participants; given a small, finite amount of time to think and make decisions, why pay attention to the crazy sounding new kid's idea, instead of the seasoned manager who deserves to get his say because he's proved himself, right? In a more applied, problem-solution context, the more seasoned people are assumed to "know the code" or "know the users" better and therefore their opinions are worth more. It's been said out loud. It's basic human sense, right? And the less time people have, the less they're willing to extend themselves to be open.

Successful innovation might require fewer over-ambitious projects, acceptable risk and play (meaning: someone isn't working on your critical shipping "normal" work and that's okay, and not overtime work for them), plus a commitment to try to listen to all voices differently, no matter what the problem is: new product, new feature, or old ordinary problem you have to solve on an ordinary project. I'll come down strongly in favor of that last -- I think innovation can happen on "old" projects, too, and it should, to keep them viable and interesting to developers and customers.

But good project management is always needed to help you actually plan and then ship something! It's still innovation once it's in the development phase, even if it feels like just "work" then. The team needs to be supported, rather than having their work taken for granted as "a done deal" while managers go off looking for the next big idea.

I can't find it now, but one of my favorite lines from Myths of Innovation goes something like, "Successful ideas, like happy pets, are shared among many people who care about them deeply." Pet them, sometimes.

Hiring the Smart and Effective: Joel

Joel Spolsky has just published a short, concise book on his hiring principles, summarized by the excellent "Hire Smart People Who Get Things Done." His book is Smart and Gets Things Done. I've blogged about his hiring guidelines and other interviewing issues: My 20 Observations on Coporate Design touches on this, as does the post about "Joel on Interviewing, Me on Performance" and the one about "Past and Current Employees and Your Reputation."

As a consultant now, and a survivor of (too) many companies, I do and have done a lot of interviewing. As a manager, I interviewed a lot of people while hiring (especially at TiVo and Autodesk). Joel is a good guy to follow on this subject, and I find his points can be extended to interviewing for designers and good employees in general. Failure to hire well (or take the right job!) is sometimes your fault!

Some things to consider when interviewing people to hire or interviewing for a possible job yourself:

1. A bad interview usually means "you don't want them and they don't want you." It's okay if it's not a mutual fit. Use that time wisely on both sides.
2. Some reasons for bad interviews (that suggest bad jobs in the background): They have junior people doing the interview, because they don't take it seriously; they have unqualified people doing the interview, who don't know what's good or bad; they have the wrong expectations, because they've never hired for this type of position before or are confused about the market and the job.
3. If you're the interviewer, and you do a bad job, that person is now possibly pissed off; freaked out; depressed; going to tell other people about your and your company. Mostly about your company because they may not distinguish between you and the company since they probably don't know you personally and you act as a representative of the company when you bring in a candidate. They may want to tell their friends, who are possible great fits, or tell their friends' friends, that you are a scary place to interview. This can do you damage and make it hard to get good candidates, needless to say (right?). I've heard more frank stories from former "rejected" candidates of the places I've worked since I left them than you can imagine. Bad word-of-mouth is not something you need in a competitive climate.
4. Sometimes you hire badly not because the person is bad, but because your job description or belief about what's needed are inaccurate. I've also heard plenty of stories along the lines of "this is not what I thought I was hired to do." (See post on "Invisible Work," for some examples.)
5. Someone who does a really superficial interview for a high-level position is a warning sign: either they hire other people badly so your peers will be poor colleagues, they have had a really hard time retaining and are desperate, or... something worse. Be wary of people who don't do a rigorous interview. I had a great one recently, or mostly great: the hiring manager walked me through scenarios, questions about the resume (detailed), adjectives people would use to describe me (I tried for positive and negative), past performance review feedback, etc. Her one failure was that she didn't ask why and what I was looking for up front, and in truth, I wasn't really looking! I was hoping for an informational discussion, as a consultant, first! But at worst, this wasted some of our time, and I ended up thinking she was a good manager and a possible contact for future work.

Ways you can avoid bad interviewing, as an interviewer, apart from having design/code tests and the other things Joel talks about:

• Treat each candidate very seriously -- it requires energy, but don't convey disinterest. Intuit once sent me home with a design test, rather than doing their usual and more effective whiteboard version, which pissed me off on several fronts; and I would not interview again with them despite them having many large product groups that need good designers, and see, I'm now blogging about this; see points 1 and 3 above.
• Get back to them in a reasonable amount of time with frank but polite response -- yes you're busy, indecisive, disorganized and unable to get everyone's input or reach a decision as a committee, but still. This is important. They're forming conclusions about you too.
• Don't assume you're their only job option and they're not being picky and making a decision too -- you're not in as much control as you think you are here.
• Don't let disorganized, rude, or confused HR people get involved and ruin the mood for them.
• Have senior people involved, to show you care, and to help make the right call outside of the comfort zone of junior folks on the interview schedule. Sometimes a hire can be strategic as well as tactical.
• Hire for potential and growth, not because of someone's current age (yes, it has happened), what they look like (yes, again), because you had budget to spend (someone still has to manage them), or because of domain knowledge that they will lose in a year off that former job. Yes, it's harder to evaluate this, but if you can't do it, maybe you're not the right person to hire or manage them?

Followup on Assholes at Work

Following up on my previous post on this... On Sutton's blog, he has a No Asshole Rule Roundup of comments he's gotten. One is quite well-taken: the subtle asshole is just as bad or worse than the flamingly obvious asshole, in their effect on morale. Sutton agrees: "Indeed, these more subtle assholes actually can often get away with doing more damage than their more 'over the top' and less politically skilled counterparts."

While googling around, I ran into this well-observed book review: Disorganized, Incompetent and Dangerous: Workers Dislike Manager Incompetence Even More Than Abuse, Study Suggests. The review is for a book I have since ordered but not yet read, Dignity at Work, by Randy Hodson. Some points from the article about it:

He found that abuse by managers was significantly connected to negative employee actions such as absenteeism and withholding effort on the job. However, the research found an even greater connection between mismanagement and these same negative employee actions.

"Nobody likes abuse, but employees can find ways to work around abusive managers. But employees don't want to be involved with chaotic, mismanaged workplaces where nothing gets done well and people feel like they can't be effective," said Randy Hodson, professor of sociology at Ohio State.

"The thing that undermines dignity more than anything is incompetence and mismanagement."

I spoke with someone recently who told me how much he'd learned from someone competent who had managed with a big stick approach, arguably an asshole by Sutton's criteria. But he had respected the guy anyway. It seemed to me in listening that he had tolerated it while he was learning, and then moved on to a more humane work environment. You decide the moral, if there is one.