Listened to a talk delivered by Irene Au during Adaptive Path's Managing Experience (MX) Week in Feb 2007. I found the 45 minute podcast via IT Conversations.
I wanted to document the insights in a more readily accessible form, so I figured I might as well blog it.
Below are the quotes which really struck me because I think they are actually applicable even in areas outside of user experience management [minutes into the podcast]:
- On collaboration. We don't want to risk having people operate in functional silos with all these hand-offs, because that's where you might lose the opportunity to innovate. [10:35]
- On hiring. I often advocate for hiring T-shaped people; people who have deep expertise in one or more areas, but have broad interests and skills in related areas. [10.45]
- On the "brand" of your team. Do fewer things really well, because ultimately it's the brand of the User Experience team. Do we want to be known as a "shop" where we service requests, or do we want to be known as a really high-end strategic asset to the company? The only way we can really get to the latter is to choose very carefully what kind of projects we engage in. [12:12]
- On juggling projects and priorities. I do kind of see it as managing a financial portfolio, in that we want a percentage of projects that are near-term, practical, we're launching projects. Another part of the portfolio ought to be infrastructure, central efforts like style guides and design patterns. And another part that's more kinda blue-sky R&D, because it's important for the User Experience team to initiate projects and not just take orders and requests that the engineering or product management organizations are coming up with. [13:48]
- On communication. Speak the right language to the right people. At Adaptive Path, it was speaking the language of finance to the people who write the checks. At Google, it's speaking the language of engineering: "Imagine a graph with a billion nodes, and you can write algorithms against that..." [17:04, Jeffrey Veen]
- On meetings. The method or skill that we would all benefit the most from is Meeting Facilitation. If we did nothing but just learn how to better facilitate meetings, we would excel. [26:18, Peter]
- On centralized vs. decentralized. Early in a company's life, it's better for user experience teams to be centrally organized and managed. The community is smaller than engineering and product management; it's cross-functional and requires expertise and talent from different areas, so it helps to have a centralized group where people can share best practices and communicate, to hone their methods and standards over time, so teams can stop reinventing the wheel and move to higher-end activities. But at the same time, user experience is often most effective when it's integrated with the product teams. You can overcome that when you're a centralized group by matrixing into the product areas, so you can get relationship building with the product teams and have deep expertise within a domain and still have ties back to a user experience community. [27:45]
- On Google's centralization. Sergei will advocate -- we should be building features and not products. I think this is a reflection of the anti-silo thinking that is advocated there, where it's really not necessarily products that we're building, but it's experiences that are integrated that we should be building. When you have a company that thinks that way, it doesn't necessarily make sense to decentralize the user experience team. [30:58]
- On creating Yahoo's Style Guide. There are three components to that. (1) Universal look and feel. When we built the style guide, we advocated for building consistency without uniformity. How do you message Yahoo as one company but not necessarily make the products uniform with each other? (2) Design pattern library. This was more around best practices for interaction design so we can stop reinventing the wheel. How many different ways can you invent a way to do pagination or editing a table? Let's come up with the best way and get past that, and if people want to iterate and innovate off of that, we can do that and feed it back into the pattern library. (3) The UI Code Library, which has now become the YUI library, which is available on the Yahoo developer network. It's a way to consistently implement those components, widgets, and modules, so that we can design not only more efficiently, but also create a more coherent experience across the network. [33:41]
- Styling multiple products. It's important to find the elements that communicate everything as one family, but not necessarily make everything consistent for the sake of being consistent. [44:38]
Updated to add:
Jeffrey Veen also has a transcript of an earlier interview (Feb 2007) with Irene Au on his blog. Turns out he's been working on the new Google Analytics, which I was just checking out earlier today (talk about timing)! Jeff also has a Twitter account, in case you feel like following.
