01 - Challenge After successfully launching our Resident360 product, a tool for consolidating Care data in Senior Living, we got overwhelming feedback from the Sales side of the business that they wanted a similar solution. The focus in Senior Living at that time was increasing move-ins, and so the Sales team needed to find ways to use their data to better evaluate trends and identify what was and wasn't working. Many customers and prospects had spent a lot of time investing in their own solutions but what they lacked was the experience we already has with pulling their systems together.
02 - Research Up until this feature, our business had been targeting Care personas. These were usually staff members who were inside the Senior Living communities themselves and very hands on with residents. Now I needed to start thinking about the new Managerial and Executive level personas and how we would cater to their different needs.
User Personas I created a research plan, and with the assistance of our Lead Engineer we conducted user interviews with participants which matched our profile. We interviewed individuals from the Sales, Ops, Finance and Care departments of our customers, targeting those in executive, regional and community level roles. We then validated our insights with a trusted resource who had deep knowledge of the industry and created persona cards. These would be the reference point for who we were designing for in our venture into a new level and area of focus.
User personas for Sales roles at Executive, Regional and Community levels. Colors
Data Visualizations On the main Resident360 experience, I delved into visualizations in the form of a timeline component that displayed datapoints for resident activities. Now I needed to account for complete charts and graphs that could accurately represent very nuanced KPIs. With the help of my Front-Engineer teammate, I found we could leverage an existing library, D3. With D3, we wouldn't have to build chart from components from scratch, and could tap into it's vast array of chart types and interaction options.
KPIs I was not responsible for designing the KPIs for the initial Sales Dashboard, but I needed to explore the requirements in order to build the experience around it. This would also help determine the types of visualizations we needed to accommodate and hence the layout and space considerations of the UI. Our CEO, Eng Lead, Frontend Eng and I developed a set of proto-KPIs that I used to build the interface around.
03 - Sales Dashboard Design Although there was a solid foundation to work from, I needed to introduce some new elements into our component library. These needed to be thought through in order to fit with the experience. We also needed to account for the mobile experience. I went to work build lo-fi mocks for the main components of the UI
Grid Initially, it seemed natural to use 1/3 column cards layout, but I started to realize the need for more space on some particular KPIs. For instance, for the Length of Stay KPI, the KPI was cohorted and best displayed in a stacked bar chart. It also required significant horizontal space as users tended to want more datapoints for this KPI. I landed on two card types: a full width card and a 2 column card.
Filters A core part of a KPI are the variables that determine them. Timeframe, granularity, etc. For the KPIs in Senior Living, I needed to understand the filters that users needed in order to get all the data outputs they were seeking. Using the insights from persona research, I pulled a list of filters. There were two categories of filters, fixed and dynamic. Fixed filters are things like Time period, where the options are standard across customers and accounts. Dynamic filters are things like Properties, which are relevant to the current account. Based
Time period Date range Care Levels Property Type Properties Cards 04 - Data Explorer (Drilldown) Chart Secondary Filters (Contextual Filters) Data Tables 05 - Launch 06 - Results
