Like Christmas Morning! I love my job today.
I got up at 6am today so I'd be ready for today. I had emails in to my colleagues in India clarifying something about the builds I needed to know and got a very thoughtful and helpful response. Today kicked off the very first cross product workflow testing of this product cycle! The setup is all automated on the client side and I'm working over the next 4 months in that legendary spare time I'm rumored to have to automate the creation part which I'm doing manually. The people participating are great thinkers, have decades of experience as a group, and I have much respect for them. They care about testing end-to-end scenarios and reporting back on usability.
This time it feels even better than ever to start my testing engines. It makes every conversation where a person just "doesn't get it", every difficulty getting setup where it feels like herding cats, every conversation I've had with other people who feel like they should be the top priority and direct all of the testing that is done, every assumption that the reason for confusion is somehow communication on our part is all well worth it just because this testing is happening at all. Less often and with fewer resources than I might wish for, but it IS happening and that is a very exciting thing. That is worth every downside. That makes my entire year.
The thing that most people don't understand is that coordinating testing is much harder than working on one product or technology. The planning is insanely complex. Talk about stakeholders! It's a conglomerate of stakeholders and ultimately "the software user" is the most important stakeholder, but not everyone agrees on which customer is important. It's the ultimate test of managing up, down and sideways all at once.
While most people involved in software that I know will claim that user focus is important, when it comes down to making the tough business decision to slip a date, allocate resources, or follow the advice of a user study rather than design what engineering wants to make, you find out just how important it is. The truth of priorities comes down to the question of, "Is it funded?" Companies vote for which customers are important by investing time and money. In testing usability we try to report back what they are getting for the investment, both in the new user and the power user scenarios.
It's tough to explain when someone who is very focused on their particular product asks what is in it for them if they choose to participate in collaborative testing for the user experience. It seems very flippant to answer sincerely. There is nothing in it for you personally unless you use multiple products or a majority of your users do and you care about their experience. Immediately there would be no gain, because you can hit milestones more quickly by only verifying that you match the spec exactly and never looking at the bigger picture. The "just keep swimming" mantra can be comforting and work well, but I'm inclined to think looking around at where you are swimming is also helpful. However, you could also see no changes whatsoever to the user experience, but gain knowledge of what users are considered a low business priority despite all rhetoric.
I very much enjoyed reading this article although the more scientific among you may not delight in such emotional prose. What is in it for you if you test for the user experience? Well, possibly nothing. It may change absolutely not one decision that is made for the software. It is quite possible that the decision will be made that the experience is "good enough" or that the shareholders matter more than the users, so while it matters, it doesn't matter enough to inspire change. The value can't perhaps be easily broken down by the bugs found, the changes brought to fruition, or even the number of people who learned something new. The difference is you are aware you have a choice, and you won't be asking "What the _ is water?" The only reason to invest your time and energy in such a testing effort is that you believe a larger customer perspective would be of value. If you don't value that, it would not be a good use of time, because it isn't likely to gain you the accolades or money that a higher percentage of code coverage would.
This time it feels even better than ever to start my testing engines. It makes every conversation where a person just "doesn't get it", every difficulty getting setup where it feels like herding cats, every conversation I've had with other people who feel like they should be the top priority and direct all of the testing that is done, every assumption that the reason for confusion is somehow communication on our part is all well worth it just because this testing is happening at all. Less often and with fewer resources than I might wish for, but it IS happening and that is a very exciting thing. That is worth every downside. That makes my entire year.
The thing that most people don't understand is that coordinating testing is much harder than working on one product or technology. The planning is insanely complex. Talk about stakeholders! It's a conglomerate of stakeholders and ultimately "the software user" is the most important stakeholder, but not everyone agrees on which customer is important. It's the ultimate test of managing up, down and sideways all at once.
While most people involved in software that I know will claim that user focus is important, when it comes down to making the tough business decision to slip a date, allocate resources, or follow the advice of a user study rather than design what engineering wants to make, you find out just how important it is. The truth of priorities comes down to the question of, "Is it funded?" Companies vote for which customers are important by investing time and money. In testing usability we try to report back what they are getting for the investment, both in the new user and the power user scenarios.
It's tough to explain when someone who is very focused on their particular product asks what is in it for them if they choose to participate in collaborative testing for the user experience. It seems very flippant to answer sincerely. There is nothing in it for you personally unless you use multiple products or a majority of your users do and you care about their experience. Immediately there would be no gain, because you can hit milestones more quickly by only verifying that you match the spec exactly and never looking at the bigger picture. The "just keep swimming" mantra can be comforting and work well, but I'm inclined to think looking around at where you are swimming is also helpful. However, you could also see no changes whatsoever to the user experience, but gain knowledge of what users are considered a low business priority despite all rhetoric.
I very much enjoyed reading this article although the more scientific among you may not delight in such emotional prose. What is in it for you if you test for the user experience? Well, possibly nothing. It may change absolutely not one decision that is made for the software. It is quite possible that the decision will be made that the experience is "good enough" or that the shareholders matter more than the users, so while it matters, it doesn't matter enough to inspire change. The value can't perhaps be easily broken down by the bugs found, the changes brought to fruition, or even the number of people who learned something new. The difference is you are aware you have a choice, and you won't be asking "What the _ is water?" The only reason to invest your time and energy in such a testing effort is that you believe a larger customer perspective would be of value. If you don't value that, it would not be a good use of time, because it isn't likely to gain you the accolades or money that a higher percentage of code coverage would.
Comments