Belong Hire

Belong Hire is the B2B SAAS product from Belong that is created to enable company recruiter to do hiring in a candidate driven future of hiring. This is the main product offering from Belong and I have been directly and indirectly involved as Head of Design in how it has been built from scratch in the past 4 years. This is my description of how we defined the problem and approached it as a team of Product, Design and Tech. It would be impractical to cover all of what we have done as a product team to build Belong Hire in the past 4+ years. I’ve covered some selected areas and qualitatively talked about them just to give you a glimpse into our thought process as a Product Team.

We at Belong believe that the future of recruitment is Outbound Hiring.

Outbound Hiring is a targeted, candidate-focused approach that coordinates personalized talent acquisition and business efforts to hire people who succeed in your company.

We achieve this by breaking the steps involved in achieving the goal in the following manner.

A good journey towards discovering the right candidates starts by defining what you are trying to find in the right way. We believe JD is a terrible way to describe the role you are hiring for. We call our better alternative, the Opportunity Profile (OP).

Opportunity Profile, if done right is a huge and complex set of information about a role. Here’s the Opportunity Profile we use to hire UX Designers for Belong.

The challenge for the Product, Design and Technology team was to figure out a simple implementation of this concept in the product.

The simplified version of OP that we use in the Belong Hire product is called the “Ideal Candidate”, made possible by our Data Science team. Configuring the search functionality in the product to find relevant candidate became a simple matter of providing the Ideal Candidate to the system.

Ideal candidate.png
 

The Profile of a candidate

The next phase in Discovering the right candidate is the ability to identify one when you see one. Product, Design and Tech ended up putting together some clever stuffs to pull this off.

We used a mix of clever information highlighting, grouping and insight generation to make decision making faster and easier. It took us a full format Design Sprint for us to get to where we are today.

Profile.png
 
 

Engage

Once you’ve identified a potential candidate, the next step is to engage with the candidate to start the process of discovering if the candidate would Belong in the role. Remember that these are cold emails and would very likely be ignored.

We figured out that highly personalized context-aware emails does the job of getting candidate interest very well, and Belong Hire as a product does exactly that in a completely automated way. From those early days where each email was written completely manually, Product, Design and Tech has taken Belong to a point where we have a platform that can automatically send out thousands of highly personalized emails with context awareness on a daily basis. We do this both for the first time when we reach out to a candidate and also when a candidate is re-engaged later, in which case we included the previous context too. All of this resulted in complex challenges for the Product and Design team to iteratively and incrementally launch this capability over years of development.

One of the most interesting challenge for Design with this approach was to make sure that the entire process which is now completely automated, is transparent and visible through the product. This became very important for users to appreciate the value it was creating.

We also did a lot of seemingly small stuffs which created huge impacts. Here’s an article written by our Product Manager just to communicate the importance of proper email signature to our users. This was also our way of introducing them to the product feature we shipped to help them with that.

What's in a Name - Power of Email Signatures in Recruitment

 

Candidate Experience

Another component that is at the core of our philosophy at Belong is

“Candidate Experience”

Make sure that the Candidate Experience is great and everything else will follow. This guided a lot of our Product road map, Design decisions and Tech execution.

Reaching out to the wrong candidate gives bad candidate experience.” The matchmaking/search has to be perfect, both in Design and the underlying tech.

“Delay in response and acknowledgement of email gives bad candidate experience.” Automate the process to the extent technology allows and improve it incrementally. Enable recruiters to prioritize effectively and work efficiently.

Lack of transparency during the hiring process gives bad candidate experience.” We felt solving this was so important, we built one of the core feature of our product offering around this. We call it the Hiring Journey. It’s a journey and the experience matters. You can read more about the thought behind it in the article below.

Recruiting Leaders – Have You Built a Candidate Journey Map Yet?

Like any sensible Designer, I tried this in our Designer hiring at Belong before developing this feature. Every candidate we interviewed would get a dedicated read-only Google Doc where they would get all updates from the hiring team. This doc also contains every single bit of information that you would need as part of the hiring process. This worked out great.

Conclusion

Those are some of the interesting stuffs we tackled while trying to solve the problem of

“Bringing the Right People together, for the Right Reason at the Right Time.”

There’s so much more to it, but this was a great start.

 
The Product Team

The Product Team

 

Design Sprints in Belong

Design+Sprint.png
 

I pre-ordered the book, got it, read it cover to cover non stop, and I thought I was ready. I couldn’t have been more wrong 🤣

Running Design Sprints have been the most fun days for me at Belong. Here are the top 3 things I learnt from my experience.

