A year and a half into running OfferZen, we realised that we needed to build a more solid base for our product. Sometimes, this can mean rebuilding core features — a challenging task while ensuring everything runs smoothly. Here’s the story of rebuilding one of our most important features, and what we learned along the way.
Initially bootstrapped by OfferZen’s founders and then handed over to a dedicated team, our product has changed at every step of the company’s growth. Over a year ago, our product team started separating the frontend from the backend, embraced React and built out RESTful APIs. Changing the base technology of our product in this way meant that we would need to rebuild some of our core features.
Choosing to rebuild something is never easy and working on a feature that’s already in place can feel like treading water — you’re spending time on something that already exists and runs without major hiccups. In order to understand why we were rebuilding, we needed a guiding principle. That’s why our product manager Gys came up with a suitable theme: In order to build the product we wanted, we needed a solid base — features that are reliable, yet remain flexible for incremental improvements and change. What we had at the time didn’t match this ideal — it was becoming more difficult improve the quality of our product.
Rebuilding a feature: Communication for job seekers
One of the early features that we identified for our rebuild was the “candidate interview requests” feature. On OfferZen, this is one of the most important features for our job seekers — they use it to communicate with companies on our platform. Up until a year ago, it had stood us in good stead, allowing job seekers to send messages and manage conversations in the thousands.
Unfortunately, it was not quite the communication tool we had hoped for:
- We had received feedback about some confusing aspects of the interface — users weren’t noticing important functionality and were struggling to find information.
- The mobile experience was quite frustrating, mostly because users needed to send messages easily — something that the interface wasn’t optimised for.
- The single page design we had chosen for the feature began to limit what new functionality we could add — there was simply no space available for new elements.
- The code had become quite brittle, making large changes increasingly difficult.
That’s why we decided to rebuild.
Figuring out what the work is going to be
In our product team, we work in cross-functional teams we call “squads”. My squad consists of a frontend engineer (Laura, also squad lead), a UX / UI designer (Marike) and a full stack engineer (myself). We were tasked with rebuilding the “candidate interview requests” feature.
We quickly stumbled onto the problem you face when rebuilding an existing feature: how can you both deliver the existing functionality and build all the things you’ve been thinking about?
Considering data and user feedback
To answer this, we needed to identify what had worked well before, and what didn’t. This meant digging into usage data and user feedback we had accumulated over the past year to find trends.
While this is an absolutely essential step, we ended up spending a lot of time thinking about the “bells and whistles” instead of the core of what we were rebuilding. This is probably due to the variety of feedback we had received. It described various parts of the feature which led us to start thinking of specific solutions for each problem.
Setting clear goals
Eventually, our product manager reminded us about the solid base we needed to build, and we came up with clear goals:
- Provide job seekers with a complete tool for managing their communications with companies.
- Build out the feature with React and RESTful APIs, so that we can add new features more easily in future.
- Provide an awesome mobile experience.
Tip: Focus on the objective — When rebuilding an existing feature, it’s easy to get caught up in all the wonderful things that you could build. We already had to ship an entire working feature, and almost made the mistake of burdening our squad with even more work — the bells and whistles could come later.
Redesigning an existing feature
While the single page design wasn’t a problem in the early days of the feature, it started making communication difficult for job seekers that were messaging multiple companies. Important information was not being surfaced clearly, and as a communication management tool, it was failing the users who needed it most. Additionally, the lack of space was making it difficult to add new functionality.
Having identified trends in the user feedback, we knew about specific things that needed changing, but not how all these changes should fit together. For us to address this, we needed to go back to the basics and focus on the intended workflow. This meant identifying the actions users needed to perform, and when they would perform them.
It quickly became clear that job seekers needed to:
- Get an overview of their communications.
- Easily identify and focus on the most important information: messages they hadn’t yet seen, the last message that was sent and the next action they should take.
- Delve into the details of a specific interaction with a company: messages, upcoming interviews, company details, job description.
- Send messages and set up interview appointments.
To address the concerns we had about the user experience and spacing, our designer moved away from the single page layout and drew up separate list and detail pages. The list page would have cards that provided an overview for each company, with icons indicating action required by the job seeker. The details page would provide all the information necessary to make decisions, and also the ability to take actions immediately.
It’s tough to see past what you have
Redesigning a feature is in some ways more difficult than designing something new: The existing design choices often anchor your thinking and ideas, limiting the direction that new designs can take. In this case, we needed to display a lot of information while still leaving room for growth.
Using the opportunity to improve things
Redesigning the feature gave us a rare opportunity to address some lingering issues. We figured that while we were here, we should improve as much as possible while still focussing on our goals. This allowed us to gain a lot of value from the rebuild, despite the fact that we were working on an existing feature.
Tip: Everybody attempts a sketch — A technique our product team has used in the past when we’re stuck, is to each have a go at drawing up a design. We set ourselves a short amount of time and quickly sketch ideas, then compare the results. Often, the ideas captured by this technique change your perspective and open up new avenues to explore.
Building on the Rebuild
Looking back on it, we were quite glad to have focussed on a specific set of goals from the beginning, since the time we spent writing and refactoring code to meet these goals would end up being substantial. We did miss a few details in our initial investigation, but in the end, we shipped without too much fuss and only a few minor bugs. From start to finish, we worked for about three and a half weeks on the project.
The upside of the rebuild became immediately apparent a few weeks later, when we added a small new feature in just a couple of days — allowing job seekers to indicate their hiring progress in a single click. This wouldn’t have been a minor feature if it weren’t for the rebuild, which gave us confidence that we would be able add new features in future — even the ones we hadn’t thought of yet.
In the last year, our product team has rebuilt a number of existing features at OfferZen. I wish I could say it’s all been smooth sailing, but rebuilding seems to present a unique set of challenges. If you can avoid it and rather make changes incrementally, it’s often a better option. Since we shipped the “candidate interview requests” feature, we’ve learned a lot, and have already thought of changes we could make — the difference is, this time it won’t be a rebuild.
Ethan is a full stack developer at OfferZen — driven by building cool things and learning every day. He enjoys readable code, good journalism, books, running and data visualizations.
