Working better from Thinking and Making

Transparency reduces organizational failure

Austin Govella — Sat, 23 Jul 2011 14:02:56 GMT

Victor Lombardi notes a great article on transparency from the New Yorker. In it, a very successful hedge fund cites it's success on the concepts of transparency, evidence-based decision-making, and honest feedback. This is the kind of culture you can help engender by making your design process as visible as possible. Techniques that help this include design critiques. Check out the presentation on critiques by Adam Connor. Critiques teach how to give and receive honest feedback. Transparency can also be helped by simple steps like putting your process on the walls. I detail this in my presentation from Big Design on miracle farming. Transparency can also be engendered through the use of design studios. Will Evans and Jeff Gotthelf have been detailing their process with studios at TheLadders on Will's blog. I used to phrase design's most important tenet as being about communication, but communication is too fuzzy a word, suggesting a broadcast with the magical hope of someone understanding. Instead of communication, we we're really working towards understanding. We really are in the understanding business.

UX Miracle Farming

Austin Govella — Fri, 15 Jul 2011 21:18:58 GMT

Update: Friday, September 2

I updated the slides with complete speaker notes, so each point is now fully explained. In addition, I've added a PDF version of the talk that shows the slides and speaker notes on the same page.

Austin speaking at Big Design, 2011. Photo by Russ Unger. I look like Lisa Loeb with a goatee.

I presented "A Guide to Farming Miracles" at the Big Design conference in Dallas on Friday, July 15. There was a great audience, and I presented seven barriers that organizations face when trying to build better products and services:

The organization:
...doesn’t VALUE design.
...can’t FOCUS on everything it needs to do.
...doesn’t have TIME to accomplish all design.
...has no MEMORY about its design decisions.
...has a low QUALITY of design by others.
...has no UNDERSTANDING about what it takes to do UX.
...can’t validate IMPROVEMENT.

Livia Labate's UX practice diagram is an example of a design story. Photo by Will Sansbury.

Alongside identifying the problems, I offered seven tactics for overcoming those barriers that are simple enough to take and implement on Monday. Unfortunately, time kept me from introducing the the scads of other tactics UXers can use to improve design at their company.

Fortunately, that means I have lots of juicy blog fuel for the future.

I uploaded today's Miracle Farming slides to Slideshare and embedded them below for convenience.

You can also download a PDF version of the talk that includes slides and full speaker notes.

The audience appeared to enjoy the talk. You can see some of the response on Twitter using the hashtags, #miraclefarmer and #miraclefarm. Being able to see audience response like that really helps tweaking presentations and performance.

A Guide to Farming Miracles (for UX teams in tough environments)

Agile+UX - remembering what a team's sposed to be

Austin Govella — Wed, 19 May 2010 01:35:49 GMT

The inimitable Dan Brown passed along an email from a friend of his:

At my current job, we have an on staff UI/UX person and since we adopted Scrum across our entire team about two months ago, she has been struggling... I fear our UX person has basically just stopped participating in team activities to everyone's detriment... I'd appreciate any thoughts on how I might help her re-engage and figure out how she might adjust her work to fit in better with an agile process.

Some sad Scrum master

My Life as a Panther

I was a Boy Scout when I was younger, and in Boy Scouts, groups of 5-10 boys are organized into units called _patrols_. And everyone in the patrol is about the same age, so it ends up being a peer group. Every patrol has a Patrol Leader and an Assistant Patrol Leader who are tasked with managing 5-10 rowdy boys who spend a lot of time playing with knives and lighting fires. It's a good time.

Once, when I was a Patrol Leader of the Panthers, I had this one kid named Nathan who was more of a recreational scout. You know: there for the camping, axe throwing, and co-ed activities with girls from Explorer Troops. Now, in Boy Scouts, whenever you go on a camping trip there's a set of chores the patrol has to do. Someone has to cook. Someone has to do the dishes. Someone has to dispose of the trash. Someone has to collect firewood.

There's no use arguing about it. Those chores have to get done, so you make up a chart with the boys names down the left side and the chores across the top and you put X's next to boy's name when it's their turn to do that chore. And you rotate through so everyone does every chore in turn. It's a fair system.

