I was thinking about my last few posts this week and I recalled a story that may help in my point.
Background: I send a short monthly newsletter to all testers at the company. Other discipline owners (e.g. my counter part in development or program management also do this for their disciplines). We wanted to make the engineering excellence "brand" more consistent, so an artist in marketing created a "template" that we could all use for our newsletters. This is where the "experience" story begins.
The template was emailed to us as a Microsoft word template along with "installation" instructions. I don't have the exact mail handy, but it went something like this.
My initial reactions were:
The instructions went on to say:
How to create an email newsletter:
Again - I'm not an office expert, but I knew that using outlook stationery was a much better solution. I also discovered that by using the above method, my newsletter appeared in inboxes as having an attachment (due to embedded art). I hate getting email that is marked as having an attachment, but doesn't really have one.
Anyway, I made some tweaks to the original word template, saved as a a web page (outlook stationery uses .htm files for its template format) and saved it to the appropriate location. Now when I create newsletters, I can stay entirely in outlook, and as a bonus, the mail doesn't show up as having an attachment.
I was able to "fix" everything so that it worked optimally, but my remaining thought was that the artist doesn't have a clue how Windows or office works.
Then I thought - why should they? I'm not a designer, nor am I a usability expert, so I won't speculate on how these scenarios could be made more simple or intuitive. All I know is that it's harder than it needs to be despite the core functionality being perfect.
Alecha would have said something about this. She wouldn't have just said "I think this is too hard - we should make it easier". She would have gathered data from focus groups, newsgroups, and CEIP to show how thousands of users struggled with the same problems. Then she would have identified other areas of the product line where similar errors may occur - then she would have worked with the entire team to make sure similar issues didn't occur again. Alecha is much, much more than a great "bug finder" - she's also a researcher and analyst that influences an entire product line.
And she's great at finding bugs in customer scenarios.