Sadly, Personably is shutting down. You can read more here.

How to design your first SaaS homepage

I joined Personably back in July, it already feels like I've been here a lot longer than 3 months. It's been very busy (good busy!) and I don't think a week has gone by without something exciting happening.

My first task was to look at redesigning the homepage. I've worked on the homepage at all my previous in-house design jobs—but this is my first SaaS product homepage. So as Yoda says to Luke in Empire,

"unlearn, what you have learned"

I too needed to approach this as something completely different.

Why the homepage first? 🤔

Initially I really liked the homepage, it was clean and simple, the colours were different from what I’m used to seeing from HR and People Ops brands, which are often blue or quite muted colours. But, on closer inspection there were a few areas for improvement.

Some of the copy felt a bit too long and in places the font size was too small. It felt a bit ‘bandy’ with the straight lines dividing up the sections.

The features section split up each feature within a tab which was easy to miss and would mean visitors have to click to see everything. I personally think vertical scrolling is the easiest interaction on all device types, so I try to avoid hiding too much content behind clicks, especially if it’s really important. The main exception being video, because autoplaying videos with sound are intrusive to the point they can feel hostile!

The content was no longer reflecting what the current app could do, and wasn't doing everything it needed to be doing. For example, it could do a better job at explaining: our features, how the app helps our customers to get the jobs they’re trying to get done, who we are. Customers may also be interested in seeing what we integrate with.

In my first few weeks with Personably I set about finding out what people thought of and what they would want from the homepage of a product like ours. Plus, I thought it would be a great way to get to know the product and some potential users!

I think it’s really important to get to know the users you’ll be designing for. In my first role I designed websites, apps and booklets for patients and carers for people with chronic and terminal illnesses—so gaining that understanding and empathy for end-users was unquestionable. Learning that it’s better to design for your user, rather than yourself, is applicable to product design and thinking I’ve done ever since.

Getting started 💪

The homepage's purpose is to explain the product and its benefits to new customers. As mentioned above, the best way to start was to talk to some potential new customers / people that fit the criteria of being a customer.

Coming from a large company where I had a lot of user research and testing tools at my disposal, my first instinct was to look to some of these tools to help me. But, they seemed a bit overkill for what I needed now, and we had access to awesome communities of people willing to help through LinkedIn and Slack. We offered a reward of an Amazon voucher plus the fulfilment of helping shape our homepage and product, no feedback would go to waste!

Each person in the team joined me for at least one of the calls too! I’ve found involving other people in the research (besides other designers and researchers) to be hugely beneficial. They get extra context and get to see exactly how users use the product they’re working on, supporting customers, marketing or selling. As well as what those users think, what they’re trying to get done, the contexts in which they do things and what outcomes they’re expecting. All the good stuff Clayton Christensen recommends understanding before developing or iterating on a product.

I put together a Research Doc beforehand, it had a list of the people we'd be talking to, topics we wanted to cover, and a table where we could tally whether some of our initial hypothesis about the homepage were true:

table

It also included a link to a script to follow during the interviews. I don't follow the script exactly when interviewing users/customers, but it helps to make sure I cover all the topics I need to.

The idea for format of the research doc was borrowed from a talk I saw at the Monzo Open Office in June by Samantha Davies, Lead User Researcher at Monzo.

This made it really easy to share insights from the interviews with the rest of the team. As well as making it easy for them to know everything that had already come up when they joined me in one of the interviews.

What we learnt 🕵️

We spoke to eight potential customers, after which we had a much clearer idea of what’s important for them to see when they visit a homepage of a product like ours. As well as what elements were and weren't working well from a usability and content perspective.

Here’s a annotated image of our previous homepage:

old-homepage-annotated-1

WWhy just eight people? It's believed that after speaking to five or more users, the amount of usability issues you'll discover and the ROI for time spent versus issues found starts to reduce. As you'll mostly be finding the same issues over and over, as this graph from Nielsen Norman Group illustrates:

20000319-user-testing-diminshing-returns-curve

User Interviews are a great way of getting some qualitative insight into how and why users/customers do and think what they do. I find preparing a few interview style questions before and after doing any usability testing helps break the session up, allows time to make the participant comfortable and maximises the insight you can get in a 30-45 minute session.

Nielsen Norman Group have covered the topics of how many users to speak to in a usability study and why user interviews are useful in a lot more detail.

We learnt that customers were trying to find out specific information:

  • What Personably is
  • The benefits of using Personably, i.e. the problems we're solving—for people teams and the new hire experience
  • Information about features and integrations
  • How established we were, who our customers are and what they would say about us
  • How much it costs

Validating what we found out 🔬

MMaking decisions (that aren’t just small usability improvements) based on feedback from eight people can be perceived as being a bit risky. Also customers aren't always great at being able to tell us exactly what they need. Using different research techniques on a different set of customers is a good way to validate what they’ve told you. Plus, you get to find what techniques work best for you and your team. Win-win.

An initial design was put together based on what we heard in the interviews. More feedback was collected from a survey about the topics covered in the interviews, the current and new designs. At this stage they looked like this:

old-vs-v2-homepage

Alongside the interviews and surveys, we looked at how other companies were addressing some of the needs of their visitors. These also influenced some of the design decisions we made. I like to collect screenshots into a folder, and we also have a #ui-inspo Slack channel to share any other websites we've seen and like.

Deciding on the design to ship 🚢

Whilst it would be great to address all the needs of potential customers, some things are going to require a lot more thought or time to do. In the interest of delivering value as quickly as possible, some ideas were ‘parked’ (in other words, we'll come back to them later).

The quickest and easiest way to work out any flaws in a design is to get it in-front of as many people as possible. Which means pushing it live and seeing what feedback you get. Then essentially repeating the process again, creating a build-measure-learn cycle.

Using all the feedback and research done so far, the new design was iterated on. I put together a prototype using Anima to play around with some animations and to create something less static to test some more, face-to-face with people in the office.

We iterated on the design and were ready to start building it. I used SVGator to build some of the more fiddly animations—all the others were done by Ruth with CSS and JavaScript. SVGator’s interface shares some similarities to Adobe AfterEffects, so if you’re familiar with that, and not CSS animations, I recommend trying it!

Launching and learning 🎯

Since updating the homepage we’ve continued to improve it. Tweaking copy, layout and other content based on feedback we got from our research and what we’ve heard since.