Revamp of our Verify feature in Playbooks
Me (Jade) - Product Designer
Michael Murff - Data Science Product Manager
Brayden - Product Design Manager
Revamp the Verify feature within our Playbooks product.
What is the problem?
There are 2 hovers for the information Verify provides and the information is not straightforward.
What is our goal?
We needed to combine them and make the data easy to understand.
There are two parts to the Verify feature within Playbooks. One was showing the status of a number or email, whether we have verified that it was a good form of contact or not. The second part was not in production yet, but it was to show 3 data points to explain why the number/email is verified or not.
Discuss and Analyze State of Feature
The Verify feature in Playbooks was in play and in use by our clients. There was a lot of positive feedback on the idea behind the feature, but sadly the implementation just didn't hit the mark. I worked with the data science PM and my manager to discuss what it is that we wanted out of the feature. We ultimately decided that we should combine our two hover states into one, and present all that data in the one hover.
Since this feature was already in use and this is essentially a "revamp" of the current design, there wasn't a lot of research to be conducted at the beginning of the project. I jumped into exploring different ways to present this information into one hover.
I met with Murff and Brayden everyday to discuss the progression of the project. I showed them different versions of the design, and from there we revised it until we came to the final design.
The final design was decided after a lot of back and forth discussion. Initially we had talked about having it be as straightforward as V.4 in the above image. However, our data scientist didn't want people to get clouded by the idea of this is "good" and this is "bad", because the purpose of the data wasn't to call out each individual piece of data. What we wanted to show, was that these data points as a whole make up for the status of the form of contact, however to also allow our client to see the breakdown, as the data is useful on it's own.
The final design we should the numbers that make up for the Verify status, but we used signal strengths to show the impact of the numbers.
Defining Signal Strength Numbers
With the signal strengths, we needed to define what the number range was for each bar. For example, how many calls placed would equal a 4 bar strength vs a 2 bar strength? These numbers came from our data scientist, but to help engineering with visuals and for a better talk track when speaking on this project, I mapped out each cut-off point.
UI States and Definitions
Along with the numbers, I wanted to gather all the different Verify states that are possible in Playbooks, and show what they would look like in a hover state for both call and email. This would help clarify any questions our engineers might have as well.