Build a foundational understanding of Dashmote's users and their experience journeys as they use Dashmote products.
Audited existing artifacts. Utilized empathy mapping, thematic categorization, network analysis, and user journey maps. Created a new method to quickly sort through large amounts of qualitative data in a group. Validated results by analyzing Dashmote application usage.
We created and validated four personas along with user journey maps. We determined which product areas to focus on in the coming months, and added project ideas to the backlog for front-end development.
Like many startups transitioning from project-based work to a SaaS product organization, at Dashmote we have struggled with building holistic solutions for end users. We were already good at meeting our users' needs project-by-project, but translating that to a product to serve all customers was not yet meeting our standards. To start, we had to build a foundational understanding of our users and their experience journeys as they use Dashmote products.
We faced two main challenges when initiating this research:
What are the personas that represent Dashmote client users? What user journeys occur with each Dashmote client persona?
I led the research for this project and guided my team during workshops to think through each phase of this project. Our team included a Product Designer, Vera (see Vera's portfolio here), a Product Owner, a Frontend developer, and our CTO giving advice during the workshops.
This research took several working sessions and steps to complete. Below is a high-level overview of the full process.
Our first step was to collect all client feedback from the past year. We focused on locating evidence which came directly from clients, and given while they were using our product, namely:
Next, we took stock of the feedback by copying and pasting quotes from all artifacts into an empathy map. We found mostly what our clients were saying and doing, and we avoided making assumptions about what clients were thinking and feeling at this stage. This resulted in over 200 notes collected. We then tagged each note to help frame the users’ points of view as a goal, problem, pain, gain, or alternative to the Dashmote product.
We then distilled the content of all the notes into thematic categories. This allowed us to spot any patterns regardless of where the quote came from. For instance, we avoided grouping content by company or job title of the client who said the quote so that we would maintain a holistic outlook. Furthermore, we would revisit job titles during a later exercise.
Sifting through 200+ notes one-by-one as a group would have been a monumental and time consuming task, so we came up with a modified version of poker to sort through everything within a few hours (across a few different workshops) instead.
Overall, we noticed two main category types:
Since our product is used by groups of users who work together, it was also important to map our users’ relationships to get a sense of our personas in an organizational context. We also wanted to see whether titles and roles told us anything about the personas, for example, whether there were clear groups regardless of what was said.
We gathered titles from each client user supplying notes, then broadly classified the most recurring job titles. For example, we tagged and grouped titles with “digital” or titles with “channel development” in the name. We then ran a network map on the job titles based on these classifications.
We immediately noticed five key groups of job titles emerging:
Most surprising to us was the appearance of the first group of digital and eCommerce-related roles. There was a clear independent group formed here deserving of particular attention when creating personas.
Next, we combined the themes found with the groups identified in the network map. For each group, we connected members of the group to notes they supplied within the content themes. By taking a snapshot of how a particular group from the network connects to the thematic content, we were able to see a holistic view of that group’s goals, jobs to be done, and get a feel for what they think about most of the time during their workday.
For example, we took the group formed by sales, new business, and account management roles, and connected each group member to a note belonging to them within the thematic board. We then tallied up the number of notes within each theme appearing for the group. In the case of sales, new business, and account management, the most frequent theme was sales execution and strategy for field sales. Second came mentions of data integration with their own CRM systems, internal political challenges, and the challenge of understanding and responding to unpredictable market fluctuations. We also noticed themes spread over a tactical perspective but not much appearing at the higher strategic level.
This overview already helped us to shape the understanding of the sales persona. We found that this persona was likely to be a manager because they deal more in tactics and setting the stage for more and better sales rather than pure execution. For example, they would more likely ask questions regarding how to define sales targeting lists or generating more leads in bulk rather than questions about their individual field route for the day, or worrying about sales scripts.
We also found overlap between this sales persona with a potential different persona interested in channel oversight and brand management, which was an indication of a relationship - a colleague might talk about what affects himself and those he works closely with.
Once we completed the same exercise with each network group, we refined the network map to identify our personas’ roles, key goals, responsibilities, and relationships found. We noticed that the channel manager and brand manager, although often two distinct job titles among our client base, showed enough overlapping goals and responsibilities so that we could confidently treat them as one persona for the purpose of building products and features. We decided to merge them and label them as Market Strategists for the time being. Personas which were also present but did not fit well to our current product offering were set aside to the periphery (for example, the Sales Representative).
As a result, we had four personas identified:
Once we had a clear overview of our personas, we started building them out. We first revisited our empathy map to tease out anything related to personal interests, personality, skills, tech savviness, reasons to use and buy our product, and where our personas might get their news. We supplemented our collected evidence by searching through our clients’ LinkedIn profiles as well. In some cases, we collected additional anecdotal evidence from Customer Success Mangers or Project Managers based on their past experiences with particular client users. In any case, we only made inferences on the personas based on the evidence found in this period, and avoided using our own personal heuristics to guide our impressions.
Overall, it was important to us to make our personas seem like real people to enable better design thinking later on. In other words, it’s easier to build products for people we feel we know rather than data points like “female, age 18-40, responsible for sales.” We therefore spent some additional creative energy in finding pictures and names to fit our ideas of each personality.
For the personas, all that remained was to summarize them in an appealing and approachable way so that all Dashmote employees could use them.
We mapped out the design of the persona views, including which info we wanted to include. Most sections were standard to persona views, but we opted to add particular sections to make the personas more useful to Dashmote users. For example, we added:
Our Product Designer finalized the personas in Figma. We ultimately included an organigram overview, plus a 1-page intro to each persona along with a second page outlining each persona’s primary goals, problems, pains, and alternatives. Our final result was a refined list of four personas:
Once we had the personas fully mapped, we tackled user journeys for each one. Instead of generalizing each persona’s experience, we chose one particular goal and problem to solve for each persona, then mapped out the experience for that persona attempting to solve their unique problem using the Dashmote tool in its current version.
Our steps went as follows:
For triggers, we thought about what brings the persona to open the Dashmote tool. For instance,
For this phase, we mapped the steps a persona takes to find what he/she is looking for. We also considered any pains she may experience along the way and what specific click routes she must take given our current product design.
Most important for this phase was to understand what the reward looks like, since the reward may vary depending on the persona. For example, although Ava the Market Tactician may require highly detailed lists and data, Alexandria the Commercial Executive may be happy with just the topline metrics. We considered questions such as:
We added this phase to our own application of the Hook Framework so that we could pay special attention to our users’ collaborative efforts. The more our users share Dashmote data among their teams, the more use they get from it as a group, and therefore the more they may end up investing more time in the tool. For this phase we considered:
Finally, we considered how the persona might be motivated to return to the Dashmote tool. For instance,
For all phases, we zoomed out to take note of how the experiences within each phase might leave an impression on the persona. For example, phases showing several pains might be more frustrating than phases in which the persona reaches his/her goal relatively quickly. Although some sentiments came directly from our evidence in the empathy map, others we inferred from patterns appearing in the user journey.
Once all journeys were mapped out, we added them to our collection of personas in Figma and published them to our internal company wiki.
Lastly, we validated whether the evidence also matched what we were seeing in real product activity. We took a quick sample of the 10 most frequent visitors in the last 30 days and found:
From this we could be reasonably confident that our personas were indeed representative of our primary users, and that although we mostly had evidence from economic buyers of the tool, that these buyers were also frequent users themselves. This indicates that we are already gathering feedback from the right people.
We set out to discover Dashmote personas representing our main users, and we ended up with four. We also now had mapped user journeys for each persona. Since we used evidence from all clients across projects, we were also confident that our personas captured the holistic view of our client users.
This research allowed us to test assumptions about our personas, namely that there was an executive type, a sales persona, a channel management role and a brand management role, and that we had some users who were analysts or marketeers but with whom we did not engage. From this research we uncovered supporting evidence for
In addition, we discovered that our personas’ user journeys followed a similar pattern: although they began on a neutral or positive note, they generally suffered a poor experience towards the end of the journey, following the rewards phase. This meant that although our users could find the data they needed, there was little they could do while still in the Dashmote tool beyond downloading it to local drives. Taking action with Dashmote data therefore had to occur using external tools, and there was little to entice the user to return to the Dashmote tool to continue the experience.
Overall, this pointed to areas of improvement we could add to our product roadmap in the coming months. For instance, ideal projects to improve the share and invest phases might include:
This research ultimately re-framed our approach to developing products for our clients. Much of what we offer at Dashmote is the collection and compilation of data, but enabling users to actually make use of what we were providing them was the challenge we were trying to overcome. With this research we had a better grasp on who our users were and what they were going through, so we could start designing smoother and more pleasing routes to give them access to their data.
This user research would not be the definitive understanding of our users. We aimed to continue validating our learnings through further research in the following year, for instance by asking qualifying questions to new clients. We also aimed to connect more often with end-users rather than mostly economic buyers so that we could enrich our user journeys with more day-to-day activities and learn how the Dashmote tool fits in with the general user’s day. We expected our users to be dynamic and would continue learning from them as we developed more products.
.png)
