UX Lead, 1 PM, 3 frontend,
2 backend
Research, User Testing,
Prototyping
Sketch, Invision, Illustrator,
Abstract
Digital Feedback lets users create feedback programs, targeting their websites or apps. They can create custom triggers to reach their customers in any way they want and in any context they want.
In todays competitive market, customers have certain expectations. In order for companies to meet those expectations, they are required to fully understand the customer needs. Asking for feedback in a given context allows companies to verify whether they meet expectations or not.
The first step was to understand who would use the tool and what their needs were.
Speaking to some of our clients, it came clear that a big part would be technical people, not afraid of writing scripts. Starting by addressing that persona was natural, from both UX and Developer perspective.
Our in-house tech support had helped clients creating similar solutions in the past, using an older system. Running frequent focus groups with them, helped us better understand who we were making this product for and what they were missing and what they might need.
We quickly realised that the users would need to customize and write scripts to create the triggers and that they needed an easy way to connect these triggers to a website.
The task that would slow the users down the most was building the scripts and/or go back to old solutions and copy them. This led me to start mapping out the most commonly used scripts and how to allow for the least amount of configuration before getting it to work. In addition, I wanted to allow the users to save their own scripts to access them when creating new programs.
On top of running frequent Focus Groups with our in-house users, I also ran user tests for specific features. I did this remotely, screen recording over Skype, using predefined task protocols. I also decided to have the PM and one developer on the line, just to make sure we all understood pain points and also for the developer to help out if there were technical run-ins.
It was never our intention to leave it at being a script only solution. Both from looking at our own client needs and through competitor analysis, it stood clear that a UI based solution would also be needed in order to cater for the whole user base.
There was no way around the need for triggers and there was no way around the triggers being based on custom conditions. The challenge was to offer scripting abilities to users who were afraid of scripts. This led me to start exploring condition builders.
UI based condition builders have a tendency of quickly getting too verbose. We needed a solution that serves complete customisability but to the extent needed for individual cases. Hence, we decided to solve this by allowing our in-house technical support (or clients with both technical and UI needs) to easily build custom UI’s for the conditions needed.