I worked as Product Designer. I would like to share our design process and my role within it to showcase my recent work. To keep it short, I will focus on the most fun part of every project—finding and solving problems!
I worked closely with the Managing Director, off-site Development team (DevBBQ) and Sales team to create first version of our product.
1. Low fidelity wireframes in Sketch first.
My goal in this project was to create working prototypes as soon as possible. I started from simple wireframes and continuously added more styles.
The benefit of using only two tools during the whole process was that the transition between low and high fidelity was really smooth. I designed the website thinking about the development process to make it easier, quicker and more effective.
I use low-fi wireframes to discuss and test solutions using User Personas and then interviewed the team. I like to play with product and to design by interacting with it rather than stick with Sketch files all the time.
2. High fidelity prototypes from Sketch to InVision.
After choosing a couple of the best solutions, I applied styles and exported the project into an InVision library to create the first prototypes and arrange the first interviews.
Clickable prototypes are simple as InVision is still quite limited. However it works well when you test only few elements at a time.
It also very effective, because you can duplicate source files to modify existing prototypes within a minutes and test it again.
3. Design. Test. Learn. Improve.
I used four simple steps, a loop to design better products. In the early stage, it was enough to test the product with 2-3 people and increase the number along the process.
Prototypes are becoming more and more advanced. Prototyping helped me understand customers and identify issues in the early stages when fixing them was still affordable. Obviously, it did not work perfectly and there were issues I did not identify, but there were significant improvements with every prototype.
Following this approach, we've defined 3 main aspects that needed special attention. We wanted to make the website accessibile for everyone with real-time inventory. We wanted to digitalize the process of buying a new home and create the best experience.
In the traditional way of selling real estate projects, customers need to register for updates to get access to inventory or contact brokers for help. Many people weren't able to buy units, because it was too late. Brokers, on other hand, generated additional costs.
Clients complained about difficulty with searching and comparing units. There are usually tens of different layouts and even hundreds of units available within a development. It is very challenging for people to find the best offers. We've also learned about issues with double sales and following up with clients.
At the moment it is not possible to finish a purchase online and we needed to create an effective and safe way of buying new property. We wanted to create a great experience and build trust to put customers in comfortable position to spend $3000 to reserve their selection.
At first, the clients wanted to have pre-registered access and customers would be required to create an account to be able to see inventory. However, I was convinced that we should let people explore the website on their own and require an account only to make a purchase.
We can't force clients to create an account and building a database wasn't our priority. It was supposed to prevent brokers from using the website, but we needed to take action against them without harming customers experience. I've suggested specify rules in the Terms & Conditions. Users need to agree that they won't use the website for brokers purpose when signing in. We've contacted lawyers and confirmed that our solutions are legal and can be implemented.
In the end, we've agreed to give public access for everyone and clients are required to create an account only to add a unit to their Save List and/or Proceed to Checkout. I think it is unnecessary, but designing is about team-work and finding compromises.
We’ve started designing mobile-first as the website will be used to sell units during launch parties when people will use their smartphones and tablets. Ohme is also designed as marketing tool for sales teams which will be used during meetings without easy access to desktops.
Our client’s new development site included almost 200 units within 41 different layouts. Each layout has from 1 to even 40 available units. Research helped us understand how important is to make inventory dynamic and that finding the right unit can be super challenging. We’ve organized it in 3 groups:
1. Number of bedrooms (Category)
Each unit is defined by number of bedrooms. New phase is supposed to include 3 groups: 1 bedroom, 2 bedrooms and 3 bedrooms units, but just before launch we needed to add one more group: Studios.
We've designed the website to be as flexible as possible (thinking of future white-label version) and this change was simple to apply.
2. Layouts (Search Results)
Layouts appears in search results. We are displaying if unit included dan, balcony and bathroom as well as size of interior, available units, price and how many times selection was viewed (basic informations).
We’ve indicated trending layouts and push them at the top of the page with notification “Trending” or “Last Chance” to help customers see most popular offers.
3. Units (Product Page)
One layout can have from 1 to over 30+ available units (which are the same, but are placed on a different floor or side of the building). Each of them are actual products that customer can purchase.
I’ve experimented with Product Page for long time doing many tests and trying to figure out the best solution. We’ve ended up with a drop-down list which included all available units within selected layout and basic information like suite number, price and side of the building.
Every time a customer selects a different unit, the basic information is updated. We needed to expand loading time and add a loading animation to show the differences.
Last but not least, we wanted to build trust so people will actually purchase their selections. I can’t tell if our solution actually works, because our client had to cancel the launch party and hold up sales. However, we’ve spent a lot of time to test and try to understand our client’s customers.
The process is simple and we wanted to make it as transparent and clear as possible. Customers like to take their time with searching and comparing suites. They can save their favourite units and access them very easy. At first, clients were required to add selection to their Saved List to Proceed to Checkout from there, but tests showed that it was too complicated. I’ve simplified it and added Proceed to Checkout button on the Product Page.
Customers need to create an account to do both of actions. They also need to confirm their email address to access checkout. Proceed to checkout lock suite for client ID for 30 minutes and remove it from search results. Checkout has two steps: Details and Payments. Payments are provided by Stripe and we require $3000 deposit to reserve selection.
Final action is Booking an Appointment. Customers have 10 days to get in touch with Sales Team to finalize the deal.
As I mentioned, there is much more to be said about this project and I would love to discuss all details in person if you are interested. I’m currently in Warsaw and I would love to get in touch.
You can reach me via email firstname.lastname@example.org or give me a call +48 733 314 880