BoutiqueHomes is a vacation home rental company. To stand out from the competition, one initiative was to allow property owners to list their accommodations under a single listing. A single listing would provide travelers the full picture about a property and make it easier for them to book multiple accommodations at the same time.
The problem was their existing content management system (CMS) wasn’t set up to allow such properties to be published. In collaboration with the founder and developers, I redesigned the CMS.
There were several challenges in this project:
I sat down with the stakeholder to understand the business objective, background information, and requirements for the design. We would later regroup several times throughout the design cycle to revisit the strategy and ensure advancements were being made.
One area we discussed was structuring the backend system to support the creation of multiunit (MU) properties. The only difference between listing a single versus multiunit property is that the multiunit property would have unique information about each unit.
Instead of replicating the pages required to list a property for each subunit of a MU property, I proposed isolating the data required for a property listing (“overview”) and having pages specific to unit information separate. This way, content that pertains to all units were filled out once and content specific to each unit would be filled out on a one-by-one basis.
With the strategy in place, I analyzed the current workflow of admin users to identify pain points and areas of improvement.
A takeaway from this exercise was revisiting the information architecture. Different admin users work on different parts of the property listing, but they were sharing the same page to enter that data.
As mentioned, a partial design was created before I had joined. I mapped out the fields from the original pages to the partial designs. The partial designs had content in different places as well as new and missing fields. After interviews with the stakeholder and developer, I was left with the fields we would keep in the final design.
I developed a card sorting study to understand how users would group the fields into pages based on their needs for the new design.
Based on the information I had learned during the research phase, there were several features I wanted to incorporate into the final design.
I sketched ideas for the multiple pages of the backend interface. Storyboarding was one technique that helped me visualize the workflow of admin users for the Images page.
The stakeholder and I sat down and sketched our ideas for how the template should look—primarily the navigation. After exploring different designs, we had two concepts, which I asked users for their feedback.
Users described the designs as “clean” and “well structured,” but were split between the two concepts. Ultimately, we moved forward with design A since its navigation on the left sidebar allowed for important content to appear higher on the page.
From there, I designed clickable prototypes that provided a near reflection of how the experience of publishing a property will be in the redesign. After a few rounds of usability testing, I iterated the design, received the go ahead, and prepared the final handoff for programmers.
The result is a finished interface that keeps the familiarity and functions of the old interface, but accommodates multiunit properties and streamlines several functions for improved usability and greater efficiency.