In a recent email exchange with a long-time Testuff user, we learned that he wasn’t using one of the main screens in our platform. In fact, he wasn’t even paying attention to that screen. After digging a little deeper, we discovered that several others were in the same boat.
This surprised us given the usefulness of the screen. We thought everyone knew about this option and relied on it heavily.
So what were these outliers doing wrong?
The Road to Software Testing Is Paved with Good Intentions
It turns out that these users weren’t doing anything wrong at all. And the real problem was with our thinking – i.e. hidden assumptions we had brought to the table.
At Testuff, we build tools for fairly specific applications. But we should never assume how end-users will ultimately apply or access those tools. Each user has needs that are specific to him or her. When working in a team, those requirements become even more diverse.
Moreover, habits are strong – and very hard to change once they’ve taken root. How you begin using a tool or platform during the initial stages is often how you’ll end up using it years from now.
This doesn’t simply apply to software testing tools. Early habits often dictate how we approach many things in life.
Just think about all of the screens and options that came with your DVD player. If you didn’t use a given feature in the first few days, there’s a good chance you’re not using it now – no matter how useful or important that feature is.
- Why they use it.
- How they use it.
- What features they like.
- What features they dislike.
- What features they want most.
This type of outreach is terrific because it involves the users and creates an organic community. But communication is also self-serving. As the developer or manufacturer, you learn a lot. By periodically checking in with your community, it becomes easier to develop new features that fit their evolving needs and behaviors.
Generating helpful feedback doesn’t have to involve using the questions outlined above. Open-ended and ongoing communication often yields the greatest insights. For example, you might discover unusual ways in which older features can solve problems you never knew existed.
We’ve experienced these surprise discoveries on more than one occasion.
Thanks to community feedback, we stumbled upon hidden uses in our own platform. These applications weren’t literally hidden of course – they were obvious to anyone who was looking for them. But it never occurred to us that our tool could be used in this manner. And we probably never would have realized it if we hadn’t reached out to our community.
Communication and Incremental Improvements
We’re huge supporters of using crowd wisdom to guide future development and make incremental improvements. The more community feedback you receive, the easier it becomes to prioritize important upgrades. You can tackle those requests that will benefit the greatest number of users or provide the most overall value.
But even when you successfully implement whatever you consider to be low-hanging fruit, you still can’t expect every user to apply these new features or tools as expected.
This is why it’s best to design flexibility into everything you release. As much as possible, try to make sure that:
- Important features can be used in different ways.
- Options are accessible from multiple screens and entry points.
- Users can easily customize sequences and steps.
- Your FAQs are a collection of the most frequently asked questions (and not simply what you assume are the most obvious ones).
- Your product manuals are living documents that continue to evolve as you collect feedback from users.
This all should be accompanied by all of the things that help the users to understand your product and make the best use of it, with your help. Manuls, online-guides, helpfull support, accessible knowledge base, improving the application fro better UI, with an emphasize on intuitivity. You still want to make sure your users first know the in and out of the tool, and only then create their own way of using it.
Turning Misuse into a Valuable Asset
Probably the biggest takeaway is this:
It’s not possible for a user to “misuse” one of your products.
Sure, you can (and should) design your products with very specific goals in mind. But you can’t anticipate every need – or please every person.
No matter what, users will adjust your tools to fit their own needs, workflows, and procedures. It’s a mistake to impose your way of thinking on others. Even if you idiot-proof your design or limit options, your users will still find ways to surprise you.
But by actively soliciting feedback from your community, you can turn those surprise “misuses” into valuable learning experiences. And you can develop even better products moving forward.