Working better from Thinking and Making

A common language for interaction design

Austin Govella — Wed, 28 May 2008 20:28:32 GMT

Working on a way to get a group of people to annotate simple and complex web interactions in a similar/common way. There would seem to be two parts to this kind of Sisyphanic exercise.

The group would need to communicate using a similar format. The medium constrains the message so there would be fewer ways to be different. More of the same.
The group would need to communicate using a common vocabulary.

This is a quick sketch at a common vocabulary for talking about interaction design on the web. It assumes several pieces are required to talk about most interactions.

You have an object,
A user or system triggers something,
The system has a response,
That response has a target, and
Transitions usually make it better.

So, for each of those five steps, I've collected a common vocabulary.

Common triggers for web interfaces

A trigger happens when a user or system does something that is noticed by another user or system. Web interfaces have a collection of common triggers.

On mouseover (and/or on focus)
On mouseout (and on blur)
On (left) click
After a time interval

Common triggers for form elements

On focus
On blur
On submit
On reset

Page level events (more rare)

On page load
On page unload (when we leave this page, but before we see the next one)

Special interaction events

On resize
On scroll
On mousedown or mouseup
On right click
On double click

Interface responses

When a trigger is, uh... triggered, the interface really only has a few responses.

Show something
Hide something
Change/update something
Go somewhere else (change the page)

Response targets

When the interface responds, it does so via an object on the page, its target. We have several possible targets.

An element (displays in the page)
An overlay (displays over the page)
A lightbox (displays over the page, modal)
A popup (displays in a new browser window)
An alert (alert display in browser, modal)

Transitions

If users need to know the interface has responded, it's often important to highlight interface response. (Norman and Cooper have frameworks for when and what you should communicate to users.)

On the web, a common set of transitions has emerged.

Fade in or fade out
Slide in or slide out
Enlarge (from something or nothing)
Shrink (to something to nothing)
Highlight
Play sound
Shake

It's often good to combine transitions. For example, if an autosave is successful, you might fade in a highlighted confirmatin message. Similarly, 37 Signals popularized the "Yellow Fade" technique where a highlighted confirmation message appears before the highlight fades away.

Using the vocabulary

Use is pretty easy. Annotate as usual.

Let's say you have a header. You would annotate interactions for each applicable trigger (much as you probably do already), but you make sure to use the above, approved list of words.

So, for our header, on mouseover change the header to a highlighted state. For our header (element), on mouseover (trigger) change (response) the header (response target) to a highlighted state.

So, there's no rocket science here. The benefit would be everyone communicates the same way about the same things. Not tested. The next bit is about a common format.

Agile + UX: six strategies for more agile user experience

Austin Govella — Wed, 07 May 2008 04:30:19 GMT

There's a secret lie lurking behind agile methods. 'Agile' suggests fast. At Comcast, we're using a scrum process that throws around terms like "team velocity". And the agile literature does promise better, faster. It's no wonder that when organizations hear this, all they hear is faster. Of course, the secret lie is that agile isn't necessarily faster. It's driving tenets are to help people stay happy and create better software. The namesake agility is meant to allow teams to change product direction every few weeks instead of every six months. How do you make these kinds of agile changes? You test: Build, push, evaluate, tweak (rebuild). Unfortunately, the iteration cycle, "agile", and phrases like "team velocity" were confused with "fast". The biggest problem with lots of user experience methods is that they're not necessarily fast. They're not necessarily slow, but they do take time. At Comcast, even though user experience work is seen as valuable and important, its also seen as a slow point in the process. How do you handle this? You have six options.

1. Synchronize UX with development

My previous post on parallel workstreams touches on this. You run a UX sprint ahead of the development sprint. You figure out what dev will work on next sprint, and you work on that stuff this sprint.

In the parallel workstreams post, I go over some of the problems and realities you see with this approach: parallel workstreams, more UX than fits in a dev sprint, etc. (Check out that post for more detail.)

2. Separate modeling from design

Design doesn't really take that long. Most of us are cranking on problems we've seen before and solving them in ways they've been solved. Most of the design is using documentation and discussion to -- virtually -- walk through the product and make sure it works the way users, developers, and the organization expect.

