Thinking and Making: Comments by Austin Govella

Austin Govella — Sat, 05 Apr 2008 23:10:39 GMT

Shawn,

I’m totally with you here. In fact, the next post explains behavior-based metrics a bit more, and I think they have two key qualities:

1. They measure the desired user behavior.
2. It’s comparative, so you have the kind of ratio you’re talking about.

Austin Govella — Tue, 08 Apr 2008 05:36:52 GMT

Paul,

That’s refreshing to hear. And I think you’re right about it being the obvious. I’m still not sure why the metrics people use are so skewed some places.

I think I’ll be doing a side thing at the Summit on the ‘UX health check’. It’s a qualitative way to derive a longitudinal, quantitative measurement of your product’s experience. That’s lots of big words, but it makes total sense when you see it.

Catch me at the Summit, and I’ll fill you in. I’m interested in getting people’s responses.

Austin Govella — Tue, 15 Apr 2008 17:01:53 GMT

Hey Jon!

I found this great article from Jeff Patton on what he calls the “slow software movement’: * http://agileproductdesign.com/blog/slow_software.html

I think your focus on feature scope vs. code quality is really interesting. I prefer to prioritize experience or product quality. I’m more interested in the gestalt of the engineering + the features + the experience.

I feel like a lot of time, the project focuses on engineering or features, which makes sense, since they’re more concrete.

Frankly, the backlog is a ghetto. Things go in and rarely make it back out. There’s a lot of political pressure and shifting priorities that cause this to happen, so it’s not the backlogs fault, but that definitely means the backlog, by itself, isn’t a good answer.

We used to have the “IA bucket”. That seemed to work well. Maybe re-instituting the bucket would be a good thing? We used to use it for bug fixes, features, and design scrubs: all the “experience” things. And maybe there should also be an “engineering bucket”?

Definitely, we should write a ticket as soon as the gap appears. That’s an awesome idea.

Austin Govella — Tue, 15 Apr 2008 17:11:52 GMT

One of my goals has always been to increase the team’s design literacy. That’s just good practice in any organization with any process. Design literacy enables faster, better, more advanced collaboration, and that’s exactly what an agile process needs.

We’ve divided user tasks on the site into four major groups, and we have a set of ‘generic’ requirements for each. (More like best practices for that kind of task.)

I’ve been struggling with the best way to communicate these requirements to both engineering and design. Any suggestions?

Austin Govella — Wed, 16 Apr 2008 18:43:52 GMT

Dude. Awesome insight. I think that begs the question: when we communicate in person, how much does our audience *really* affect what we say.

We assume it affects a lot, but maybe it doesn’t?

Austin Govella — Wed, 23 Apr 2008 14:38:41 GMT

Tanya, I didn’t even know the Second Life island was going to be active.

I think part of Twitter’s brilliance is how it easy it is to use it to create a virtual world around any other event.

Austin Govella — Sun, 18 May 2008 15:27:44 GMT

”... my perception of social intimacy is entirely relative. I may feel (and truly believe) I am close to you and you may feel (and truly believe) that we are not close at all—Twitter seems to allow us both to live that reality.”

Wow. That’s totally true. And although tat occurs occasionally in real life, I think Twitter exacerbates that disconnect because it lacks a lot of the physical social contexts that we have in the physical world.

Austin Govella — Sun, 01 Jun 2008 01:51:19 GMT

Brian,

I totally agree on our primary goal as UX practitioners. If I seemed casual, that’s only because I don’t think the UX is the most important part of working on a team. I think the most important part is working well together.

Every one on the team makes compromises. Working well means everyone understands the best compromises to make. That’s why the team’s design literacy is so important.

Austin Govella — Mon, 16 Jun 2008 20:26:36 GMT

Thanks! I appreciate the kind words.

I actually came across your blog recently. Wish you wrote more.

Austin Govella — Mon, 16 Jun 2008 20:27:49 GMT

One thing I liked about when we did the exercise for our team is the way we couldn’t necessarily agree on an “Only”. That can be a useful insight, too.

Austin Govella — Fri, 07 Jan 2011 19:39:19 GMT

The first time I tried this, it was for a specific, but pretty broad project (Fancast). Since the Only statement focuses on differentiation, you could use it at any level. For Fancast, we made one for the project as a whole, but we could also make one just for the online video experience.

It’s definitely useful for the whole org.

When I was working on the Only statement for Fancast, I sketched one out for Comcast (the parent organization), but I never documented or communicated it out. I used it as a very broad horizon for making sure the Fancast work was properly aligned with the company’s overall strategy.

Austin Govella — Fri, 07 Jan 2011 19:39:19 GMT

I’ve been mulling this over (for a month), but I disagree. Sometimes better than yourself is all you have to launch, but it’s never enough, especially for commercial products.

Jeff Patton has some good analysis as to why this is true on his blog, Agile Product Design (12 emerging best practices for adding UX work to Agile development).

Good UX depends on how the experience works in context, and these very important contexts include competing experiences from both direct product competitors as well as analgous experiences. (E.g. Flickr manages photos but offers an analog you could use for file management.)

But as long as everyone answers the same question, then you’re already way ahead. :-)

(Isn’t this why the user story specificies the user and the why?)

Austin Govella — Tue, 06 Jan 2009 04:19:12 GMT

Thank you David.

I was just thinking about redesigning to make it more cluttered. Your comment came at exactly the write time to remind me to keep it clean.

Austin Govella — Wed, 08 Jul 2009 20:40:59 GMT

Liz,

Those are great. I have a really tough article I’m editing now that I’ll try the context switching on. I’ll probably try a new format AND a new location.

Reading the piece backwards sounds especially good for material you’re self-editing (like blog posts).

In a similar vein, I often change context by letting something to sit for several days. The different head space helps provide a new perspective.

Austin Govella — Wed, 19 May 2010 01:58:50 GMT

Dearest Ms. Spencer,

I think that happens. Anyone is forever skewing their work so they can do something they’d rather do. But it’s still a team sport. And a team chore is still a team chore. Regardless of who-so-ever the Nathan is, the rest of the team still needs to get the chores done.

And I do not for a minute believe you have seen this on non-agile teams. Agile teams are special and unique. YOUR WORLD IS UPSIDE DOWN AUSTRALIA!!!

Kindest Regards,
Me