For the past several months, we've been interviewing for a replacement position to compliment our 1.5 person team. Out of one interview, we came across an example of a greatly formatted document, looking somewhat like an ISO document delineating everything from the purpose to the actual design recommendations after user testing. I hadn't had a really good look at this document,though I did see headings for it and detailed visuals and screenshots. But then I wondered, how useful is it really?
I've created documents like that and had thought in the past that they were being read and extremely useful to get the message across. Enter now, this past year, where I have yet to write a complete report, printed and bound with the best binding plastic, the clearest transparent cover and proper vinyl backing, ready for distribution to the internal masses. So what have I really done to get the message across?
At one point, I was tired of writing up something spectacular, something so detailed and thorough, and extremely well-written, so long that - no one had the time to read it. Fed-up with my old habits, one of the questions I asked myself was: "How can I serve my peers better?"
Marshall Mcluhan's most popular quote was, "The medium is the message." If this is the case, then what gives a bigger message? A slick document that nobody reads or the raw data collected by my user testing, the video footage, the analysis spreadsheet, the emails and the prototypes?
Yes, this would mean a somewhat less organized route - but hey, isn't designing and iterations always messy?
So instead of the "prized document", I helped developed better access points for the usability data online. While this was centralized, the medium still became the message: the sometimes boring footage where I forget what to say, the analysis spreadsheet that have inconclusive remarks, the emails and forum messages asking the so many questions we have no answers for, the prototypes that *almost* work. I left nothing to the imagination.
In giving my peers access to the work without a filter, the credibility of usability work has increased, the time to deliver the results decreased, and more effort goes towards to the raw work - not to polish it up for presentation.
Indeed, for me at least, the day and age of the slick document has ground to a halt. It's no longer what I aspire to - and here's hoping you do the same.
Showing posts with label user testing. Show all posts
Showing posts with label user testing. Show all posts
Monday, March 3, 2008
Wednesday, January 16, 2008
Empower your team
Do you know what kind of impact you have when you've included your project development team into your user testing? I'm sure not many realize the benefits of this. While I'm sure most researchers, kind of like the scientific type would rather hide in a dark room to do their tests and only give out findings and recommendations later on so that there are no "biases" or outside forces co-mingling to create skewed results, there are better more efficient and effective ways to get the message across.
The goal for me has been to find ways to empower our team. Find ways so that the development team create their own message from what they have seen and experience by watching user testing. No hearsay reports, no convincing, and very little person to person influencing to design decisions.
By watching user testing, the team gain a few things:
1. Perspective - It's no longer by the developers or sales, it's all about the user and how they go about using the application. While some may say the user is wrong, or they're unfamiliar with it, or they're doing things wrong, one cannot argue with their actual mental patterns, their previous experience, make up all their user behaviors up until the time of testing.
2. Thinking towards a solution - the instant the team sees a user have a problem, the team sees ways in their mind to improve the program concurrently with what just happened in testing. By doing this, it takes the pressure off the usability professional and empowers the team with instant information - a catalyst to improvement.
3. Individual contribution to masterminding - This is the last point to this cascade. We all know - hopefully, that masterminding is one of the most effective tools to get to where we want to be instead of where we don't. By masterminding our design solutions and understanding the catalyst in its different facets, the team no longer designs in a vacuum. Also as individuals, there is some self-gratification to a better job done well.
By empowering my team, I've pushed-out the knowledge to create other ideas, not from myself. The team takes ownership and makes these kind of battles more personal. And with it, the combined effort applied is greater.
The goal for me has been to find ways to empower our team. Find ways so that the development team create their own message from what they have seen and experience by watching user testing. No hearsay reports, no convincing, and very little person to person influencing to design decisions.
By watching user testing, the team gain a few things:
1. Perspective - It's no longer by the developers or sales, it's all about the user and how they go about using the application. While some may say the user is wrong, or they're unfamiliar with it, or they're doing things wrong, one cannot argue with their actual mental patterns, their previous experience, make up all their user behaviors up until the time of testing.
2. Thinking towards a solution - the instant the team sees a user have a problem, the team sees ways in their mind to improve the program concurrently with what just happened in testing. By doing this, it takes the pressure off the usability professional and empowers the team with instant information - a catalyst to improvement.
3. Individual contribution to masterminding - This is the last point to this cascade. We all know - hopefully, that masterminding is one of the most effective tools to get to where we want to be instead of where we don't. By masterminding our design solutions and understanding the catalyst in its different facets, the team no longer designs in a vacuum. Also as individuals, there is some self-gratification to a better job done well.
By empowering my team, I've pushed-out the knowledge to create other ideas, not from myself. The team takes ownership and makes these kind of battles more personal. And with it, the combined effort applied is greater.
Subscribe to:
Posts (Atom)