There's an interesting article on B&A about Building the UX Dreamteam by Anthony Colfelt. Worth the read.
I've added my comments about the article on the B&A site, rather than here.
Friday, November 30, 2007
Friday, November 16, 2007
Friday, November 9, 2007
Virtual Hosting Blog has compiled a list of the Top 100 User-Centered Blogs. Shockingly, my blog did not make the list. This is an outrage!! I blame the hanging chads!! Stalin was right!!
Okay, so I only have one reader (Hi, Mom!), so maybe it's not a complete shock. (I'm just kidding -- my Mom doesn't actually read my blog)
Regardless, this is a really useful list of sites, and unfortunately highlights to me just how hard it is to keep up on everything that is going on.
Time to update my feeds.
Jason at 37signals has an interesting post about why they don't use personas:
Every product we build is a product we build for ourselves to solve our own problems. We recognize our problems aren’t unique. In fact, our problems are probably a lot like your problems. So we bundle up the solutions to our problems in the form of web-based software and offer them for sale.
We recognize not everyone shares our problems, our point of view, or our opinions, but that verdict’s the same if you use personas. Making decisions based on real opinions trumps making decisions based on imaginary opinions.
I’ve never been a big believer in personas. They’re artificial, abstract, and fictitious. I don’t think you can build a great product for a person that doesn’t exist. And I definitely don’t think you can build a great product based on a composite sketch of 10 different people all rolled into one (or two or three).
In addition to the post itself, the comments are really well-written with good points made in both directions.
For me, what's interesting is that I am known for not being a big fan of personas, and yet I think Jason is completely off the mark in his criticism. Or, to be fair, he highlights good reasons why 37signals doesn't need to use personas, but doesn't seem to recognize that those reasons don't apply to many other teams - 37signals is not a representative company. They are the exception, not the rule, because they strongly believe that they are the users of their own products. Not only is this unusual, in my opinion it's also not sustainable.
The other mistake he makes is that he thinks personas are meant to replace talking to real people. Of course, the truth is the opposite - personas are the output of talking to real people. For most organizations, it's just not feasible for every person in the organization to talk to real people and have the skills to successfully interpret what they actually mean and not just what they actually say. For the people who do talk to people and do have those skills, we need a way of communicating the results of those discussions to the rest of the team. Personas are one way to do that.
(Of course, it goes without saying that like any technique, there are teams that do personas poorly, but that is a reflection on that team, not the technique)
Friday, November 2, 2007
Carl Kessler and John Sweitzer (two IBMers) have written a new book called Outside-in Software Development.
This book occupies an interesting spot in the UX-related book landscape. It's not really about design, exactly, nor is it prescribing a particular software process. It's written by an executive with experience on the management side of building software (Kessler) and an architect with experience on the technical side of building software (Sweitzer), and neither of them have ever been User Experience Professionals.
And the target audience isn't UXers. I think it would be most useful for people in charge of software projects, including marketing, product management, managers, architects, and developers. I think UXers will enjoy it as well, but mostly because you'll find yourself nodding and saying "Damn right!" throughout the book - which is nice when reading a book written by a non-UXers.
However, there are some ideas in the book that were new to me as well. One in particular that I liked is that the authors argue that when you build up your list of key stakeholders for a products (including end users and business sponsors), you should also include your internal stakeholders and their goals. This surfaces explicitly that sometimes internal stakeholders have goals that are in conflict with each other... and sometimes the end users. For example, developers are internal stakeholders and they usually have a clear goal of completing their code on time - which can lead to a conflict of interest. It's not a new thought that developers can have a conflict of interest, but it's a new thought (to me) that we should document that goal when defining a product's stakeholders. Get it out in the open. Talk about it. That's a really good idea.
Mainly I found the book to be practical. Which is the highest form of praise for a book like this... and rare. It has fairly easy to implement ideas on how to shift towards outside-in thinking, and doesn't expect people to make a wholesale change to their processes in one fell swoop. They also discuss common mistakes (often with personal examples) and how to avoid them - such as trusting that your customers know what their own requirements are. And best of all (from my perspective), the book applies to enterprise software, not just building little websites. It doesn't assume that everyone on a project team is co-located and can fit in a single conference room with a whiteboard.
Anyway, I recommend the book highly.
(Full disclosure - in case anyone hasn't read my profile, I work at IBM too. I don't know Carl or John, but I've had one or two meetings with them over the years. I wasn't involved at all in the book - I didn't know anything about it until after it was published.)
By the way, Carl also has a blog dedicated to Outside-in Thinking.