Except for Nathan. He wasn't into any of it. Especially dishes. Whenever it came time for him to do the dishes, without fail, I'd have to go help just to make sure he did some of them. I helped because it was my job as the Patrol Leader. If the team chore didn't get done, the team didn't eat, or didn't have a fire, or would have to fight off bears in the middle of the night. When Nathan failed, the team failed.

The bullshit behind agile+UX

There are a lot of agile teams where we like to say "the UX person has been struggling". We talk about culture clashes, misunderstandings, wagile, sprint 0, and scrums. And there's often a good bit of derision and disrespect that drips from the engineering community about UX, in general.

I would like to take this opportunity to call bullshit on UX not integrating with agile.

BULLSHIT

Agile is built around teams. Your UX person isn't struggling, your team is struggling. If one person fails, the entire team has failed. Your burn downs, WIP charts, bug triaging, and velocity mean fuck all if any member of your team from any discipline "is struggling".

What you really should be saying is "my team is struggling with UX and not one person in a room of engineers can do anything to help her out". Really? No one can help her? Is the asshole quotient so high, that she's actually stopped participating?

Working as a team

Team's aren't rocket science. Differences in the way designers and engineers think are important, but they're not stopping you from succeeding. It's not the difference in process. It's not different goals. It's not the length of the sprint. When you phrase the problem as a team problem, and not a UX problem, it's obvious how you can better integrate UX.

Do you need wireframes but not have them? Then help your team member with the wireframes. Do they say you need personas, but not have any, then learn how to make personas. Do they say you need to do some testing, then help them do some testing. Do you not understand why you need wireframes or site maps or personas or testing? Then learn about wireframes, site maps, personas, and testing. Does an engineer who takes time out of their sprint to help a team member then complete less code? Yes.

But there's no use arguing about it. Those chores have to get done. Your team member said they needed to get done. The same team member that never questions when you say a chore needs to be done, has said a chore needs to be done. If the chores don't get done, the team fails. Not one person. Not one discipline. The whole, entire team. If you release something with shitty UX, it wasn't UX's fault. The Team Released Something Shitty.

The fact is, a lot of engineers on a lot of teams are Nathan's. They'd rather light fires and throw axes and chase Explorer Scouts. But someone's got to do the dishes. And whether you like it or not, UX is the dishes, and you've got to get it done.

Next time you think your team has an individual problem, rephrase it as a team problem and see how _the team_ can make sure all of the chores are done. If UX isn't integrating well, I'm willing to bet the few UXers are less likely to be the culprits than the many engineers. Just playing the odds...

Things you need to do to write a book

Austin Govella — Thu, 12 Mar 2009 10:00:00 GMT

If you ever find yourself writing a book, there are a few things you'll want to make sure you have lined up.

Set a wireframe and diagram style - If you might be using wireframes, diagrams, screenshots, or photos, you'll want to settle on a style for each. This includes how closely they're cropped (or not), how they're annotated (if at all), the text size for labels, and the style for lines, object strokes, and object fills.

Define a style for URLs, navigation, and links that appear in text - You or your production team will probably already have a style for displaying URLs. But make sure. For Blueprints, we spend a lot of time talking about navigation, links, and labels, and we found we needed a style to differentiate a link from a label.

Write an introduction, foreword, and conclusion with serious purpose - The introduction, conclusion, and first chapter significantly frame the readers perception of the book. Christina and I jumped right in to working on the meat of the book. The intro and conclusion are competent and get the job done, but we didn't spend nearly as much time on them as we spent on other chapters. They're ok, but I think the entire book would've been better if we'd provided better framing.

Styles for call-outs - This ties in with identifying a style for wireframes, diagrams, and screenshots. Sometimes you'll include something and then want to call attention to a specific portion of the page. Of course, it's better to crop down to the area of importance. A couple of times, we specifically included a shot of an entire screen with a small call-out just so we could show more context.

Phone convos/f2fs regularly (weekly or bi-weekly) - Writing a book is a serious, group activity. I think weekly phone conversations or face-to-face meetings help the team occupy the same headspace. Your readers will read the book in one headspace. On the scale from schizophrenic to extreme, singular vision, the latter is easier to read.

