innRoad
Property Management Software
innRoad is a property management system that services thousands of independent properties each year. From bookings to comprehensive reporting, innRoad provides an essential service to property owners.
The Task
innRoad is an all-in-one, cloud-based property management system (PMS) that provides a variety of services for it’s users. One of these services is a reporting system that allows users to generate reports that show property analytics, guest bookings, guest information, and more. My task was to enhance the user journey when accessing reports by clarifying the steps needed to generate reports, while also creating straight-forward terminology and support systems along the way. Users needed to understand reports, generate reports as quickly as possible, and not have to think twice about what they were doing.
Role
Lead UX/UI Designer
Tools
Sketch
InVision
Trello
Team
Phil Markunas (PM)
David DeAngelo (VP of Product)
Peter Ku (Lead UX/UI Designer)
The Research
To better understand what our users wanted, innRoad provided me insights they had gathered through user research. I also held discussions with the sales team and customer service teams to see what the common wants and pain points of our users were. I knew that these teams hadn’t conducted user research in the traditional sense, but they had countless conversations with users and would be able to provide me with valuable information. Through this discovery, the high level problems that kept occurring were:
Inability to access reports quickly or efficiently
Report input fields were confusing/tedious to complete
Users often request reports from innRoad that were already available in the system
Users weren’t able to get the exact reports they wanted so they had to find their own solutions to do so (ex. export data to excel to customize data)
From reviewing these problems, I knew that most of my efforts would be focused on clarity and simplification. There was a lot of emphasis on not being able to complete essential tasks in the system, and users were having a difficult time completing “simple” tasks.
The Journey
Now that I had an understanding of the problems that our users were facing, I wanted to pin-point the moments they were facing these problems. To do so, I quickly created a journey map to get a firm grasp on which areas in the innRoad system I needed to focus my efforts on.
I also created a journey map because during the discovery phase, I found that there were two users groups to be accounted for and I wanted to see where in the system their paths diverged and/or converged.
While mapping our user’s journeys, I found something very interesting. The needs of each group were similar, they had just found different solutions to their problems. The “power” user filled out their reports by finding their own solutions (ie. taking screenshots of how they commonly filled out their inputs to use as reference), while the “casual” user would call customer support and essentially have the report filled out for them. Seeing that the pain points were the same for both users, I was confident that creating a system that emphasized simplicity and support would be the best approach.
The Solution
Keeping simplicity and support systems in mind, we prioritized a few key solutions that we felt would be most valuable and feasible to implement.
Reports Landing Page
With our solutions in mind, I began sketching some landing page ideas and weighed the benefits/weaknesses of each design. The goals we wanted to achieve were to give users a clear idea of what the report was about before they clicked into it, and to expose all the reports that we had available.
From these sketches, my product manager and I chose two directions we wanted to flesh out and continue exploring. I developed lo-fi wireframes and continued to weight the pros and cons of each approach.
We wanted to quickly expose all the reports that were provided and felt the “List View” was best for that, but it needed to be more informative. The “Card View” seemed to provide a good middle ground, but could be tedious to scroll through once users were familiar with what each report was. Reflecting on these points, we continued to improve on the “List” and “Card” views.
Switching Directions
A big challenge I faced while designing was exposing all the capabilities of reports at a quick glance. There are so many intricacies involved with each report and I found it difficult to find a balance between giving a clear general description, showing sub-categories of reports, and showing all reports available in the most concise way. We wanted to create a more informative and compact landing page view, so we worked through various iterations to come up to a better solution.
Ultimately we settled on a “mega-menu” style homepage that mimics drop downs commonly found on e-commerce sites. We decided on this because we felt it was a great way to showcase all reports and their sub-categories available at a quick glance. We also simplified report names to be more easily understandable and included an in-depth preview for each report.
The compact “mega-menu” view was our primary focus as it achieved the primary goals we wanted, but we kept the card view as a toggle option as we felt it was good for discovery as a new user.
Saved Reports
While developing our landing page, we also worked on building out a saved reports area. Allowing users to run reports at the click of a button, without having to repeatedly fill in the same inputs everyday, would greatly cut down on user time spent generating reports.
The list view we previously tested as a report home page worked well in this format as there was less information users needed to see for their saved reports.
To accommodate for the use case where users would save many variations of reports, we included the ability to pin reports
Reports
After having a firm grasp on what our landing page would look like, we focused our efforts on re-designing the actual reports themselves. Our main focus was on creating intuitive input fields that were consistent and easy to complete across all reports. Our users expressed issues with overwhelming input fields that had too many confusing steps and terms, so we wanted to simplify this process as much as possible.
Exposing Essential Info (Input Field)
In order to not overwhelm users, we exposed only the most crucial inputs needed to generate a report on the left hand side and placed “Optional Report Inputs” (inputs rarely used) collapsed on the right
Segmenting Universal vs. Report Specific Inputs (Input Field)
We also segmented input fields into steps in order to guide users when filling out information, and also to use as a design format for all of our reports
Step one: universal inputs that apply to all reports (dynamic date ranges given to adjust for saved reports run on different dates)
Step two: Report specific input field that varies across reports
Simple Design Takes Effort (Generated Report)
The designs for the generated reports were focused on making information as easy to read as possible and generating a design mold that all reports could fit into. Important report inputs were placed top left, top level categories represented by blue text, aligning numbers on the right hand side, and much more were taken into consideration.
This project was a good way to push my thoughts and limits as a designer. As the only designer on the project, I was forced to quickly come up with solutions while still taking the time to explore many different approaches for the best solutions. Luckily I had a great PM that took the time to come up with ideas, work through iterations with me, and provide support each step of the way. Working closely with someone that wanted to explore each solution to it’s full potential helped me to realize that there’s value in every idea. Overall, I’m very happy with the work we were able to accomplish and saw this as an invaluable experience in my career.