With a good team of smart, happy people (i.e. an agile team), the design is easy. Modeling -- not design -- is the part that requires thinking and synthesis and time. You need a good model for your users, for your business, and for your interface. Don't confuse models with requirements, because they're not the same. For Fancast, the user model includes information like people think of TV shows more than they think of episodes. (You're more likely to search for 'Seinfeld' than you are for 'soup Nazi'.) These kinds of models frame how the team thinks about how to solve its various problems. Models suggest requirements because they suggest how you should think about the problem. If you can do your modeling up front, then you don't have to do it during the sprints, you can spend your small time on the fast bit, the design.

3. Design literacy

If there's not enough of you to go around, but you still need going, then you need more you.

Every team has a certain design literacy, a certain level of experience and maturity designing stuff. (Jess McMullin covers this really well.) Essentially, user experience practitioners are really, really, design literate. If you don't know an answer, then you know a method or where to look to find it. The more your team knows about user experience and design, the less they need you. This is a good thing. Leave good books laying around. When you make a recommendation explain why. With a good team of smart, happy people (i.e. an agile team), they'll pick the basics up really quickly. After all, it's not rocket surgery. Once the rest of your team can handle most things by themselves, it's like there's more you, and you can focus your expertise on the more wicked problems.

4. Collaborative Design

Agile is all about build, push, evaluate, tweak. Oddly enough, design is all about build, push, evaluate, tweak, except we do it in our heads before we bother coding it.

Everyone digs this, so take advantage. There's no reason to do your virtual build, push, evaluate, tweak by yourself. In fact, it's better for the team's design literacy and easier to share your models if you don't. Get in the same room and sketch, point, talk, and iterate. By the time you're done with the conversation, every one has a good, consensual idea of what you're building. In the end, a consensual idea is why you document. If everyone leaves with the same idea in their heads, then the last reason you have for documenting is recording details that might fall out of people's heads. Things like how a list is ordered, or what happens if there's an error. As above, you can spend less time on basic documentation and focus on what documentation is good at: remembering things you won't.

5. Lower fidelity

Documentation is still a good thing, but the more details you have, the longer your document takes to produce. Wireframes are the best example of this. A well-annotated, high-fidelity wireframe for one page can take a day, easy.

If you need to spend less time, use fewer details. If you've collaborated on the design, and you've helped improve their design literacy, then your team won't need all the detail. Strip your documents down to the basics and only deliver what people need. Make your wireframes more like page description diagrams or block layouts.

6. Book your time

Agile developers don't really pretend to code faster. That's silly. But they're fanatical about estimating how long something will take and exactly how much time they have. They're clear about their limits.

In fact, that's a clear benefit of agile methods. The extreme focus on a small sprint's worth of work means its easier to estimate, track, and communicate changes to your timeline. If it's going to take you 10 hours to work on one feature, then be clear about that. Book your time the way the development team does. Use their systems and their language. Use story points, tickets, and time tracking. Only commit to what your estimates say you can commit to. If something starts to take longer, communicate the change in the timeline. The agile system manages this (by bumping lower-priority items off the sprint).

Become agile

Obviously, these six strategies are not mutually exclusive. In fact, they work best when pursued in parallel. The crazy thing is, in retrospect, they're kind of the obvious application of agile principles to user experience design. They don't necessarily make you work faster, as much as they let you work in a more agile way.

There's one more strategy for working better with agile development teams, and it involves reframing the way the product and development teams perceive product development: have agile become UX. But that kind of design mumbo-jumbo requires a separate post. Maybe later :-P

Agile + UX = idealized vs. current state

Austin Govella — Tue, 08 Apr 2008 16:03:00 GMT

Please listen to the attached soundtrack whilst reading the following.

Agile really likes to focus on iteration. For a lot of developers, this is code for biting off small, manageable, deliverable chunks. Small, manageable, deliverable chunks is not necessarily the same thing as iterating on a design.

They _can_ be the same, but they aren't _necessarily_ the same. Regardless, this means the current state of your product is not the same thing as the envisioned state. This is true for almost every product development process, but agile can make this more of an issue.

How iteration works in the agile process

One of agile's tenets is that you release small changes to a product frequently, instead of major releases less frequently. The agile sprint is a cycle as short as two weeks where the team is supposed to develop, test, and release a feature in its entirety.

Say you wanted to add forums to your site. By itself, this might take three weeks worth of work. A small, manageable two week task might be to add a way for users to register their email address. At the end of the sprint, the team would expect to release the next version of the product that includes user registration. On the next sprint, developers might release the back-end updates necessary to handle the forums, and two weeks after that, they might release the front-end interface that allows access and participation in the forums. During these three example sprints, everyone knows the ideal state: forums on the site. And each sprint moves you closer to this ideal state. However, iteration requires two corollary management tasks. First, you have to communicate the ideal state to the team. Everyone needs to have the same shared understanding. Second, you need to track the gap between the current design and the ideal design.

Communicating the ideal state

I'm totally thinking "this is why we crank out wireframes".

To clarify for any non-UX people reading this, drawing, annotating, reviewing, editing, reviewing, approving, communicating, and clarifying wireframes is not the sexy part of the job. Sure, some people really get off on that sort of thing, and I make a point to wear fishnets any time I open Visio, but most practitioners do wireframes because they have to so they can communicate the shared understanding of what the product is _supposed_ to be. Let me be clear. Deliverables are not teh sex. Teh sex is what _leads_ to the deliverable. (Someone -- who shall remain anonymous -- put it this way: "Toddlers are awesome. Poopy diapers suck. Wireframes are the poopy diaper that happens after your toddler has eaten a great meal.") Of course, this doesn't have to be a 500-page spec. Doesn't have to be wireframes. But it has to be something. Even a photo of a whiteboard session that everyone has access to can work. Whatever it is, it has to be something.

Minding the gap

You can't mind the gap unless you have two sides to point to. One side is the current version of your product, and the second side is the idealized version.

While your agile team is iterating on the current state and marching towards the ideal state, someone has to keep track of what has and hasn't been built. This seems silly. I imagine agilists saying that the smart, unfettered, goal-centered team members will manage the gap. Sure. I suppose they could. In my experience they don't. Nothing against _them_. I'm one of _them_. And even being heavily invested in "my baby", I'm not minding the gap. This ties into my post on parallel work streams where I mentioned the sprint support role that's emerged at Fancast. Everyone is busy doing something. Engineers are developing. IAs and designers are designing. Product's reviewing, tweaking, and iterating. It's really pretty awesome. But, if a feature is limited so that it will fit into the current sprint, all of a sudden you have two features. You have the edited version being built, and you have the ideal state you _hope_ is coming. If the functionality is different, you need two shared understandings: one for now, and one for later. Now stay with me. We're imagining rolling sprints. This sprint, a small portion of a feature, an edited version of the feature is built. Next sprint, you build the next version. Or maybe you don't. Maybe the iteration isn't as important as launching another small feature. Agile lets you turn on a dime, and you've just turned. The ideal state falls into that ghetto, the sprint backlog. Who remembers that ideal state? The team's busy with something else now. And what if you've got really lean documentation? There's a gap in organizational memory. And it's not minded.

Dirty laundry. Look away. Do not read any further

Here's a dirty little secret from where I work.

Let me set the scene for you. Engineers? Rock stars. Seriously. In the IA group we have engineer love-ins where we talk about the engineer we're crushing on this week. The product team? Fucking brilliant. Seriously. They just get it. Everything. And the IA team? If I may say so myself: fucking awesome. (And, no, I am -- by far -- *not* the only IA on the team. But, for the record, the _entire_ IA team at Comcast Interactive seriously kick ass.) So here's the dirty secret. Back in September we wireframed a new version of the preferences section. In October we "iterated" on the first wireframes, which really meant they were totally redone. Each time, they were bumped off the next sprint by other things. We're redoing the wireframes a third time right now. It's not the people who are the problem. We've got good people. And it's not the project. The prefs aren't particularly sexy or ground-breaking. We just don't mind our gaps very well. Or at all, really. But if you're doing agile, you have to mind your gaps, or you'll forget where you're going. Heck, if you're moving really fast, you'll forget what's actually made it on to the site.

Agile + User Experience = Parallel work streams

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

There's a thread on the IAI-members list about how agile and user experience work together. We're using an agile dev process at Comcast, and it's been the source of some frustration, so I was kind of snarky about some of the problems I've faced. Snarky's not constructive, so, as a penance, here's something I've learned. Like anything, agile works or doesn't work based on the people you have, and the culture they function in. (Everyone can now say one giant, collective "duh".) Regardless of whether it does or doesn't work for you, I've noticed most environments require parallel work streams.

Why parallel workstreams?

Though Agile pretends to eschew documentation, it really wants to avoid unnecessary documentation. Agile likes lean. Do only what you must. This doesn't mean no documentation. The team still needs a shared understanding about what it's building.

In that sense, it's better to refer to documentation as "shared understanding". Whiteboards, napkin sketches, daily scrums, and annotated wireframe decks all provide shared understanding. (In my experience, too, the more people who will see the "shared understanding", the more time documenting the "shared understanding will take. Not an inherent truth; just an observation.) Product managers and UX practitioners still need a vision. And, it's still vitally important to examine possible impacts. (For example, how will this new feature affect flow through the site.) To that extent, *planning, design, modeling will always be necessary prior to development*. Erin Malone mentioned several Yahoo teams have started a Sprint 0 with upfront planning. At Comcast, we don't have an official sprint 0, but there's a parallel product development track that dumps something new on to the sprint backlog. Essentially, they're both the same thing: Plan before do. For incessant waves of sprints, this means you design work for the next sprint while supporting work on the current sprint. With Fancast, supporting developer UX needs (answering questions, clarifying, collaborating on additional iterations) has become a full-time job. Someone else (or several elses) design features for the next sprint. (There's a fall-out assumption here: planning and design require more product, UX, and design folks than implementation does. Everyone can now say one giant, collective "duh".) There's a danger here. If you do not accurately communicate how much work you have and how much you can do, you can get sucked into doing more than one person's worth of work. That is, you support the current sprints UX needs, and you design all of the work for the next sprint. That's a lot of work. This isn't a problem with agile. This is a problem setting expectations and communicating status. However, I think agile can make this problem more likely. With agile, the focus is often on development time. A feature might require 10 hours of development. It's possible to require more than 10 hours to plan. It could take less. Again, it depends on the amount of shared understanding, the design literacy of your team, the actual impact the feature has on the current project, etc. If you have four 10 hour development features, and they each require more than 10 hours of planning time, then you cannot crank out enough design work to keep developers fully occupied next sprint. Parallel work streams require very clear expectations and status regardless of the development process you're using. Using our above example, it's imperative you're clear that planning a feature will take longer than you have. Similarly, if planning suddenly requires more or less time, you need to communicate this change right away in a clear manner. Thankfully, on top of being lean, agile is also about constant communication. That's my experience. The big unknown is whether it's possible to support a rolling series of sprints without parallel work streams. Anyone seen this in action?

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.

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.