Edit, edit, edit, rewrite from scratch, edit, edit edit - Edit, edit, edit, rewrite from scratch, edit, edit edit. Edit, edit, edit, rewrite from scratch, edit, edit edit. Edit, edit, edit, rewrite from scratch, edit, edit edit

Once you've taken care of these six steps, the last thing you'll need to do is edit.

The secret to writing well

Austin Govella — Thu, 12 Mar 2009 02:32:49 GMT

For several months, Christina whipped my writing into shape with three incessant questions asked from the audience's point of view: # What are we about to learn? # What’s the core argument? # Why do we care? And after all of that, she'd delete my introductions and ask "WAYTTS": What are you trying to say? So now you know the secrets to writing well.

Frank Gehry interview from TED

Austin Govella — Mon, 16 Feb 2009 14:30:00 GMT

I really loved this interview with Frank Gehry from the TED Conference. He talks about why he does the work he does and some of his experiences.

Wilson Katter's Business Deal Basics

Austin Govella — Tue, 02 Sep 2008 12:11:00 GMT

Recently, David Maister ran this fantastic post on Wilson Katter's "Business Deal Basics". Lately, I've been mulling over the idea that design is less about designing the interface and more about designing the organization that designs the interface. Wilson Katter's basics speak to ways designers can better design the organization. Katter has graciously allowed anyone to circulate his ideas providing you acknowledge his authorship and copyright. I've copied them below hoping that would make you more likely to read them. Also check out David Maister's site. (He has a new book out!)

Wilson Katter's Business Deal Basics

To avoid many of the problems which arise in business relationships, here is a set of prerequisite criteria with which all parties should enter the discussions/negotiations.

Much time, money and effort can often be spared with the conscientious practice of these criteria. Without them, the negative impact of misunderstandings, aggravation and emotional wear and tear can also sometimes cause an almost incalculable loss.

The goal of a win/win result, defined as such by all parties
The skill of understanding the position of all the parties
A keen appreciation for the relative value which each party brings to the equation
The use of reliable, authoritative resources
An “I may not know it all” attitude
The willingness to have “facts” challenged
Finely tuned listening skills
Consideration of all points of view
Impeccable integrity
Transparency and honesty
Keen analytical faculties and good judgment
A mature sense of fairness
Compliance with high legal, ethical and moral standards
Clarity of both oral and written communication
Timely replies/responsesin the exchange of information
The ability to “disagree agreeably”
Humble acceptance of the required modification of one’s position
Patience to do it right the first time so it doesn’t have to be done over
Equitable compromise without the sacrifice of principles
A long-term perspective which looks beyond the near-term benefits
Respect, respect, respect

REMEMBER, IMPROPER MOTIVES WILL MOST LIKELY KILL THE DEAL.

ALTHOUGH CHALLENGING AND SOMETIMES TOUGH, DOING BUSINESS THIS WAY CAN HAVE THE GREATEST REWARDS.

72 questions to ask on your first day

Austin Govella — Mon, 07 Apr 2008 04:00:00 GMT

Well, maybe not on your first day, but during your first few?

When I joined Comcast Interactive Media, my supervisor, Livia Labate, handed me a copy of Michael Watkins's job transition primer, The First 90 Days.

It's all about landing in your new position, figuring out the landscape, and then kicking ass. Intended for "leaders", it's actually good for anyone moving into any new position. The title refers to your transition period, and the book is about coming out of those 90 days with clear wins, the support of your teammates, and shared vision for getting things done. Recommended reading.

While I was going through the book, I put together a list of questions I wanted to answer. In a more generalized form, they're a good set of questions for understanding the ins and outs of any organization.

Questions about my performance evaluation

What are my specific duties within the team?
How am I evaluated? (What is success? What is failure?)
What are your goals for me?
What are the organization’s goals for me?
What can I do to cement credibility with the organization and other business units?

Questions about your supervisor’s goals

What are your supervisor’s goals for the IA team?
What are your supervisor’s goals for the organization?
What are your supervisor’s goals for you?

