Context
Contextual product improvement conversations.
This concept was developed in a 'scratching your own itch' way, though it's an example of how I typically relay the story of a problem and what we could do to overcome it
The audience is management, where I'd pitch the concept to gain support and seek additional time to conduct user research and validate the problem is sufficiently real enough to warrant solving. So in some respects, this is a backwards approach to your research spawning new product ideas, something clearly required when your domain knowledge is more limited.
Here's the story:
------------------------------------------------------------------------------------------------------------------------------------------------------
The user (in green) has a problem with our software.
------------------------------------------------------------------------------------------------------------------------------------------------------
Which likely means they’re off to our website searching for our support details, juggling tools so that they can submit a support request in whatever way we’ve implemented.
They need to describe the problem, maybe attach screenshots or log files to an email and wait for a response. Maybe they call us too.
The thing is, this is all using other tools outside of the product they’re in.
It’s a hassle:
------------------------------------------------------------------------------------------------------------------------------------------------------
Once the support person (in red) receives the message, they need to translate that back into where the user was and what they were trying to do.
Here, they might submit the problem into a bug tracking system or provide support back via email/phone.
Mostly, this activity is invisible to the dev team.
------------------------------------------------------------------------------------------------------------------------------------------------------
Where bugs are recorded, the development team review them, but need to rebuild that context as to to where and when it occurred in the app to fix it.
------------------------------------------------------------------------------------------------------------------------------------------------------
Maybe at some point in the future the user will be contacted about a fix, or at the very least, informed of whether a fix will happen.
All of this communication happens outside of the context of the original app that caused the user to contact us.
------------------------------------------------------------------------------------------------------------------------------------------------------
Some apps have built-in feedback mechanisms, some of which might just fire-up an email for the user to describe their feedback to the dev team.
------------------------------------------------------------------------------------------------------------------------------------------------------
Which might start an email conversation outside of the tool for greater clarification.
------------------------------------------------------------------------------------------------------------------------------------------------------
A more advanced feedback mechanism like UserVoice might allow them to add their support to previously submitted ideas or add new ones. Again, all collected into a system outside of their current context, requiring that they need to describe what they mean.
------------------------------------------------------------------------------------------------------------------------------------------------------
So let’s imagine the same scenario, though instead they’re using Context.
All disciplines in the company have access to Context, bringing everyone closer to real user feedback and easing internal collaboration.
------------------------------------------------------------------------------------------------------------------------------------------------------
When a user encounters a problem, wants to give some feedback or is maybe just stuck, they can note this in the app itself via some kind of overlay.
It’s a bit like sticking a post-it note onto part of the app, on a specific page.
This is visible to us as soon as it is posted.
------------------------------------------------------------------------------------------------------------------------------------------------------
What’s cool is that we could directly respond to that message in Context.
No other tools are involved.
Everyone’s context remains where it’s useful.
This could either be in an instant chat kind of way, or in an asynchronous way where the user would be notified that their message has been responded to.
We could nudge users through difficult set up procedures.
------------------------------------------------------------------------------------------------------------------------------------------------------
Feedback from users is aggregated on our side so we can see the most problematic areas of our apps.
On our side, we have powerful filters to quickly let us see new notes, notes of a specific type, resolved notes etc etc.
------------------------------------------------------------------------------------------------------------------------------------------------------
During development it’s much clearer which parts of our app we should be focussing our attention on.
Each day, the latest feedback and bugs can be reviewed during a stand-up to help prioritise and give teams direct contact with their end users.
Everything remains in Context.
Need usability test participants who have tried to use a feature? Now you can contact them.
------------------------------------------------------------------------------------------------------------------------------------------------------
Feedback could be submitted by the user as:
Bugs
I’m confused
Opinion
Hate this
Love this
…and our relevant teams could filter these so that, for example, “I’m confused” feedback is picked up by UX.
------------------------------------------------------------------------------------------------------------------------------------------------------
Whilst being a tool for teams to directly engage with their users, it also works as a dashboard for management to quickly gauge how the tool is performing.
How much do people love the improved feature?
Are less people getting stuck at this point?
------------------------------------------------------------------------------------------------------------------------------------------------------
Internal teams can use Context too without any involvement with end users.
For example, they might be working on early prototypes or Balsamiq Mockups, and yet still be able to utilise all of the same annotation, filtering and work assignment functionality.
------------------------------------------------------------------------------------------------------------------------------------------------------
This isn’t just a tool for us, we sell the platform.
It’s easy for us to dog food this and we know some of the problems deeply.
Even in a limited form, it’s useful.
It’s one platform for everyone who needs to engage with users, eg support, product management, UX, tech authoring, development and test.
I see it as a contextual version of UserVoice, Trello, SupportWorks, Instant chat and Jira all rolled into one. That might sound huge, but it’s easy to see how this could start small and accommodate different use cases over time.
Some features just wouldn’t be necessary too, like attaching logs or screenshots as we’d already have these in Context.
