Mind The User: Hotjar
This interview is the first one in my series called “Mind the User”, where I explore companies that build great products through user-centered design. I interview people who believe user-centricity can drive competitive advantage and change industries or communities.
In just 2.5 years HotJar has disrupted the site feedback and optimisation market. Its focus on improving value for the user, ease of use and affordability made it the go-to website analysis tool for small companies and enterprises alike. I have been using it for over 2 years for various projects, both agency-side and in-house. It seemed amazing to me that I can quickly gather very rich data about the website, which was my secret weapon when discussing priorities with stakeholders and showing what doesn’t work.
As Hotjar’s user, I knew they gather feedback through polls and surveys on a regular basis and I learned a great deal from just observing how they do it. That’s why I decided to interview David Darmanin, Hotjar’s CEO and Co-Founder to explore how important user-centered design is to them in building Hotjar. Creating a tool which simplifies quite complex data in a very user-friendly way is not a stroll in the park, but a giant slalom between the competition, the user expectations and the learning curve of a young organisation. What’s even more interesting about HotJar is that the whole team is spread around the world, working remotely.
I have been using Hotjar for quite a while on different projects. It’s a very well designed tool and it seems to be very user-centered, minimalistic — it’s not overloaded with features. How do you manage to facilitate user-centricity in your organisation?
We were focused on receiving correct data from the start. We needed to be very careful in what do we do. Because of that we needed to be very ruthless in the way we prioritise and how we approach the work — being as iterative as possible.
Luckily, from the beginning with HotJar we were very agile and used this continuous improvement model, so at least we were well trained to deal with limited resources. Having said that, I don’t know any organisation or any CEO who says “We don’t have the resources problem.”
A lot of our success comes from the fact that we are very customer-, user-centric and obsessed in the way we collect data. (…) I think we are very knowledgeable in terms of what we need to work on, but getting there is our biggest challenge right now.
How do you make sure that not only the design team, but also marketing or engineering teams have knowledge customers? Is user-centricity present in the whole company?
I’d like to think that everyone understands it in the company. I think it’s used in multiple areas. The four pillars of the company: Marketing, Customer Experience, Product and Operations. Obviously, Product runs that way, but I’d like to think Customer Experience also thinks that way.
Our idea of support is not having a group of people so we throw bodies at the problem. Instead the whole Customer Experience team has what we call a “productisation” function. So our Support’s function is dual. One is obviously react and reply to questions and build better documentation. Then also on the back of that make product suggestions, changes and hypotheses so that we can eliminate this conversation happening in the first place.
(…) We use a model called Product Cases. So we’re constantly identifying opportunities and then the team does a write up to product, saying “Here is what our users are saying, this is what we observed. Here are suggestions and thoughts”. The product team might dig deeper and find another solution, but at least they are setting the tone of what we should do.
And this approach actually, towards delivering a great experience has also impacted the choice of the tool we use. Initially, for the first 2–3 years we used Intercom, which is great, because it is an amazing experience for the user, because it is very easy to use. However what we actually found was it was hindering the process of having a feedback loop back to Product. We’re actually in the process now of moving over to Zendesk, to a ticketing system, which I thought we would never do because we always prided ourselves for being in the product, communicating. Our users are confused, because they think Intercom is a chat and they’re disappointed. It is also really difficult with Intercom to get stats about our users and what we can improve. I’d like to think that this change is going to make us much more agile in terms of identifying opportunities. (…) Originally we got a Trello board and then put what people were saying in Intercom in there. But as we scaled up to thousands of conversations per month, that doesn’t scale as well.
And on the marketing side we pride ourselves on this idea “good is enough — don’t aim for perfect”. When you look at our site, our guides and lot of our pages — they’re far from perfect. It’s very easy to look at all the companies — Intercom, InVision, Hubspot and say “Oh my god, our stuff doesn’t look as good”. But it’s a mistake, because they are on a different stage than we are. They have 4–5 times more people than us I think we’re remaining scrappy — get something out, see where the value is for users, ship on that and improve over time.
Is the whole team then involved in research and design processes?
Definitely. We developed our only way of communicating, which is obviously not easy while working across territories. Well, the whole Product Team is in the same time zone, which is important. The marketing and customer experience teams overlap with different ones.
When it comes to the design process, one principle which we apply the most is “get feedback early”. (…) We’re lucky and unlucky that the team is so small — up until a month ago we had only one person doing all the design thinking at work. It obviously made it very easy to go out and collaborate with the team, but we have 3 people now, so it’s starting to grow. It hinges on “get feedback early” — it’s both the team and our users. When you’re in the office, you could do quick prototyping and involve the team, involve customers. We do it, but in a more remote fashion. Again, we’re lucky to have that many customers.
And we do it not only to build the product. A perfect example is when we built a sales guide for small startups. What we did, we used our tool called Feedback (it’s this widget you put on your site and people can highlight and leave comments). We invited people to participate and help us with this guide. Rather than putting it in a Google Doc, after a few stages we put it online live and we had people use it and leave feedback. We had about 400 contribute with ideas and suggestions so that we could work on the content in sync with people as they gave feedback and it allowed us to create a much better guide. It’s similar to most of the changes and designs we do in the product.
You are very deliberate, or obsessed about the limited features you ship, which I imagine must really hard among all the user requests and competition pressures. Sometimes you do conduct a sort of a soft launch of new features to a limited user group, right?
In many ways, that’s the approach the marketing team have taken. With Product it’s much more starting with internal stakeholders and then moving to customers very early on. So typically we do the research stage very well — a lot of it centres around using Hotjar itself. We ask questions, we observe how people are behaving. That leads to hypotheses, then we create this initial version, which typically go for the feedback to the team, and then it moves towards a more fleshed out version. That leads to scheduling calls with our customers and then we come back and we regroup. Typically we do another round internally as well. This is the point at which we then go out to our users and customers with this kind of soft launch or a beta release.
Very early on we built a functionality into HotJar which enables features on specific accounts, so that we can get something out in the wild, but only for people who requested it. We’ve had features, which have been in this testing for months though. So it’s not something we’re happy about, but we’d rather be obsessed, as you said, and have something battle-tested instead of rushing. There is something that we’re working on, the filtering system for the recordings. It’s quite a big change, so we’ve used what we call a feature flag, so we went through all these stages I discussed before and then we made it available only on our accounts, so we made our teams use it. That allows us to build up some time, get some feedback and now we’re slowly making it available to the users, to see how it affects the usage of our product as a whole.
One of the toughest questions in product development. Have you ever removed a feature which was not popular?
Not yet, but let’s just say it’s something we discussed quite often [laugh]. Not yet. The reality is — because we’re so much strapped for resources, everything we’ve released has been discussed at lengths with our users. Most of them are things that they asked for. But there are a couple of features that we released at the very beginning, which we questioned “Should we have done this, or should we have been focused on the core?”. Form analytics being one of them — it’s something that we released very quickly, as it was something that we promised. It was something that we didn’t do very well and we didn’t have the time to go back and do better. It is something there that is not being used a lot, so sometimes we say “Maybe we shouldn’t have released it?”. I’m sure we’re going to come back to this conversation quite soon.
Before you started designing Hotjar, what sort of research have you run to understand what needs to be built, what were the user needs?
It’s a funny story there. I used to work in a conversion rate optimisation firm. I did it internally within a firm before that as well. I’ve been using these tools for a long time. And it’s interesting that over time, obviously, I developed an opinion over what works and what doesn’t. When I was working with bigger clients when I was a consultant, it was interesting to see their interpretation. Interestingly, we were a group of 20 consultants from all over the world and working in a lot of different industries. We had conversations now and then, where we would say what tools we would find to be the most useful, the ones we get the most value out of for our customers. And we’d list them together and it was interesting to see that the results were similar across all the consultants. And they were not the results that you’d expect them to be. So on the very top there were qualitative tools. So we’d say we get much better results from a poll, asking a questions, comparing that with for example recordings, as opposed to using just heatmaps.
So a lot of the decision-making process of what to put in HotJar was made by myself, having experienced that for decades. To put it in other words, we were only obsessed about things that we knew to deliver value. The problem was creating an experience in a way to make it a no-brainer for our users to extract that value. Because where heatmaps were relatively lower on that list, people tend to be very obsessed with heatmaps because they’re sexy to see and to share, and they’re easy to set up. It always comes back to us, though. It’s all about how do I design the experience of the product in a way that value extraction is as automated as possible — the least work possible. And it’s the part we haven’t got to yet. What we’ve successfully done is we disrupted the market in terms of changing the way data is collected and how to learn through that. So we’re made it incredibly cheap and easy. Now comes the second part, which is getting the value across to our users in a very easy and intuitive way.
You mentioned that your design team grew from one designer to 3–4 people. How did this work for you and how do you maintain consistency within interface design?
Our team has grown in just a few last months actually. What we’re actually doing is we’re hiring designers within product teams. Then this initial person, our Director of Design, who is my co-founder, Jonathan, has moved to a more leadership role and has his own backlog for designers irrespective of the product teams. Obviously they have their specialised areas of the site, but they also collaborate quite a lot together. I think they are already taking 3 calls a week to make sure there’s alignment. And there has been also a lot of preparation for creating building blocks to use in the product, documenting the design process. So there is a lot of preparation that went into that, which I suspect is going to get us to maybe 5 or 6 designers in the organisation and then there’s going to be a whole new level of preparation to go to the next. So yes, we did prepare ourselves for now — the question is, probably, how well did we prepare ourselves. Again, it’s going to be a question of getting feedback, reacting — so it’s exactly the same model also for the structures we’re creating internally. So far so good, though. It all comes down to discipline of creating a process and sticking to it, reviewing the process and doing retrospectives to see: “Is it working?”, “Is it not?”, “Are the teams working on delivering the results expected?”. To me discipline is a big word here.
Is it your role to promote principles of user-centered design in the organisation? How do you maintain the discipline?
It’s across multiple roles, not just me, as the leader of all leads. We created a strategic document with our vision and our values — it’s just a single-page document. And in it are user-centeredness. Customer centricity comes through not only in our values, but also the initiatives, in our strategy and everything. It’s just by virtue of what we chose to work on — it’s something that we live and breathe constantly. But then obviously there are certain roles that are even more focused on it. Jonathan would be a perfect example, but then also the Customer Experience team obviously do that as well. We are measuring NPS, measuring that for both our users and our customers, customer satisfaction scores. We feel that design has a role in not only these numbers, like the experience team, but also how the product behaves. It’s something that we’re actively working on.
I’d say my job is creating a framework and designing an organisation where that can happen and then also making sure that leads to where it happens. On the company monthly meetings following up on making sure everyone is accountable for projects that we’ve set and the numbers that we’ve set ourselves to improve.
What is special about your design team? What makes it unique?
I’m not sure how unique it is. But I’d say it’s definitely the focus on function versus form, so on how things work versus aesthetics. It’s a difficult thing to sustain over time, because it’s so easy to go towards the pixels and how things look. Things should have good enough form, so they should not be despising to use, but that should not be the top priority. It’s something that can easily get in the way. And that’s probably not very unique — I’d hope to think that more teams are focused in that way.
Maybe what’s unique is that approach that we have to get feedback early. Yeah, I’d say we’re modest in general. I don’t think we’re doing anything insanely innovative. It’s just something that comes back very often to this discipline thing, which is — focus on the things that matter to our users and customers. Don’t get to excited that we’re HotJar and a brand, and all these things. Stick to the basics and deliver to our users and customers. I’d say maybe it’s the modesty and discipline that are something relatively unique.
Is there anything you’d like to add about user-centricity and how it relates to your organisational culture?
In terms of our culture, I think that last principle we discussed is something that we consider as really important. There is a saying that we use quite a lot, which is “If we’re not a little bit ashamed of what we delivered then we’ve gone a little bit too far”. I’d say not many teams think in that way. Typically it’s like “It has to be perfect! We have to nail it!”. We value much more the journey as opposed to the milestone. We know that we’re going somewhere, we know that we’re probably not going to get it right, so we value speed probably more than nailing that perfect experience, because we know the journey is about doing and learning. It’s this feedback loop. We pride a lot ourselves in this notion of “If we’re not a little bit ashamed of what we delivered then we’ve gone just a little bit too far”. Even when speaking to our users we know that what we value more than anything is speed. It’s something we aspire to be better at, we’re not there yet. But we hope to get better and I think it’s a slightly different approach to some other teams take. Probably later on we’ll become more mature and we’ll be doing more complex things. We’ll probably become more sophisticated, saying that speed is less important and we’ll focus more on creating really intuitive experiences, where the user doesn’t need to think about anything and focus on wowing the user. But because we have so much to get done and because we’re barely just getting started, we’re valuing speed much, much more.
The last thing I will leave you with, if there is anything that you can share with the readers is the tip of getting feedback early. Nowadays anyone who’s serious about creating a process around user-centered design does it but I think it’s important to be as obsessed as possible about getting feedback early. How do we push the limits? Could we be speaking to our users and customers when we’re writing a story, when we’re defining what the work should be? It’s interesting to think how far we can push the limits on this.
Massive thank you to David Darmanin for sharing Hotjar’s story! I hope we will have a chance to talk again, this time in person.
This interview is the first one in my series called “Mind the User”, where I explore companies that build great products through user-centered design. I interview people who believe user-centricity can drive competitive advantage and change industries or communities.
Remember to follow me to keep up to date :)
Featured image by Paola Chaaya
