Protecting Awesome User Experiences
I had the honor to visit an office I'd never been to the last few days. I met some people who not
only want to work with my team, but are willing to train and mentor us in something.
They also understand that web creations do not maintain themselves and still remain relevant. The important data is the data added by humans. There is information everywhere, but what do we care about? We care about things that make us feel and think.
I gave a short presentation in a meeting about collaborative testing. I showed one way we represent an overview of a path through multiple applications in complex scenarios. We showed areas where there were some problems, areas where there were serious problems, but we could work around it, and areas where we were totally blocked from completing a task during the collaborative testing. I then told them that in representing it this way, we just weren't good enough. We aren't representing the experience. In order to do that, we must also show what things were delightful. What should we "not mess with"? Just as software can need improvement, I believe it also needs wildlife preserves. If it is something so delightful that it is the only reason many users enjoy it, please, just leave it alone unless that changes. It is fine to add to that. Maybe new options, but do NOT change the default when it is brilliant. The team I met with contributed many ideas about this and they took my overview to play with it. They had never even seen the overview before and thought it was great even without the missing part, but they liked the idea of seeing both.
I'm not sure why we have been ignoring the opportunity to provide this data. It is a huge part of overall quality. Testers, managers and developers assume that if it wasn't fantastic, bugs would be written against it. I've tested some very stable code for a feature that sucked so much to use that I met a loyal customer who was using a script to work around using the feature entirely. Software users ultimately will provide some of this data, as will the market and research. However, as a tester, why not share this critical information? I think it is because it is subjective, and so often rejected as information of value. Collaboratively, however, if we agree on what the top 5 delightful things about the software are when we use it, our odds of predicting user reaction improve dramatically.
I know I harp on this collaborative testing, as it is my passion, but we are getting better at finding the dull subjective data. Does it work as designed? Does it do more than it was designed to do? These questions can be answered with "Yes" or "No". These are things that can be determined with automation.
How do I feel about this software? Is it just fine if this one feature is mediocre? What is the worst thing about using it? What things make me excited to use this? Is it just sort of good, or does it thrill me to the point I am going to tell someone else? These are the questions I want to help answer with collaborative testing.
Currently, the person who writes the most automation in the most languages wins a testing job. I know that phase will go on for years. What then? Where are the thinkers? Where are those with the passion to answer the more subjective questions quickly and with accuracy? I hope they are on my team, coding just enough to get past the trend, using any buzzwords they have to.
only want to work with my team, but are willing to train and mentor us in something.
They also understand that web creations do not maintain themselves and still remain relevant. The important data is the data added by humans. There is information everywhere, but what do we care about? We care about things that make us feel and think.
I gave a short presentation in a meeting about collaborative testing. I showed one way we represent an overview of a path through multiple applications in complex scenarios. We showed areas where there were some problems, areas where there were serious problems, but we could work around it, and areas where we were totally blocked from completing a task during the collaborative testing. I then told them that in representing it this way, we just weren't good enough. We aren't representing the experience. In order to do that, we must also show what things were delightful. What should we "not mess with"? Just as software can need improvement, I believe it also needs wildlife preserves. If it is something so delightful that it is the only reason many users enjoy it, please, just leave it alone unless that changes. It is fine to add to that. Maybe new options, but do NOT change the default when it is brilliant. The team I met with contributed many ideas about this and they took my overview to play with it. They had never even seen the overview before and thought it was great even without the missing part, but they liked the idea of seeing both.
I'm not sure why we have been ignoring the opportunity to provide this data. It is a huge part of overall quality. Testers, managers and developers assume that if it wasn't fantastic, bugs would be written against it. I've tested some very stable code for a feature that sucked so much to use that I met a loyal customer who was using a script to work around using the feature entirely. Software users ultimately will provide some of this data, as will the market and research. However, as a tester, why not share this critical information? I think it is because it is subjective, and so often rejected as information of value. Collaboratively, however, if we agree on what the top 5 delightful things about the software are when we use it, our odds of predicting user reaction improve dramatically.
I know I harp on this collaborative testing, as it is my passion, but we are getting better at finding the dull subjective data. Does it work as designed? Does it do more than it was designed to do? These questions can be answered with "Yes" or "No". These are things that can be determined with automation.
How do I feel about this software? Is it just fine if this one feature is mediocre? What is the worst thing about using it? What things make me excited to use this? Is it just sort of good, or does it thrill me to the point I am going to tell someone else? These are the questions I want to help answer with collaborative testing.
Currently, the person who writes the most automation in the most languages wins a testing job. I know that phase will go on for years. What then? Where are the thinkers? Where are those with the passion to answer the more subjective questions quickly and with accuracy? I hope they are on my team, coding just enough to get past the trend, using any buzzwords they have to.
Good call - a bug illuminates code that fails to work. There is no current way to point at a feature that fails to delight.
I know I certainly have tried, and been advised that I was requesting a new feature, and the company would consider it... someday. Perhaps. And I think, before I hung up the phone, I heard the lid of an ancient dusty crate closing on my input.
It's an admirable thing, to champion the hard-to-quantify "feature-richness" of software over the current developer-focussed "code robustness" concept of software quality. Go, you!
Reply to this