Domo Personas
What do Personas do for your design anyway?
Ok haha JUST KIDDING the real question is, what does your design do for your Personas?? If you don’t know who you are building your product for, then you are not going to build it with them in mind. And if you don’t build it with them in mind, well…they won’t buy it.
“Let’s be real — the sales team skips things. Because they know which parts of the product are not useful or attractive to customers. This is great for the design team to know, so we can either improve that experience to make it marketable, or cut it out altogether and reduce the cost to upkeep it.”
This was a passion project of mine. Since Domo was started, believe it or not, they have not had personas to design for. I and other designers noticed many problems that arose from this — including upwards of 7 full iterations on projects, because of miscommunications about what it should contain. Because although Domo was trying to be the cool item that appealed to everyone and they didn’t need personas — that simply wasn’t realistic. While Domo is meant to be for CEO’s to be able to see exactly what’s going on within their company, someone still has to compile the data, and the app should be a great experience for those people. And if Domo wants to make BIG money selling to an entire enterprise, then they also need Domo to be useful and geared toward the workers below the CEO’s and managers.
Now obviously, we have done quite well without clear personas up to this point, with a quality product still being built — but a lot of money has been poured into projects that were never seen by customers. Because being built for “anybody” really means, it is built for “nobody”.
Because being built for “anybody” really means, it is built for “nobody”.
So with no further ado, here is a compilation of the research and visuals I made and presented to the UX Design team, which they happily accepted and adopted.
Obviously, I started with research. Since I knew for CERTAIN one of our personas was an executive, ideally that is who I would have interviewed. However, executives don’t tend to have a lot of time to spend with people like me — so I started within Domo first (which I knew should have a great deal of data on them anyway, due to the nature of the product).
Below are two of our top-most customer support people, whom I interviewed separately from each other, and compiled their data.
I explained to these gentlemen that I was attempting to learn more about our users, in order to in the end, make five different personas that the team could design for. This got them thinking, as I hoped it would, about what different personas they had noticed in their job each day.
Below is the first question I asked. I wanted a general idea of the problems people were experiencing, and who was experiencing them. Their job title was the thing I most wanted, and what was most difficult to get.
Connectors are what allow you to upload your data from a source like excel, cards are what displays the data, and data manipulation, well, you get the idea. It’s how you tweak the data in order to present it.
The reason for this is not that mobile is less popular than the web version (though it is, fine), but because you cannot create any content on mobile — it is only for consumption. Therefore, if something is broken on someone’s phone, it is still a web problem.
I thought it would be telling to have our own people, who use and teach about Domo every single day, to tell us what they struggle with, and what users struggle the most to learn.
This Domo card was a huge asset that the design team had not previously known about. All of the data on incoming calls that we could ever want, that proved very useful in developing the final personas.
Next, I interviewed some of our sales people.
Because they have different jobs and interactions with customers, I asked them a different set of questions.
While the Customer Support was able to give us raw data about WHAT our customers were doing, the Sales team gave me more insight on what drove people to buy or reject Domo in the first place. They could tell me more about WHY the customer was doing what they were, which was as you can imagine, also incredibly useful.
Don’t want to look stupid: May have already purchased something, and don’t want what they have chosen be upstaged by Domo. (They want to bring the tech to the company, not the other way around).
Security: They are hesitant to put their data in the cloud.
Familiarity: Often Analysts are married to products that have been around for a long time. Tableau, our main competitor, gives their program to college students free, so that they prefer their program when they get to companies.
Personal Pride: Offended that they feel the company is going around them to get Domo.
These issues, while they can be explained by the sales team, could also be supported by design that emphasizes these points.
Let’s be real — the sales team skips things. Because they know which parts of Domo are not useful or attractive to customers. This is great for the design team to know, so we can either improve that experience to make it marketable, or cut it out altogether and reduce the cost to upkeep it.
The items on this list stood out to the salesmen as the weak parts of the Domo product.
Buzz: They usually have a communication system in place already, and would like to avoid the cost.
Projects and Tasks: Same as Buzz
First 6 items: Launcher, publications, report scheduler, etc. which all seem like very specific use cases and should maybe not be first on the list.
Like the customer support team, the sales team spends a lot of time with Domo, and a lot of time with our customers. They can tell us what they want, that will make customers happier. Which will make everyone happier.
Stories: The sales team is very excited about the interactivity that stories is going to afford them. Having data is a great thing. But having that data presented by someone who compiled it and understands the story it is telling is better.
Predictive Graphs: Forecasting based on historical variables and inputs, also current variables and inputs. Would like to show what you can do now to affect the future currently predicted. (So Insight driven design)
Head of Domo University
Focused on helping customers learn how to use Domo.
Domo University/Domo Learning creates tutorials on the Domo processes for customers. They are not even located in the same building as Product, including the designers, which means we almost never communicate with them, which is unfortunate. From them I learned that there are incredible resources for users to learn how to use Domo (it is very complicated, because it is such a huge product). But unless the content has been dowloaded, the tutorials do not show up in search. Therefore, if a new user types “tutorial” into the search bar in Domo, nothing shows up. Oops. That alone shows the massive disconnect between the two of our teams, that needs to be mended asap.
So after getting a massive list of all the training available, I created the following visuals for personas, and their correlated Domo University courses.
With this data, and these primary personas outlined, I hope it is easy to see how much easier the product would be to design. With the users’ basic goals and different job descriptions listed, we are no long guessing, and we as designers will be much better able to address their core needs. In turn, this means keeping the customers we have, and being instrumental in converting new ones.
