Before we closed for the Christmas holidays, we decided to run a design sprint to ramp up our new service, Boost — a one week design sprint for businesses to improve their digital products and give a bump to their metrics. While we’ve already successfully run a couple of Boosts, we thought we could continue improving our process. As they say, practice makes perfect.

Picking our “client”

This time no client called us. We chose the service we wanted to improve. At first, we came up with lots of ideas and then decided to go for Immoweb, the reference website for real estate in Belgium. It seemed like the right project for us; a content heavy platform with thousands of visitors every day looking for a new home, it’s complex enough and has plenty of opportunities for improvement.

With the feet on the ground

However, we had to be realistic about what we could achieve in just 3 days. For that reason, we used the 80/20 rule to choose how to allocate our resources to achieve the greatest gains for users. If you’re not familiar with the 80/20 rule or else the Pareto principle, it simply states that:

“80% of the effects come from 20% of the causes” — Pareto principle

In design this means that if 20% of a product’s features are used 80% of the time, you should focus your design, research and testing resources on those features. We assumed that the product page “rent an apartment” was this 20% we were looking for. By framing our Boost around the product page we could drastically improve the site’s user experience. We should mention here that the global navigation elements such as the master head, the navigation bar and the footer were out of the scope for this sprint.

Current product page on Immoweb

Figure 1: Current product page on Immoweb

The plan

Once we settled on the aim of the project we planned our sprint. For client projects we usually break the week into 4 days like so:

  • Day 1: Kickoff session
  • Day 2: Design workshop
  • Day 3: Build
  • Day 4: launched

Then we monitor how the changes affect the metrics for a week or two (depending on the site’s traffic), and then we meet with our client again to evaluate the results and advise on how to continue improving the product.

In this case, as it was a hypothetical project and Christmas was on our doorstep, we decided to stop on Day 3.

The team

Depending on the Boost, we assemble the right team for the circumstances. Typically it’s two designers “ping-ponging” during the design sprint, asking other Central members to pitch in when they feel it’s necessary.

For this project, we were four. Loucas our UX designer led the Boost. Sarah, our Content Strategist showed off her wireframe skills, while Quentin and David tackled the design problems during prototyping.

Day 1: Kickoff session

The goal of the first day was to frame the design problem. During a 2-hour workshop we encouraged everyone to share their own experiences of looking for and finding an apartment, and so developed a common understanding.

How do we currently do this?

Loucas shared his experience as a foreigner looking for an apartment in bilingual Brussels. Sarah recalled how it was to search for a house to buy, and David described the time he was looking to move to a new apartment with Laetitia. We all agreed that:

“Looking for a new home is an exciting, creative experience that quickly turns into a stressful, long process draining people’s energy.”

It requires good search and curation skills, as well as collaboration in the case of couples. First, people need to start filtering the results depending on a set of criteria (location, price, size, number of rooms, etc. ), then save the ones that look interesting, share them with their partner, schedule visits, remove from list, and so forth…

Looking at existing commercial solutions

Next, we looked at existing solutions from direct competitors in Belgium and elsewhere, as well as companies that are similar but not focused on the same market segment such as Airbnb and We identified design patterns that might in our case be helpful. We discussed and highlighted them and then set them aside for the day we’d start designing.


To make things more concrete, we created our lightweight personas and started telling their stories. We outlined the story of Inge and Tom, a young couple who plans to move in together in Brussels, and the story of Josette a 72 year old widow who is looking for a small apartment to settle in with her small dog Emille. The two stories helped us define the search criteria for each case, draw the two distinct user journeys and come up with ideas that we could consider during the prototyping phase.


Figure 2: The stories of Inge, Tom and Josette; the 3 personas we chose to tell our story.

Identifying goals

Towards the end of the 2-hour workshop we summed up our discussion and stated our goals. We all agreed that it was apparent that the need was to:

  1. Save time in looking for an apartment.
  2. Make the process more enjoyable and less stressful.

To achieve this we would need to focus the Boost on:

1.Improving the Information Architecture of the product page.

  1. Improving the typography and readability of the page.
  2. Improving the navigation and calls to action

How would we measure success?

We used Google Venture’s HEART framework to find the right metrics for measuring the success of our redesign, where HEART stands for Happiness, Engagement, Adoption, Retention and Task success.