1. Start small

The book talks about a 5 day Design Sprint and if you are doing it for the first time, it might not occur to you that you need not do a full fledged 5 day Design Sprint. The first hurdle you’ll face is in trying to convince people to do the Design Sprint. Just say the following out aloud and see how it sounds.

“I’ve never done this before and I have no idea how it’s gonna turn out but I believe this is the best use of your time. Let’s spend 5 days doing a Design Sprint. I’ve been told it’s good.”

It’s hard to sound convincing when you yourself are not convinced. Starting small worked for me.

I started by convincing 3 members of my team to spend 3 hrs per day for 3 days. I’d to adapt the format. I realized that I needed the practice.

2. Make sure it’s the right problem for a Design Sprint

There are enough great contents out on the internet which covers this in much more detail. We never got ourselves in a situation where we were not sure if we should do a Design Sprint or not. We asked a simple question.

Is it worth the time of 5 to 6 people for 5 days?

The answer has been pretty straightforward in all the cases I’ve personally faced. In some cases we decided to do 3 day sprints.

3. You don’t have to call it a Design Sprint

I realized that I do a lot of mini Design Sprints. We rarely do a 5 day Design Sprint. I frequently found myself using the first few steps of Design Sprint very frequently to approach any problem and get to a point where I can make mocks on some promising directions. While I don’t complete it like an actual Design Sprint by testing the mocks on carefully selected users, I use the mocks for internal validation and other basic validation/reactions/comments from some real users. This might sound like blasphemy to hardcore Design-Sprinters but considering all other realities like always-impending-deadlines, never-free-team-mates, five-other-things-to-do, this adaptation of the Design Sprint has done more good than bad.

The Belong Design System

I tweeted the above some time back. Realising this was one of the key to how we were able to put together a Design system for the Belong Family of products.

How to get started

When I joined Belong 4 years back, there was already a basic live product being actively used. We really didn’t have the luxury to spend dedicated time and people to work on a Design System then. To get started working on a Design System, you should make peace with the fact that you will never be given dedicated time to do it, especially in a startup.

So pick a small UI element and start figuring out how to make it uniform/consistent across the product. We picked buttons! Buttons were the easiest place to start. The idea is to just get started.

Buttons

The challenges

We identified 3 main challenges we should address if we want this Design System to succeed.

  1. Building it without affecting normal work.

  2. Buy-in and adoption from stakeholders (Designers and Frontend developer)

  3. Continuous improvement and evolution of the Design System as the Products evolves.

Our approach

I’ve seen good Design Systems being built only to fail eventually as the team suppose to take advantage of the Design System fails to adopt it. Yes! building a Design System for your internal team is just another UX problem solving exercise where you have to empathise with the user and figure out ways to drive adoption. We found our answer to this problem in the following.

  • Participation in the creation process

    • Ownership is key to adoption and while we haven’t figured out a simple and repeatable formulae to make this happen, acknowledging this and actively trying to drive it has been fruitful.

  • Enforced discipline through a live pattern library

    • The developer is the ultimate gatekeeper to making sure what gets shipped respects the Design System. So we established a very clear understanding with the developer that no custom codes will be written to create a specific UI. If it’s not in the live pattern library, it won’t be implemented. This became so efficient that in a few instances, I gave a block diagram to our developer and he put together the exact UI I would have created, directly in code.

    • This pattern library is an open source project and you can find it here https://engineering.belong.co/belong-ui/

  • Pattern Driven Design

    (Totally original and has got nothing to do with “Test Driven Development” 😄) It’s a simple concept. It has only 2 basic points.

    • If what you need in your UI is not in the pattern library, add it to the pattern library first. (Avoid duplication)

    • Don’t add anything in the pattern library which will be used only once.

We are a small team of about 6 to 7 Designers and our product is not very complex from a UI standpoint. This approach has served us well and we believe as long as we keep evolving and building on top of this framework, we should be fine.

 

The rest of the stuff are detail in technical implementation and some clever tricks to collaborate and work on the Design System as a team. I’ll cover some specific examples below.

One button to rule them all

We ended up having just one button as the base symbol and every other button was a variation of it. This limited the variation of how buttons look through out the product. All the buttons that you see at the top of this post was all created from a single symbol using overrides.

Button normal

Button normal
 

Button dropdown

Well it was not just one button to rule them all, we had to create separate button for dropdown buttons.

Dropdown button

A special shout out to Akshansh Deva who interned with us briefly and worked with us on the Design guidelines. He has written his own blog on this project.

Defining Design Guidelines at Belong.co