Our Design Journey — From Acquisition to Relaunch
Last June one of Canada’s largest real estate search websites Zoocasa.com was shut down by its then owners. Seeing potential where others saw loss, the site’s assets were purchased by a small, visionary group of Toronto-based investors. Zoocasa was saved and given a second chance at reshaping Canada’s real estate industry.
To say that we acquired a ‘company’ is a bit of an overstatement — what we really had was simply a git repository full of code. No engineers, no marketing team, just some code and the leadership/vision of our new CEO.
The first hire after the acquisition was an experienced CTO, and shortly after I was brought on to oversee product. From there, we spent two months putting out fires — hunting down passwords, removing any mention of the previous owner from the site, and switching from physical to cloud hosting.
After changing the agent model —which was to bring all of our sales team in-house to prioritize improving our customer service — and bringing on individuals in design and marketing, the next eight months were spent completely overhauling the product. We’re extremely proud of the end result!
Read more about our design journey below.
Zoocasa.com is ours. Now what?
Our first challenge was determining a vision for Zoocasa. We had a terrific asset on our hands complete with positive brand recognition and considerable web traffic. Yet we disliked the existing user experience and site architecture.
We could take the easy road and move forward with the status quo, making small tweaks to allow us to quickly get started building new features. Or, we could commission an entire redesign of the styles and a complete rewrite of the front end code using a using a modern Javascript Framework.
We knew that scrapping the old styles and user experience would be better for our users in the end, and would give us a solid foundation for the future to build quickly and with styles we were proud of.
Here are four ways we reinvented Zoocasa to put the homebuyer first:
1. Putting the focus back on search
Users come to Zoocasa.com to find a home. Search had to be the main focus.
Before the redesign, when going to a page such as Toronto Real Estate, you’d be given demographic information about Toronto rather than home listings. In our new version, the homebuyer is taken directly to a map of Toronto with listings available that can be easily filtered. For homebuyers looking for information on the city, there is an area guide in the top right corner. Users are here to find something — our job is to make the search effortless.
2. Expose the main search filters
To help ease the user experience we exposed popular filters such as home type, price and number of bedrooms. This allows for faster filtering and lets the user know which properties were currently being filtered. In the old experience, all filters were tucked away in a dropdown that when opened, covered the entire screen.
3. Preview the listing when hovering on a pin
Our biggest issue with the old experience was that a preview of the listing was not available when hovering over the listing pin. In the new version, hovering over a pin will give you a snapshot of the listing and allow you to access the full listing with a single click. The full listing will open in a pop up on top of the map instead of taking the user to a new page. This ensures the user does need to go ‘back’ and reload their search.
4. Offer a transparent home buying experience
With a new team and business model we decided to build an extensive ‘About Us’ section on our website. This helps users get to know us and learn about our mission, vision and purpose. Here, users can learn more about our journey, our team, and our agents.
Our product design process
Our design processes have evolved significantly over the past year.
As a small team our biggest hurdle is figuring out how to make our processes work as we grow.
Our existing process is as follows:
Brainstorm/Mockup
Before starting any new design, the core team (product, design, engineering) comes together to discuss and offer opinions on the product at hand. Take for example, our ‘listing light box’ (also known as the information that appears when clicking on a listing). We’ll openly talk about what we do, and do not like about the product in its current state, and do the same for competitor’s products. From there we collectively create the initial wireframes using pen and paper or Balsamiq Mockups. An example of two versions of the mockup for the ‘listing light box’ page are below.
Design
After the initial wireframes are complete, a high-fidelity design is done in Sketch to roughly 80% completion. At this point the team meets again to offer feedback, try some changes in real time, and allow the designer to reiterate. For quick design feedback, Slack has became our best friend. It allows the designer to upload screen captures to a product channel and have the team offer quick feedback without having a full meeting. This also gives team members who are not as involved with product development to offer their feedback.
This process continues until we’ve locked in a design that the team is happy with, and have ironed out every design detail such as hover states, button styles, font sizes, error states, etc. The final design of the ‘listing light box’ is seen below.
Code
Deciding on what software to use to track product stories caused quite the heated debate. I had exclusively used Jira in the past, but the CTO was a huge advocate of Pivotal Tracker, stemming from his days working at Pivotal.
After deliberation, we choose to use Pivotal Tracker, and I was delighted with the simplicity of Tracker in comparison to Jira. While it is meant to be used for more agency style development, it worked well for our small team, and we found it very intuitive to add points to stories and to monitor weekly velocity. My only complaint thus far is the inability to customize the story statuses.
The engineers and I formally meet every Monday to look back at the previous week’s finished stories and to ensure our velocity was in normal range, as well as prioritizing the stories for the current week.
QA
Unfortunately we do not have the luxury of having a QA person on the team, and many of the automated tests that were written before we took over the product, were broken and difficult to fix. For QA I went back to the basics with a trusty excel spreadsheet that included a list of over 200 manual checks to make, from visual UX components to making sure leads were submitting to our CRM system.
Takeaways from the past year…
The past year has been one of tremendous growth and learning for us. Here are some key takeaways from the period between the purchase of Zoocasa.com to our relaunch.
1. Originality in design is not always necessary
In the beginning stages we spent a lot of time attempting to create design elements out of thin air. Sometimes they looked amazing, other times, they fell flat, and the process was always time consuming. We learned quickly that we needed to start gaining inspiration from other sources if we wanted our design sprints to be more efficient.
This process is not as simple as copying everything that successful companies have done, but taking design inspiration and making it your own. The quote below sums up this notion well, taken from this post.
“…it’s about being strategic and selective with the process of choosing your influences, taking what resonates with you, making other people’s ideas your own, and being diverse enough to find unexplored points of intersection between your various influences.”
Once we allowed ourselves — and were at peace with — taking inspiration from other sources, designs came together much quicker.
Some of our favourite sources for design are:
· Behance, Dribble, & Pinterest
· Awwwards & Nicely done
· UI Movement, UI Parade, Collect UI, & Product Pages
As well, we looked to some of our favourite sites — Airbnb, Zillow, Square and Xero for inspiration. Our team also subscribes to Sidebar, a daily email that highlights five design articles on the web. If you aren’t subscribed, do it, do it now.
2. Involve internal stakeholders early on in the design process
While I believe it is best not to have “too many cooks in the kitchen” when designing products, there were times however, that we forgot to consult internal stakeholders outside the core design/engineering team before finalizing designs.
Trying to do a total redesign in under a year requires the team to be laser focused, churning out design elements extremely quickly, and this led us to occasionally forget to consult the right people.
There is nothing worse than completing a design, *high fives all around team!*, and someone from marketing lets you know you forgot about X,Y, and Z.
On the flip side, we learned more than ever how and when to say no to feature requests from internal stakeholders and how to justify our design decisions. This article really sums up my experiences saying no as a PM. It is possible to say no and still get invited to lunch.
What’s next for Zoocasa?
After spending some time monitoring our KPIs and ironing out bugs related to the redesign, we’ll be starting to tackle the features on our roadmap. Stay tuned over the next few months as we roll out new, one-of-a-kind tools and features!