“To figure out what those are, you need to start at a higher level: identify your goals so you can choose metrics that help you measure progress towards those goals.” — Jake Knapp, Google Ventures

As we wanted to save time in looking for an apartment and make the process more enjoyable, we decided to focus on measuring Happiness and Task Success. In both cases, a usability test would give us the cues we’d be looking for.

Day 2: Design workshop

The goal of the second day was to come up with one final wireframe, which we would agree to prototype during Day 3.

Content first

We started the second day by printing the current product page, and each one of us making annotations on it. The exercise helped us define the content hierarchy of the page, and agree on the main content elements and modules that we would need to design. We separated the page into two sections the top main section (hero) and the detailed view. The first should give the user a quick impression of the apartment, while the latter should allow to include all the little yet important details, but in a manner that is easy to scan them and digest.

Figure 3: Annotations of the existing product page


Once we had defined the content, we moved forward looking for possible solutions to structure it. To illuminate all the possible paths, we set our timer to 1o minutes and we each sketched solutions for the hero section.

Team Critique

We posted our ideas on the whiteboard and each gave our feedback by voting with green dots for the ideas we liked. We took another 10 minutes to compare and discuss our sketches. This helped us quickly create a common ground and envision the desired solution. Sketches

Figure 4: Quick sketches of the product page


We returned to our desks and had another 10 minutes to come up with an improved wireframe. The new wireframes integrated the elements we liked from each and removed the elements that had received negative critique.


We followed the same process for the details section, and then assembled the two sections (hero and detail) into one, converging towards a common idea. We then discussed some design problems we anticipated and researched how other services try to solve them. We fine-tuned to draw a consolidated version which we would prototype on Day 3 and Day 4. As a client had mentioned during a previous Boost:

“What would have taken us a week, took us a mere 2 hour workshop. ”

Consolidated wireframe

Figure 5: The consolidated wireframe of Day 2

Day 3: Build

On Day 3 we started by designing directly in the browser. We believe it’s a far more efficient way to build websites and applications for our clients. It allows us to collaborate, reuse code, show interactions and flows in their native environment and start with content instead of style.

We started committing code, and creating new branches (versions) whenever we had a slightly different idea. A few check-ins and a couple of “idea ping-pong” later, we had managed to have four versions of the product page.

Version 1 was an exact representation of the final wireframe we drew on the second day. No surprises there.

Prototype version 1

Figure 6: 12:00 o’clock: Version 1

However, looking at it on the browser we realized that price is a very important factor when searching for an apartment. We would have to move it upfront. So in Version 2 we moved price to the top of the page together with the other essential criteria: type of apartment, size, number of bedrooms and another highlighted trait of the apartment (garden view, parking…). Here, we made the contact call-to-actions more prominent and provided some space to display the agency’s logo and information, while moving the location map into the slideshow.

Prototype version 2

Figure 7: 14:00 o’clock: Version 2

After a check-in with the group we agreed that the second version looked way too complicated. It broke the page into three content zones instead of two, as we had agreed. Now we had one zone for the title and the essential criteria, one for the details, and one for the rest.

So in Version 3, we simplified it keeping the price on the top but placing the title and the criteria just beneath the images. We added the call-to-action save to favourites and placed a full width map on the bottom of the apartment ad.

Prototype version 3

Figure 8: 16:00 o’clock: Version 3

In Version 4 we added some pictures to make it look more realistic and moved the map back at the top of the page as we thought that location is too important to be placed below. We also replaced the ‘save to favourites’ button by a star icon to further simplify. We also added the other Immoweb services to the bottom of the page, as we assumed that they were an important part of the Immoweb business model.

Prototype version 4

Figure 9: 18:00 o’clock: Version 4

Day 4: Wrap-up

To be honest there was no real Day 4, since we didn’t have to launch or test anything. If this was a real project, we would test our prototype with people, tweak it, adjust-it, plan another design sprint for the visual design of the page, launch it, and then evaluate how it scores against the set metrics. Instead, we exchanged wishes, gifts and chocolates, and cheered to 2015. Happy New Year!

Central team

Figure 10: From L-R: David, Pascal, Loucas, Quentin and Jonathan

If you’ve read till here it either means you liked our story, in which case you might want to read another Boost case, or that you would be interested by a Boost yourself? If so, give us a shout. And whatever your reason, thanks for reading our post!

This story was first published on Medium for Central.