Menu
Talenya
AI, Talent Acquisition Bots
Design Sprint, Rapid Prototyping, UX/UI
By Orit Zetouni Sade
Co-Founder, UX Strategist
One of the most amazing things about the Design Sprint methodology is that it works just like a cookbook. it’s not just a common philosophy.
In this case study, I am going to share with you how we ran a Design Sprint with Talenya, one of our customers. Talenya had this great idea, they wanted to use veteran professionals and make them into headhunters, supplying them with candidates and clientele, making them look through AI recruitment tools, and hunt people that are willing to move to a new position.
That was a great idea, however, the business side of it required them to make it hire the company to make it higher for millennia to get paid like a recruitment agency, and that’s a very difficult market to be in since you’re very dependent on the time schedule, and decision making of hiring, which is a complex process.
They wanted to pivot from that idea, and the big idea was to utilize their current machine learning technology and to position themselves better against headhunting agencies, using bots. They thought they would supply only sourcing procedures finding the candidates recommending them and enable the employers to directly select appropriate candidates and move them into the hiring funnel. They contacted us and we ran a Design Sprint about that.
By Gal Almog
CEO & Co-Founder of Talenya
“Focus, time to market, cost saving. You will save a lot of money and time on your effort to go to market”
On the first day of the Design Sprint, we defined the challenge.
We started the day by performing expert interviews. We interviewed the CEO, the CTO, the sales manager, the marketing manager and we went through the user journey.
As I interviewed our experts, I asked the rest of the team to frame the challenges and problems as HMW (how might we). This is a method designed in Procter Gamble and it helps you focus on the challenge and also phrase it in such a way that you want to actually solve it. For example ‘how might we create something that keeps HR in control’. This is one of the top how might we’s we had in our Design Sprint.
Before I dive deeper into the process itself, I want to share some of my thoughts about making the right mistakes. When I was seven years old, I started to take piano lessons, I was really bad.
Six years of classical music, and it got to the point where the teacher told my mom ״hey look, maybe we
should leave the boy alone, it’s been nice.”
My mom said okay, and she switched the teacher.
The next teacher actually changed my life. He introduced me to jazz, and in jazz, I found out very early on, that I can make mistakes, and it’s okay. One of my favorite pianists is called Thelonious Monk.
He sounds like he’s making mistakes, but actually, they’re not mistakes- it’s explorations and he once
went out of a concert he had and he said: “Well today I made the wrong mistakes”.
This shows us that not all mistakes are good. Mistakes are part of it, but not every mistake you make
is good. So what are the wrong mistakes?
The first wrong mistake is a mistake you already did, so if you keep on doing the same mistakes all over
again then you’re doing something wrong.
Usually, it’s because you don’t acknowledge that you make a mistake.
The second type of mistakes are mistakes that you can’t learn from. It’s okay to burn a cake but
if you didn’t check what heat the oven was in, and how much time you put the cake in the oven, you can’t learn from it and you’ll probably burn the cake again.
The third type of wrong mistakes are mistakes that you can’t recover from.
In 1982 Atari, the gaming company came up with an idea for a game around E.T, the movie picture, and they negotiated the deal for a year. The negotiation went on and the release time did not move forward and eventually the game designer Howard Warshaw had three weeks to design the game, and this was not enough time. The game was released with a lot of PR and it was the biggest recall in game history.
The game was so bad they had to actually bury all these game recalls in a dumpsite very shortly after they had to close the company and fire everybody.
It was so bad that the entire gaming industry saw a strong recession and could not recover for years.
Once we finished interviewing the experts, we had a lot of How Might We’s written by the team
and then we hang all of them on the wall. We gave each participant three voting dots, and they
voted on the top three How Might We’s. Eventually we categorized the How Might We’s and we decided on only five or six top HMW’s to be used later.
The next step was to select the long-term goal. We asked the participants to write down on a
post-it note, a sentence that starts with the words “in two years time” and then define how success will look like. Each participant wrote their long term goal on a post it note and eventually after time’s up everybody presented their long-term goal and we hung them on the wall.
Each participant got one vote and they voted on the sentence that most reflected what the vision of the company should be. We asked them to be very particular about the KPI’s of how success will look like so as not to be too general that it’s not tangible.
The chosen two year goal was “in two years time, Talenya will be the go-to tool or service
for hard to fill jobs”. We managed to get a little focus here – the entire team realized we don’t want to focus on the entire hiring market, instead- we want to focus on hard to fill jobs.
Once we put on our very optimistic glasses on what success will look like, now we had to put on our pessimistic glasses, and think of what will prevent us from reaching that long-term goal
I asked the team to phrase it in questions that start with the words “CAN WE”.
These questions served us as our sprint questions. They guided us to build a prototype
that was able to answer these questions. So everybody wrote their “can we’s” from
the long-term goal. We voted on that and then we decided on the top three.
The team voted and after that the decider put the three green voting dots on the winning can we’s. As you understand, this is not really a democracy. It’s just giving the decider tools to make informed decisions.
This is what the team thinks, but not necessarily what she or he will decide.
In Talenya, the winning Can We questions were:
The last Can We is a bit technical but ideally we hope that it can be fully automated and we wanted to also see if the clients will like that idea that everything is automated.
The map is a way of looking at the user journey. We divide the user journey into three parts:
1. Reach – how people will hear about us, which channels are we exposing ourselves to the users.
2. Learn – once they heard about it how do they learn what we do
3. Use – is actually the user experience
We did a very very rough user experience map, this does not serve as a ux map.
User journey maps are much more detailed. We try to be very high level, because in the next step we took the How Might We’s we already wrote, we prioritized and put them on a map and that gave us an idea where most of our challenges are.
This really shed light on where we should focus in our prototype, which is the next step in the Design Sprint. We asked the decider to select the type of user we’re going to prototype for and also where in the journey they wanted to focus on.
In this case the decider selected the hiring manager at the company we sell to, and the use section in the map. From my experience, sometimes our prototyping outcome will be a landing page, because sometimes the main challenge is just explaining what’s the value proposition of the product. This time it was different because the Talenya team wanted to examine the use part.
There is a very strict process we always follow to produce solutions. Once we defined the challenge, the first thing we wanted to do is to open our minds.
We started from divergent thinking – we opened our mind and then we converged our thinking.
We started from divergent thinking – the lightning demos exercise. We asked the team to
look for solutions in the market, not necessarily in our domain, that solve similar problems.
This helps us to look at different types of solutions. This enables us to open our mind to innovative ideas beyond what our competitors are already doing.
The next exercise was a four-part sketch. Sketching a solution is not easy for a lot of people especially if they’re not designers, so we always help them go into that mood and ease that process. It sometimes might feel a bit awkward to many participants, we use music to ease the atmosphere.
The first step was the note-taking exercise. They went around the room and they just had to copy the long-term goal, the sprint questions, the how might we’s, and also review some of the lighting demos. This puts everybody in the mood of creating solutions. It moves our brain wheels a bit.
Once that was done, we gave 20 minutes for doodling, just starting to form up an idea for a solution. It does not have to be very clear. We explained to the team they don’t have to get to a full solution but they need to start to have an idea of what’s the direction of the solution.
The next exercise is called crazy 8’s. We folded an A4 paper into eight parts, and we gave one minute per part. this is why it’s called ‘crazy eight’s’ – you give one minute for each part.
That way, the team had to think of alterations to their doodling ideas.
Many of us, when we start to solve a challenge, we stop when we have our first solution.
We’re so happy we have a solution, so we don’t move forward.
Interestingly enough, the second or third iteration is much better.
We asked the team to take an A4 paper, and draw their solution in three frames.
We explained it should be self explanatory.
Once the team finished working on their solutions, we hung them on the wall, the team was happy, we drank beers and went home.
On the morning of the second day we went through the solutions. We first gave each participant a bunch of dots. They reviewed all of the solutions and put red stickers on them, so we got a little heat map on the wall. Once the team was done, we could see which solutions were interesting to the team. It’s a good trick to get the team to review all of the solutions and understand them. Once we finished that, I presented all of the solutions.
After each presentation I gave a few minutes for clarifications or questions to the creator of the solution. Once we reviewed all of the solutions, we voted on the best solution and then the decider looked at the voting and decided which of the solutions we’re going to prototype.
By Eyal Katz
Co-Founder, Head of Services & Creative Director
The first exercise in this section is called ‘user test flow’.
I asked the team to think about the first screen the user will see in the prototype, then to think about the last step in the prototype and lastly do the in between steps of the flow.
That way, each participant had six post it notes showing what are the screens we’re going to prototype the day after. The next step was to vote and decide on the best option for the flow.
In this part of the Design Sprint, I allowed some of the participants to go home, since we don’t need everybody. It’s mainly the product people and the marketing people. In this step the team and I started to draw the screens on a whiteboard. I wanted to create clarity on how things will look like tomorrow. When we have clarity, the design team and I can work much faster, since everything is aligned with the participants.
These screens were prototyped with my design team in one day and were shown to users.
They look very realistic because I wanted to get the users’ reaction to the prototype.
We had like fifteen screens in the prototype. I had three designers working on this with me for a full day.
One the prototype was over and approved by the client, we interviewed five users.
In each interview, we showed them the prototype and we listen to what they have to say about it. There are very few questions we always ask during the user testing session.
We show them the prototype and we ask them to openly speak up what they think.
You’d be surprised how much information you’re getting just from letting people see click, and talk.
The right mistakes require you to first know the wrong mistakes. Making the right mistakes requires you to find a good framework like Design Sprint, something that you can repeat. Another thing is you need to take your risks based on data instead of guessing.
By the end of this Audit call, you will have a clear understanding of the next steps you can take to step up your product.
This audit call is perfect for product leaders (Startup CEO’s, Product Managers) who are currently dealing with complex problems, creating a new product or significantly improving an exiting one
