Why Comfy was ready for a UX overhaul 

Comfy's original mission was to solve the number one complaint in offices: temperature. 
Over a few years the feature set rapidly expanded to include other workplace amenities: lighting, work requests, room booking, and desk booking. The floor map (part of the original app) grew in complexity as well. 
As a fast-growing start-up working to be nimble, the design and dev teams simply opted to add these new features as individual pages in a bottom nav. The user landed on the floor map when opening the app.
This structure posed multiple problems from a UX perspective:

•  Users reported landing on the floor map was daunting and the call to action was not  obvious.

•  As more features were added, the bottom nav had no place to 
grow. We reached "peak-nav"!

•  The need for a dedicated home page grew not only with the additions of new features and growing complexity of the app, but also as a request from customers.
​​​​​​​
Goals for success​​​​​​​
Welcome and orient users on launch of the app. Give them a complete picture of their workplace experience in a single, convenient view. 

Introduce a modular card system that can allow new features and micro-services to be customized and released quickly. 

Make a high-impact first impression for enterprise customers and pitches with the wow factor of a premium workplace experience app. 
​​​​​​​
The TEam
Front End Engineer, Product Manager, Junior Product Designer, & VP of UX 
My role: Lead UX/UI (Research, Wireframing, Prototyping, Dev Specs), Visual Design (updated style guide)
PLATFORM Challenges 
Comfy is a hybrid app built in Cordova. With that, it’s a single code-base for mobile and web. The app is available on both App & Play Stores, but they are not native nor do they have many differences in look/feel. The desktop app is fully responsive and optimized for all modern browsers.

The hybrid model is great for a small development team, but poses a good deal of challenges related to breakpoint optimization and the tricky back button navigation of Android vs. iOS. These two elements played a major role in the remainder of the project. 



User Research: Phase 1

User research was conducted in two phases. The initial phase consisted of compiling divergent design ideas mainly to solve for the “peak nav” issue. This was complemented with a round of user interviews with click-through InVision prototypes. The outcome of this round confirmed that users were able to confidently navigate the app without a bottom nav. It also surfaced technical questions and scoping concerns for our dev team mainly related to the hybrid nature of our codebase:
•  Without a bottom nav, how can our hybrid app utilize a back button fluidly on mobile in both iOS and Android?

•  How will a card based system behave at different break-points? Especially the odd in-between “phablet” sizes. 

•  Can we feasibly remove the nav, build the cards and support side-scrolling elements on top of them in the first phase of development or do we need to design for multiple phases?

•  Can the team support uploads for a profile photo? 

Wireframing with an unexpected tool

To iterate quickly on the questions created from the initial research, the team decided to use Google Slides to pair on wireframes. This was the first time I had used Slides for this purpose and was skeptical, but in the end, I found that I enjoyed the process and the ability to get very rapid feedback from the team using this simple tool. 

The design team presented the wireframes to our dev team who provided feedback on technical feasibility and timelines for each option.
Prototyping for user feedback

With dev team feedback in-hand, I was able to build the first round of prototypes. We created three options that were utilized for testing purposes.

Option 1: No Nav with a Search card
Option 2: Floating Action Button for Search
Option 3: Bottom Nav with Search in Header

User Testing

Option 2 was quickly ruled out as only three out of ten users tapped the floating action button. Therefore it became a mater of bottom nav or no bottom nav. A basic click test was set up through User Zoom to validate the navigation structures.  
The heat map imagery showed us that users were able to successfully complete all tasks with wither nav structure. There was an overwhelming preference from our executive team to strive for the no nav version to de-clutter and elevate the style of the product. Since user testing showed no problems with that, we moved forward.
REady for Hand-off
After synthesizing the research and getting the go-ahead from PMs and the dev team, I began developing matrices for every permutation of feature sets a customer could have and how that would appear in the app. I also crafted a detailed dev spec document in Jira Confluence. Working with the lead developer and PM, we drafted high level stories and prioritized them in the engineering backlog.

As the stories went into development, I began refining visual design updates. These were compiled into InVision’s DSM style guide tool that could be synched with Sketch in order to ensure the latests assets were up to date.​​​​​​​
The future has endless possibilities

The new enhanced welcome experience sets the stage for a full roadmap of enhancements,  including endless card customization, enhanced amenity information, and step-by-step navigation. It also provides users with the tools they need to be their most productive and engaged selves at work and customers with the ability to satisfy the individual needs of their building environments.​​​​​​​

Other Cool Stuff

Back to Top