ListenTool is a platform for talent development through continuous feedback. It is a business-to-business product in the Human Resources and Company Culture spaces.
I am currently working on this project as a User Experience Designer, and dabbing a little in the VP of Product space as well. Some of the skills I'm using for this project are user research, user testing, client management, product thinking and wireframing.
I joined this project in the third year of it's lifecycle. This meant that previous designers had worked on this project, and the development team had already established a workflow and ethos.
Therefore, the first thing I decided to do was to learn as much as possible about the team, the workflow and the existing processes. I made it a personal goal to get to know my coworkers and their strengths, so we'd be able to collaborate better.
Being a part of a remote team, I quickly realized that I did not have direct access to the primary users, and the existing definition of the users was too broad to be useful.
This presented an excellent opportunity to conduct some classic and experimental user research. So far, I've conducted surveys and interviews to identify usability issues, focus groups to gauge user perception, and literature review to keep myself updated about the shifting trends in HR. Currently, I'm conducting a user study to measure the offline effects of using the product on teams' work life.
Like most product teams, we have a product backlog that stretches on
for days. I am glad I found myself in a position to work closely with the Product Owner and Project Manager to identify the right problems to solve.
This was easier said than done. The team was operating like feature-factory rather than a research based, user-centric product team. Currently, we conduct research to identify the biggest problems in users' experience, test and iterate our proposed solutions with them, and only then move into development.
Because of the feature-factory like process, the only measure of success for the team was how many stories they completed per sprint. Metrics like value provided, usage times, feature impact, likability were not being measured.
Currently, we establish measures of success before rolling out any new feature, and try regularly follow-up with the users to see if we're succeeding. We also use Google Analytics to measure, analyze and tweak our solutions to better the user experience.
I start with a user experience story about a persona that's based on user research. I discuss this story with the Product Owner (PO) and Project Manager (PM) to assess the its soundness.
After that, I create paper sketches to accompany the user experience story. This gives me an idea about where and how does the interface fit into the story.
After that, I create mid-fidelity mock ups in Balsamiq. These are tested with users, and their feedback is taken into account alongside the PO.
I sometimes use Sketch to turn the iterated mock-ups into hi-fidelity screens to hand them over to the Visual Designer (VD). Mostly, I handover annotated Balsamiq mock-ups to the VD and trust him to elevate to the next level aesthetically.
I am also frequently involved in discussions about the product where I stress the need to have a clear product vision, value proposition, primary user base, content curation and a sales strategy.
Goal setting is an important part of personal and professional development. Keeping this importance in view, ListenTool has a feature for adding Development Goals. The user interface was simple: it had plain text fields that asked users to enter a "Development Topic" and associated "Goals to achieve", and a status selector with "Not Started, In Progress, and Completed" as options.
It is this simple interface that turned out to be one of the problems. It was too simple. When we dug a little deeper, we realized that users were struggling to come up with the right language to fill out the text fields. They were being overwhelmed by the cognitive load, and hence not using the feature at all.
We started looking into how organizations went about goal setting without the help of any online tools. We discovered that goals are usually never fully formed and set in stone, not in one meeting at the very least. Goal setting in most organizations involves a minimum of two people: Mentor/Mentee or Individual Contributor/Manager. Usually, goals are set as a result of a conversation between these two people. This was the key user experience insight that we based our solution on.
We realized that the 'process' of goal-setting must be taken into account when redesigning the Development Goals feature in ListenTool. The conversational element of the goal-setting must not be disregarded, rather utilized in creating an interface that facilitates a user's thought process, instead of overwhelming it.
The redesigned interface can best be described as "a step ahead of a Setup Wizard, but a step behind a ChatBot." This guided interface mimics a typical goal-setting conversation between a Mentor/Mentee or Individual Contributor/Manager. The user is asked for bite-sized information about his strengths, aspirations and where he feels the need to improve. The guided interface takes care to only ask the user to focus on one thing at a time, like a progressing conversation. At the end, the user is presented with a set of draft goals, that he can send to his Mentor/Manager right there and then for feedback.
As a result of the new interface, the number of development goals added by individual contributors in our client organizations went up. Currently, we're using Google Analytics to track where the most drop-offs are occurring during the guided interface, and tweaking the interface accordingly.
ListenTool had been in use at a client organization for two years, yet the client was still unsure about the value being provided to users by the feedback they were exchanging. This uncertainty was making the client uneasy to the point of thinking of pulling the plug.
I met with the client a few times to explore this uncertainty and uneasiness, and discovered the client was actually concerned about the effectiveness of feedback exchanged. i.e. whether the comments being exchanged within the organization were actually helping the employees grow as professionals.
I worked with the client to breakdown the term 'effective feedback' into three separate but related attributes: valuable, insightful, actionable. I, then, conducted a survey of 100 users asking them to rate their received feedback against the aforementioned attributes. I also conducted another survey, and a round of interviews to assess the quality of feedback requests being made within the organization.
The survey results were compiled and presented to all stakeholders in the client organization. The survey found that while the majority of users were happy with the value and insight they were getting from the feedback, the majority did not find it very actionable. These survey results not only put the client at ease, but also gave the client and myself a more nuanced direction to pursue moving forward.
Alongside organizing coaching sessions for giving more effective feedback, my team and I made changes to ListenTool to empower the requestor to make such requests that particularly elicited valuable, insightful and actionable feedback. We created fill-in-the-blank feedback request templates based on popular feedback models, that users can quickly use without needing to know the models themselves.
The initial results of post-release surveys of the feedback templates have been overwhelmingly positive, and the 'actionable' template is the second most used template, right behind the 'appreciative' template designed to get recognition. Users have also mentioned that these templates have saved them time, and helped them get over the fear of not knowing how to think about feedback requests. The client's uncertainty about the product has lifted to a good extent, and is awaiting the next 100 people survey to measure how people's perception of their received feedback will have changed.
This is a project from 2014, right after Google had just released Material Design Guidelines. I remember being blown away by the small interactions they'd introduced, like the floating button '+' turning into a 'x'.
Since this was a college project, our instructors asked us to use as little resources as possible to best emulate the development environments found at startups. These animations were created using a technique called 'onion skinning' or 'tweening' in Sketch.
