Doug Proctor Strategic product designer
« Back to case studies

Co-founding a SaaS business

My role
Product Owner / Product Designer
A team of 4
CEO, Client Services Director, Marketing Director, and me

What is Livelink?

Livelink is a SaaS application that helps businesses save time and money managing their live entertainment schedules and programmes. We started this side-business in February 2019 and spent 12 months developing it before the pandemic rudely entered all our lives. Our revenue for those 12 months exceeded £100,000 and we had several hospitality businesses in London trialling us, including The Ned.


All four co-founders are musicians, DJs or have otherwise worked in live music. Through our experience we sensed that our part of the hospitality industry - the part that deals with entertainment bookings - remained mostly “undigitised” while almost everything else was being transformed if not disrupted. With this observation, we set out to uncover further insights and to decide whether there was an opportunity (spoiler warning: there was).

Kicking off: interviews & contextual inquiries

The interviews gave us insight into the goals and ambitions of different staff within a hospitality business, and we began to see that Livelink would be able to help more people than we had thought.

I arranged to visit several people within our target organisations and watch them perform their booking-related tasks. We saw quite clearly that we could save a lot of admin time, but also realised that admin time was relatively cheap. It was when I spent time with more senior people in finance departments that I saw how Livelink could have a much bigger impact.

So not only did we get initial validation of our proposition, but we had insight into how exactly some hospitality businesses dealt with live entertainment, and what their pain points were.

You can learn more about my approach to discovery in my UX- focused case studies.

Planning and modelling

Before I start thinking about specific interface solutions, I tend to create diagrams that represent the underlying forces that will be at play. It’s essential to understand the business context before diving into any interaction design.

It’s also a great way to carry synthesised insights from the research phase into the subsequent design phases.

High-level wireframes

With the planning done we now have a clear idea of what the user tasks are and what they look like, which allows us to create a set of high-level wireframes. This gives us a sense of what pages or modules are required to fulfil the user tasks, and what content and functionality is require for each step.

Developing the UI logic

I tend to wireframe form UI in a more traditional way using native browser elements as much as possible, e.g. radios and checkboxes. I do this because it more clearly shows the logic and structure of the content, making it easier to ensure that the design meets the requirements. Then later in the UI phase I bring in an additional usability “layer” over the top, as you will see in the final UI for this form.

I think of this phase as the “awkward teenager” phase of product design: we’ve moved on from the cute, soft, high-level shapes shown above but have not grown into a beautiful fully-fledged design just yet.

Sometimes I use colour in wireframes, which helps to surface the underlying intention in the wireframe. This draws attention to what the purpose of the UI is, rather than just showing a grey static view that doesn’t not always represent reality well.

User testing

It can be really intesting to compare user tests done with greyscale prototypes versus colour-highlighted prototypes. Some say that testing with highlighted prototypes creates a bias where the subject is effectively given clues, but I believe that discovering these clues is essential to creating an intuitive interface.

Once the I have the core user tasks wireframed, I can string them together into an interactive prototype for testing.

Experiments with colours, icons, spacing and other styles

At this stage I’m not yet worried about pixel perfection. It’s important to remove any factors that get in the way of being able to quickly and intuitively express ideas. Nothing kills exploration more than worrying about polish. That comes right at the end.

Chicken or egg?

Which comes first - the visual language or the UI? Neither: I develop both at the same time. There is an important interplay between the two, and I don’t believe it’s possible to complete one in the absence of the other.

So at this point in the UI design process I have the UI structure pretty much locked down, which means I’m ready to distil out elements of visual language into a centralised definition.

Keeping it lean

Structure and rigour is important for all projects. In this case I was the only designer (and I was also the frontend developer) so I was the only main consumer of my design artefacts, which meant I could cut sensible corners for the sake of efficiency.

Every project is different, and so requirements for documentation will be different each time. It’s important to think carefully about what level of documentation to create because it takes time that could be used solving more immediate problems.

It reminds me of that saying in Agile: The prototype is the documentation.

Finalising the UI

With the structure and content of the components worked out, I can finally apply the visual language that’s been developed so far.

This is the point at which I create components (or symbols) and start to fuss over pixel precision. It’s really important to me that I only define a component once and that that definition becomes the single source of truth. This is a primary concern of design systems.

Engineering, revenue and bats

With our well-tested user experience and polished UI, I set out to start building the application. That took a few months, but I took an approach that meant we were able to deliver value to our trial customers in stages rather than making them wait until it was all ready at once.

The response was great, but that wasn’t a surprise because we had already been working closely with our trial customers and already had a lot of certainty about what we were doing.

After we launched the core offering we continued to design and develop new features as we responded to feedback. Meanwhile, the rest of the team were growing the business and we were signing up new customers at a comfortably slow and steady pace. Our revenue was looking great. That was... until someone in China ate the wrong bat.

We expect that we’ll be able to revive Livelink as a neat side-business sometime in the future when the live entertainment industry picks up again.

Let’s make something


JAMstack! This site is built with Gatsby and