At Balzac's coffee, this is where Tammy and I did most of our profound design thinking.
From January through to May (2012), I had the opportunity to work on the interface behind Encircle's
mobile & web experience. At the time of this design scrub, Encircle served as a cross platform app aimed at providing a dynamic home inventory.
The design has changed since then, understanding that user experience is an ongoing dynamic process,
here are some notes about what was learned during a short period of immersed focus. User feedback via in-person interviews, phone calls, & emails were collected at an ongoing basis to drive the needs of the design. I'm glad to have collaborated with Tammy
(teWinkel), a UX strategist/architect with much experience in the domain of UI and UX. She has been nothing short of a great mentor.
A video about Encircle explaining the value of a home inventory.
Creating a strong user experience is about taking the bigger idea and translating that bigger idea
into smaller pieces that then get manifested for the user to interact with.
Encircle is an app that manages a dynamic home inventory, within the inventory is a number of objects that we defined as 'assets' which users are able to track. We assigned 'structured assets' to objects with a model/serial number & 'non-structured assets' to objects without. For example, users could log their home appliances (a structured asset) to track warranties, get product recalls and product support, order parts, request service, or add pictures as proof of purchase.
Design Objective: Study the existing user interface for both mobile and web applications and assess current usability in order to design a simplified interface which would yield the most usable experience.
Process: Start by mapping out the existing end to end experience against the systematic aims of the product. This process was driven by deduction, extracting the excessive steps to the necessities in order to achieve the most intuitive solution.
Organizing the Structure: From Property to Room to Asset
Before the app took any form, these objects that we called 'assets' needed a structure, that structure needed to be comprehensible for the team to build, but also carry a transparency so that users could understand at a hierarchal level where and how their content was being organized. The Matryoshka dolls were a good visual example of how we approached the organization of key objects within the app. This
article from UX Booth talks about the Nested Doll
method under Mobile Information Architecture
in great detail, highlighting the benefits of this scheme.
We drew precedent from the of design of Russian Matryoshka dolls by organizing the app's structure through nesting,
The goal was to design an interface that would support a usable dynamic home inventory. In an attempt to organize the structure, we mapped a user's real world understanding of their belongings through a nested organization where one's assets are contained in a room which is contained within a property. We then took this mapping & transposed it to a digital interface. There were many ways to organize the data library (one big inventory list with great search capabilities, a long list of assets with visual cues, etc.), the nested structure with property/room/asset classification mapped well to a users general understanding of their belongings, so we opted to organize in the same way.
Original interface before design scrub: properties were tabs across the top & rooms and assets lived within the property tab
Our initial proposed interface provides a stronger intuitive nested structured through visual cueing & graphic hierarchies.
This interface is a hybrid compromise from the original design as it maintains many of the key nested objects while tightening up loose design elements. We went with a hybrid interface so that technical changes would be limited which would provide more time for beta user testing to continuously inform usability. It's worth highlighting the subtle visual consistencies as users drill down to asset level. Elements like the consistent header & profile act as a way of drilling down the navigation so that way-finding is clear regardless of orientation in the app.
The design history of the interface evolves from a hybrid compromise to a fully photo-based hierarchy.
Here the interface shows a view of the property, the rooms within that property, & the assets within the selected room.
As the interface transformed to become more usable, the design leaned towards a photo-based app where visual communication became a high priority.
Presenting the Structure: From Collection Level to Object Level
Working through the Collection Level was a valuable learning process because it provided the foundation to understand all the required pieces that would eventually connect to create the Object Level user interface.
Some of the key elements that needed to be included at the Collection Level included:
- Value proposition callouts & notifications-proposition callouts enabled us to request more asset information from users in order to provide more value. For example, asking for purchase date information meant providing a warranty countdown for future maintenance
- Pairing the Collection Level to the Checklist & Tree View for web and mobile interfaces, this includes full & empty states
- Build structure for articles & tips related to each asset
- Within messages, enable the ability to delete the confirmation of messages for objects at all levels while in waiting states. For example requesting model/serial number from user in order to provide product information value
We initially started with a Collection Level based display where nested objects were shown in a list format because it seemed obvious at a universal level to view all belongings within an account but eventually shifted the design (based on user feedback) to Object Level display where belongings are photo-based. This approach made more sense because users naturally map & recognize ownership of their specific assets visually when scanning at a glance through the dynamic home inventory.
The original & hybrid design used a Collection Level approach:
Property, rooms, & assets objects/sub-objects are presented in a list format.
The photo-based interface moves away from Collection Level.
Every stage of the nested structure is now presented in Object Level as picture-based content from the user.
Creating 'The Rinse & Repeat Cycle'
A visually summarized Rinse & Repeat Cycle that would become the introduction narrative to first time mobile users.
The heart of the design really came to fruition in what became known as the Rinse and Repeat Cycle (R&R Cycle). The Rinse & Repeat Cycle was a terminology & process created within the team, it is a modular flow designed to capture necessary data to yield the most value for users in a learned repetitive pattern. The primary task was to efficiently streamline the R&R Cycle so that what needs to be consistent is consistent and what needs to be different different. This was dominantly an exercise in logic & behavior; initially checking to create an efficient & understandable interaction, then ensuring the necessary visual clean up to convey each intent.
Mapping out the flow implied mapping out a method that would easily & continuously encourage dynamic input of critical information to return value to users. For example, mobile users may use the platform to input pictures into the cycle & then use the web application to input text-based information about those same pictures. Streamlining the R&R Cycle ensured the app could continuously request necessary data to provide value & maintain consistent pairing behavior between the two platforms.
Charting out the flows within the app.
Use of Visual & Non-Visual Cues to Create Learned Behaviors
Using a strong iconographic set from the beginning was critical to usability & a clear pattern language.
Visual nesting consistencies emerge here when users begin the flow of adding a property, a room, & an asset for the first time.
Use of the power button as a navigation tool to access sub-menus within the object scope.
Tightening up the architecture & navigation streamlined the usability of the app. Adopting the main power "+" button as a gateway to get from one level of the app to another helped in this effort. By placing the power "+" button in the same consistent spot (bottom, center), the interface begins to establish a pattern about way-finding. This universal button permitted easy access to varying sub-menus for drilling down more info about the home inventory. The fan-like gesture to access the submenu personifies the sense of drilling down the object level. The power button became instrumental to navigating the Rinse & Repeat Cycle discussed above.
Ensuring visual language was paired and consistent for both mobile and web applications.
Here the graphic tally of both asset types (structured & non structured) are equally used in both environments.
Recognizing that users may use both mobile & web platforms for varying purposes (potentially inputting images on mobile & inputting text detail on web) implied the need for a strong visual navigational aids. Small details like the summary of asset types required a clean icon to easily map between the two. Here the tally symbol quickly gives users a sense of how many structured assets (objects with a model/serial number) & non-structured assets (objects without a model/serial number) are within the inventory.
Since the premise for this app is a dynamic home inventory, the ability to search any asset at any time was a necessity. We identified the need for two levels of search, global & local. Global searching refers to searching for relevant information on the internet, while local search restricted the search within the database of the app. For example, at any given time a user could search for a service provider (on the internet) about a specific asset such as a washing machine, or search for a particular asset across multiple rooms/properties. The visual language established to differentiate the two was contextual-based, all global searching was done through the overflow menu (in the top right hand corner of the header), while local search always lived within the sub header of the current inquired object. Ensuring this visual consistency of both levels of search was vital to the success of a dynamic home inventory.
Many of the onboard visual design decisions made sense, but were considered placeholders. Navigation issues were the deeper user problem, exacerbated by the fact that users seldom read.
User feedback (mainly through in person interviews) in the beta round resulted in the need to move towards a design that focused on iconic representation of objects to:
The drawback to this design shift would be many technical changes in a short period of time. So the compromise would be a hybrid interface until all changes could slowly be implemented while continuing to obtain user feedback.
- Better guide the user in movement
- 'Save' the valuable visual space
- Allow necessary text-as-label stand out better in a cleaned up landscape
This would yield more time to understanding the implications of the design change before fully committing to a complete interface overhaul. It would also provide enough time to get critical weighted feedback from beta users.
User Objects & Actions
An object action matrix for structured objects, one of many to aid in a thorough design solution.
The purpose of the object & action matrix was to understand the behavior patterns. It's a necessary tool to map out all the possibilities of each object & its associated function. The matrix eventually served as an interaction checklist, aiding the design by ensuring correct coverage & the use of the right objects to do the right functions inside the interface.
Building a Suite of Transitions & Gestures
Gestures & transitions can be great cues for creating learned behaviors; they can also get confusing rather quickly if there is an excessive amount of them. It was important to make sure that we used gestures and transitions in a logical and judicious fashion so as to allow users to easily develop an accurate model of use. Transitions become affirmative responses to gestures, we curated these to personify the action. An example of this is accessing the global hub (showing global level information about all assets), the transition to affirm this was a screen swap where the current screen (regardless of where you were in the app) would be swapped for the global hub screen. This transition signalled to users that wherever they were leaving to access the global hub was independent of any of the other screens recently visited. Alternatively, hitting the "back" button would translate to a sliding transition to map user behavior of moving through screens that are linked to one another. Meaningful Transitions was a good primer for understanding the construction of our interaction suite.
Creating & classifying a suite of interactions & transitions helped generate simple learned behaviors within the app.
The importance of horizontal swipe transitions within this particular app design.
Transition thinking was a vital piece of the design scrub. Though non-visual, transitions have an impactful contribution to user experience. Analogous to the soundtrack of a great movie, a suite of transitions & gestures can really enhance usability. We used gestures to personify the interaction, for example horizontal swipe within the app was strictly reserved for browsing the asset categories. This made sense because users are no longer drilling down through the nested structure when they are at this level, they are navigating the categories within the asset. Just as the horizontal axis suggests a balance, so the asset categories are visually weighted equally relative to the asset.
Other key transitions include the fanning action that would affirm the call for sub-menu options (picture/text notes, contacts) from the power "+" button. To close the sub-menu the reverse fan transition would occur to personify the parent- child relationship between the main & sub-menus.
Mapping the Mobile Experience to the Web Experience
From analyzinging beta user feedback, the team recognized that there was a time & place for the mobile & web interfaces to thrive.
The quickness of the mobile experience allowed capturing photo content (the primary drive of the app) easily. This built a strong visual library and ultimately proof that these assets came with ownership. The limitation of screen size often became a speed bump for users to input formal text data about their assets into the screen because there was just too much information to input from a smaller device, therefore an opportunity for the web platform to shine. We also learned that the beloved Rinse and Repeat Cycle, as a full cycle, was more difficult to present on the web because there was less control over how to guide the user, hence the "shortened form of the R&R Cycle (i.e., the picture taking cycle became a repeat unit & filing in text content came in later via a modal window interface). The Elements of the Mobile User Experience
was referenced to utilize mobile design for its strengths while equally reserving web for its contribution to the inventory.
Toggling between the Tree View & Checklist View enabled users to simultaneously add in-line information,
contributing to the dynamic graph of asset value against contents coverage.
Once logged in within web, the Tree & Checklist views convey a master-level visual understanding of the app at large. The Checklist View supports in-line detail input to give a user a sense of the level of information they've contributed, while the Tree View permits easy additions of a new property with its suite of rooms & assets. Both views function as a master checklist of the current dynamic home inventory state. These same views are mapped to mobile for at-a-glance viewing in both platforms.
One of the underlying problems we were trying to solve through the Encircle app was the home insurance coverage component, many homeowners do not have the correct quantitative coverage for their properties & belongings. (Homeowners often significantly over/under estimate purchase coverage.) The information contributed from both Tree & Checklist View builds a dynamic graphic where the total sum value of assets is visually compared to the total sum value of insurance coverage for that property so users can better assess the value of their home inventory.
At best, keen home owners compile a static home inventory through a spreadsheet. We recognized the need for a dynamic one because users are always adding value to their inventory through the accumulation of 'assets'. This needed to be accounted for. The app details & its dynamic graph is a reflection of this.
In web, the pop up modal window created a contextual understanding for users to input text-based asset details.
The designed web interface took advantage of the wider real estate to present information & encourage text input. We created contextual understanding by utilizing a pop up modal window with in-line editing of asset information to pair with the mobile app. The pop up window supported the ability to manage many sub-menu items including the ability to add / delete multiple pictures in a room/property in the R&R cycle, add notes to the manufacturer contact, or delete retailers.
And, more Details
Details: keeping a strong visual language within the process, here are drafts of the 'data connection interrupted screens.'
There continued to be a number of ongoing details that all required the same level of scrutiny, these include but are certainly not limited to the following:
- The ongoing terminology sync between web & mobile platforms, requiring consistent monitoring
- Mapping out the matrix of system error messages to account for outlier situations we may have not yet discovered became a detail-oriented task. Topics that needed to be accounted for within this realm include how to classify the error messages, assigning where they go, & how they persist
- A detail issue was the keyboard behaviors for all actions on mobile. Some of the mobile platforms we supported had pop up screens which would reserve half the screen persistently. We also looked at implementing a type ahead system to ease the usability for inputting text data via mobile
- Looking to the future, as we performed the design scrub, we often tagged decisions that would impact the future support site. This meant consistently thinking about design decisions and the implication of those as the roadmap broadened
- As with any design process, we discovered outliers such as rental equipment within a home (ie. water softener and heaters). This required working through the kinks within the text form fields so that application input was constrained appropriately for such outlier assets.
- The various notification types due to the array of inventory possibilities required building a classification set around global/high priority news & the necessary steps to dismiss & persist them as needed
Ongoing Adaptive User Experience Design
Crit sessions=lots scribbles on the fly and building a tangible layered system for critical review discussion with the team
Above are ongoing updated screens of the mobile experience at a scale that handles markups well. Working at this scale (at the very minimum) allowed details to surface that would have been overlooked otherwise - the details make the experience. The physical at-a-glance approach helped map the screens in relation to one another. This was very useful for understanding the pattern language that was inevitably emerging amongst the network of screens & their respective purposes. Quick penned notes work great for on the fly discussions & changes with the technical team.
The ongoing use of shared artifacts to make sure everyone was on the same page- both literally & figuratively was the success of developing a pattern language. The beauty here is that we had an opportunity to keep change front & centre to create a larger shared mind.
Though this case study was for a short period of immersed focus, the design process continues to evolve as necessary.
A challenge, for all UX'ers, is how to keep this continual design interaction alive & well in any project.
Up in the air:
What's the best way to establish a pattern language? Is a mobile to web approach better?
Can a textbook approach make for great UX? Or is it more about tangible real world experiences?
Designing -- and thinking -- continues.