Cultural Norms (What’s most important? What’s sexiest?)

The timeline, the features, quality (product or experience), or the budget?
Being first to market or well-architected?
Having comparable products or innovative products?
Being on message or being visually stunning?
Client-side development, server-side development, design, marketing?
The customers, the products, the technology?

What’s the business structure?

What are the business units?
Are there any other fiefdoms?
Who are the key visionaries?
Who are the go/no-go gatekeepers?
Who are the greatest champions?
Who are the most-feared Black Knights?
Who are their influencers?
What are the key revenue streams?
How is your supervisor evaluated?
How is your supervisor’s boss evaluated?
How is the organization evaluated?
Who is your supervisor’s greatest Champion?
Who is your supervisor’s most-feared Black Knight?

What’s the story?

What’s the vision?
What’s the strategy? (compete on quality, not price?)
Are the vision and strategy different from the past?
Are they expected to change for the future? (We’re realigning now. To what?)
How fast is the organization growing? (Hiring versus attrition)
How fast is the organization’s market share growing? (overall and in specific markets)
How is the customer base growing?
How is the organization’s revenue growing?
Who are the organization’s top competitors?
What are their advantages over us?
What are their comparative weaknesses?
What is the organization’s strategic advantage?
What is the organization’s strategic weakness?
Are these strengths and weaknesses shifting? (How does the realignment affect them?)
Who are the future competitors?
How do we expect the market environment to change?
Are there other markets that will become a factor for us? (Opening, closing, merging, fracturing, etc.)
What capabilities, products, or positioning is the organization missing that prevents it from being prepared for these changes?
What’s the organization’s biggest challenge for getting to where it wants to be?
How did the organization’s story arrive at this challenge?
What was the impetus for the realignment?
How has the realignment affected morale?
Has it affected projects in a positive or negative manner?
Has the realignment affected products to make them better or worse?
How has it affected custmer service quaity?
During the realignment, were there any early wins or losses for any of the fiefdoms, champions, or Black Knights?
What are three cultural attributes?
What other cultural strengths should be preserved?
Where is the invisible elephant?
How can we fill that hole?
How can your department help the organization get there?
What are the reasons customers usually leave?
What’s the most common reason for joining?

How do we work?

What’s the real process (not PMI phases)?
What are the inputs for each project?
What are the usual timelines?
Who’s involved (beyond the project teams)?
How do projects come about?
How often are they driven by tech or engineering as compared to being service driven by CRM, sales, and marketing?
What is the organization’s batting average for success and failure?
Are there any benchmarks the organization uses?
Are there any common stories attributed to successes? For failures?

Who should I talk to?

Who’s done contract work for us?
Which media and technology analysts are best to watch?
Who’s been with the company forever?

Way back in the 90s, I cribbed this great list of questions from Vivid design that covered all the basic requirements gathering one needed when designing a website. I've long lost them. If anyone has those, I'd love to see them again. Even if only for the nostalgia.

For that matter, if you have any suggestions for additions, changes, or removals to the list above, let me know.

Too many feeds? Ration your feed subscriptions!

Austin Govella — Sun, 06 Jan 2008 02:31:09 GMT

I read feeds to keep up with the industry, as well as with the community and my friends. So, when I moved 1500 miles away from the local community I enjoyed seeing at PhillyCHI events, it was important I get back into "readin’ mah feeds".

However, as a feed junkie, I tend to collect large numbers of interesting reads (inbetween periodic culls). Definitely, I watch too many to check on anyone day.

In the past, I grouped my feeds by subject: business, marketing, ia/design, and web dev. That worked pretty well, and I could ignore huge tracts of RSS real estate based on mood, time, or interest.

And, sometimes, I don’t really care. I’ll check a couple of websites and then ignore the feed universe for weeks at a time.

But, if I want to keep up with everyone all (or most) the time *and* not blow chunks of each day in my RSS reader, then I need a good way to ration what I read every day.

A screenshot of Newsgator where I created a folder for each day of the week, each with an equal number of feeds.

So, instead of grouping my feeds by subject, I rationed them evenly by days of the work week. To keep the daily read minimal, I split them across two work weeks (10 days, instead of five).

