User Experience
October 9, 2019

inFullMobile: We used a Design Sprint to showcase company culture on our careers page

Alicja Topor
User Experience Researcher

This is a story about a GV style design sprint. If you’ve never heard of that, you can learn more here or read the book.

inFullMobile is a digital product design and development studio based in Warsaw, Poland. We are a team of passionate designers, developers, project managers, and quality managers who are dedicated to getting (amazing) things done.

Like most IT companies, we are constantly dealing with challenges when it comes to recruiting. Developing the right recruitment strategy is an extremely important and difficult task, which is why we are always on the lookout for possible improvements.

At inFullMobile, it is important for us to hire not only top-class specialists in the field but also great people who fit our culture. Our most important asset is our team, and we know that there’s no successful project without cooperation and culture of teamwork. Sometimes it’s a challenge finding the right fit, and due to an ongoing process of redesigning our careers page, we decided that this would be the perfect challenge to use Design Sprint.

The team

We formed a cross-functional team of specialists across different areas: HR, Recruitment, UI Design, UX, Software Development. We assigned sprint roles, choosing our HR Specialist as The Decider.

Defining the challenge

We started the Sprint with Expert Interviews to extract the problems and challenges that we would focus on. Input from the HR team played an important role here. They know who our target users currently are (and who we want them to be in the future), what the possible constraints are, and how ( in the perfect scenario ) we would like our careers page to look two years from now. On the other hand, feedback from our employees was extremely important, as they are a representation of the people we want to hire.

The exercise based on “How Might We” note-taking during the Expert Interviews was quite challenging for the team. It takes practice to simultaneously gather important insights from Experts, turn them into a “How Might We” question, and write it down (in the way that makes sense for someone who might read it later on). Luckily we managed to create a fair number of HMWs, and we had a vote to determine the most important ones for our Sprint.

In the next step, we established:

● Long-Term Goal: To attract the best candidates.

● Sprint Question: Can we make candidates stay on the careers page and apply?

While creating the Map, we chose the candidate as our main actor, and the final step was applying.

The Map and the target area formed by the challenges (HMWs)

Sketching solutions

Doing a quick Lighting Demos session is a great way to unlock creativity and find inspiration for the sketching phase. Each of us presented up to three different products that either solved the same problem or at least consisted of solutions or features we could use in our project.

Sketching was the part that caused the most confusion and the biggest doubts in the team. It was a challenge for people who are not used to sketching, and for some of them, it might have been uncomfortable. But after a while, it started to go more and more smoothly, and cool ideas started to form on the paper sheets, along with new concern — how are we going to choose only one solution?

Decision time

The decision-making process felt a bit harsh. Here we had all these great and creative ideas, and we had to face the fact that only one idea could be chosen for further work. (I honestly felt like maybe it was time to cheat and choose all the ideas!)

We noticed something interesting during the heatmap voting, as well as during creating HMWs — our preferences and picks were often aligning, even though we all had different perspectives from various areas of expertise and different goals.

During the voting, our Decider made his choice and used one vote for a winning solution, and the other one for a feature from another idea which we decided to add to the prototype.

It was very helpful to do a User Test Flow exercise before the actual storyboard. We suggested our ideas of user flow, and then again the Decider had to choose the one to proceed with. Just like with the voting on the concept, he has also chosen a single step from another story that we added to the storyboard.

The Storyboarding stage left us with a few important takeaways. Now we know how important it is for the Storyboard to be detailed — it makes prototyping a lot easier and helps alleviate a lot of doubts. We also didn’t include a copy in the storyboard, which — as we figured out later — was a mistake that cost us way more effort on the third day.

Building a prototype

Here comes the fun part — armed with the storyboard, we started to work on the prototype that would reflect the idea we wanted to test with users.

We decided to create the prototype using Figma because it gave us the ability to collaborate in real-time and speed up the work. Because not everyone was familiar with the tool, during the morning kick-off meeting we ran a quick Figma introduction, led by our Designer.

During the prototyping day, we had two check-in meetings to discuss the progress, clarify any uncertainties, and delegate tasks for the next few hours. It was especially helpful to discuss all the design-related questions that came up while creating wireframes.

Interactive prototype created in Figma

Testing with users

On the final day, we held interviews with our target users (software developers) to get their feedback. These interviews brought us lots of insights, including some unexpected ones. Users generally liked the design and were positively surprised by the overall idea. But the purpose of certain features was not clear or found to be unnecessary.

We organized post-it notes with the feedback according to what was positive, negative, or neutral. In the final step, we filtered them out by finding and pointing out the trends that emerged to see if we could answer the big questions. We wanted to see if we were moving in the right direction towards our long-term goal.

What did we learn from this Sprint?

Lesson #1 — Keep your storyboard detailed

The team initially underestimated the value of a detailed, precise storyboard. Creating a storyboard is a good opportunity to revisit the Sprint goal and keep that in mind, as storyboarding leads you directly towards the prototype. Adding copy to the storyboard also saves a lot of time on day three.

Lesson #2 — Focus on the challenge

It is super important to revisit the goal and the challenge quite often to make sure the team keeps its focus and stays on the right path. While storyboarding and preparing the prototype and user interview scenario, we needed to ask ourselves whether we would be able to answer the Sprint question, is the solution aligned with the long-term goal.

Lesson #3 — Trying to save time will (most probably) cost you… more time

The last but most important takeaway for the team was discovering where we could make some modifications, and where we needed to stick to the process. Having a cross-functional team of people with very busy schedules made it very tempting to make some adjustments, cut the time, make the process more flexible. We divided the first two days of our Sprint into separate exercises, and it turned out to be way more difficult not to lose the focus, to drive toward the goal, and keep the whole team engaged. By trying to save time, you may actually lose out as a result.


After we finished the Design Sprint and summarised outcomes, we ran an Iteration Sprint that had a huge impact on the present designs. We learned a lot during the Design Sprint, and we used that knowledge in the Iteration Sprint. Most importantly, we were more focused on the goal and what we are trying to verify with target users.

Insights from users, as well as new ideas from the Iteration Sprint, led to a lot of changes in the prototype, which was made almost from scratch (with just a few parts kept form the first version).

The project is still in progress, but the current design fits our expectations and users’ needs much better than the first one. Iteration Sprint is a crucial step and a great way to incorporate user feedback and fix any wrong turns that have been taken during the first Sprint.

Feel free to contact us:

inFullMobile: We used a Design Sprint to showcase company culture on our careers page was originally published in Sprint Stories on Medium, where people are continuing the conversation by highlighting and responding to this story.

Written by
Alicja Topor
User Experience Researcher

You may also like

Like what you read?
Get monthly business and technology insights straight to your inbox.
Location: Wilcza 46, 00-679 Warsaw
About us
.intent (formerly inFullMobile) is an international digital product design & development studio delivering software at the intersection of digital and physical.
.intent™ All rights reserved.
Terms and Privacy