I segregated a small set of daily reads into an "everyday" folder.

I’ve been using this method since Wednesday, and so far, it’s fantastic. I feel like I’m keeping up with everyone, and my daily update takes about 15 minutes. Perfect timing for waking up with my morning coffee.

Assessing your team's UX skills

Austin Govella — Mon, 17 Dec 2007 05:11:00 GMT

Jared wrote such an awesome article over at UIE, I'm actually posting: Assessing your team's UX skills.

The best part isn't the assessment. It's his breakdown of core and enterprise UX skills.

Changing the Channel (interview with Livia Labate and Austin Govella)

Austin Govella — Sat, 15 Sep 2007 20:04:00 GMT

Last March at the IA Summit, Christina Wodtke grabbed myself and Livia Labate for a quick discussion about how information architects can better interface with the business.

I'm a few months late on mentioning this, but our interview inaugurated Boxes and Arrows podcast series, 'Straight from the horse's mouth', that also included great interviews with Behavior's Chris Fahey, Dan Brown, Yahoo's Tom Wailes, and Derek Featherstone. (The interviews are no bullshit, Summit conversations captured in little audio time capsules.)

One of the reasons I wanted to work with Livia at Comcast Interactve Media is because she has the amazing ability to enter a conversation, immediately understand the key issues, intuit exactly how the participants need to be spoken to, and then say the perfect thing at the perfect time.

For anyone in any service industry, this is THE skill to have.

And of course, Madame Wodtke wields this same magic. Her summation of the interview with me and Livia?

Learn the language
Lose the agenda
Be a resource
Dress better

If you don't speak PowerPoint, that translates to learn the language of business, lose the user agenda and focus on what the project needs, become a trusted and dependable resource for the business, and if you look like you're on the business team, you'll have more business conversations than design conversations.

That's the gist of it. The complete interview is up at Boxes and Arrows. Straight from the horse's mouth: Changing the channel.

Products as duck-billed platypi

Austin Govella — Fri, 14 Sep 2007 00:08:00 GMT

Products evolve, and I get that, but it's driving me crazy. 37Signals's Backpack lets me email to-dos, but there's no way to date them. I can added dated to-dos (reminders) manually. As a bonus the reminders are available as an ical feed, which means I can import my reminders into the Backpack calendar. That's cool. I can see appointments and dated tasks side-by-side. Brlliant. Highrise also has to-dos, but they're called tasks. The only difference between Highrise and Backpack tasks is that Highrise gives you the option of dating a task. Essentially, any task can be dated or undated. And of course, a dated task is essentially the same as a Backpack's reminder. As a bonus, Highrise supports this really robust email feature that lets you email tasks to the application. And you can email them as dated or undated, and you can even associate them with one of your contacts. So, if I need to email Mike mockups in March, I can email this to Highrise and forget it. Highrise will tell me later. This is great, but Highrise doesn't have an ical feed for dated tasks (reminders) like Backpack does, so there's no way to see if I've scheduled 15 tasks on the same day I already have an all-day meeting. Did I mention that Backpack has a calendar? And it accepts ical feeds from other places. So, if my wife and I have our family events in a Google calendar, I can pipe the Google calendar into Backpack and see that I'm in Dallas for a wedding adjacent to the all-day meeting I scheduled in Backpack. Too bad I can't see the 15 tasks I scheduled on that day in Highrise. And forget the to-dos I've already emailed to Backpack. I assume that at some point, the fine people at 37Signals will unify their email and calendar APIs for each of their products, but it would sure would make my life easier if they did it sooner, rather than later. Or if by some magic moment, I acquired a personal assistant to follow me around, take my appointments, open my pickle jars, and tell me which shirt to wear. Did I mention these shenanigans are taking place because Mac's iCal has started eating my machine whenever it's open? In my original system, my family calendar in Google was piped into iCal alongside the synced work calendar from Entourage (Outlook for the Mac). That was great, and all my to-dos were in Backpack. Days started with me printing out my Backpack to-do list and that day's view from iCal. Man was that awesome. Two printouts and an entire days worth of focus and productivity. Man does it suck that iCal doesn't work anymore.