• Use of boolean logic

  In order to support the dynamic nature of customer data along with the complex use-cases, boolean-logic style filters were selected. While data comparison is based on the type, filter rules are combined with AND and OR.

• Support for various/multiple data types

  Filterable data types
  String	Integer
  Floating point number	Boolean
  Date	Timestamp
  Raw (base64/binary data)	Array( of types defined )
  Object ( n-number of key/value pairs )

• Data comparators and relevant UI control surfaces

  While the combination of filter rules are limited to that of AND and OR, data of a specified type may be constrained with the following:

  Supported Formats	Comparator Operators	UI input for data types
  currency	Equal To	Input
  int	Not Equal To	Multi-Input
  percent	Less Than	Select
  email	Greater Than	Multi-Select
  plaintextarea	Greater Than Equal To	Range
  richtextarea	Less Than Equal To
  select	Between
  text	Not Between
  url	In
  date	Not In
  timestamp	RegExp
  float	Not RegExp
  location

• Support simple to very complex logic

  Most often, only a few filters may need to be applied to generate the desired result however a user may need to apply many filters using a combination of logical operators to achieve the desired result. The control must allow for both the simple use-case without being intimidating while supporting a power-user to create the complex.

• Compact

  By design, the number/size of filters is not limited and can become very complex. The design needs to allow for one to many filters and filter groups to be applied while still remaining readable.

• Constrain user input to prevent impossible filter combinations

  A user could combine filters in an illogical way that would allow for either ambiguity or guaranteed null results. In order to provide a good experience, the components must enforce certain rules by providing relevant feedback/errors, preforming actions on behalf of the user and hiding/showing options in a given situation.

Where the existing opportunity filter used a subtractive approach, the final design uses an additive pattern to build the filter. These two types are depicted below:

Subtractive filtering pattern

This is a common pattern, typically when the content has a finite set of criteria on which to filter. For example many e-commerce sites utilize this type of filtering, where all options are listed and selecting one reduces the main result set. This is not ideal for a Commit customers as their data is driven by CRM which does not limit the number and type of data fields that can be defined.

Additive filtering pattern

This approach is to start with no parameters and add in only what is relevant. It renders a clean empty state that is less visually intimidating than presenting all the possible filters up-front. This pattern is less common among consumer and e-commerce sites, and more common in digital applications that interface with large data-sets, such as geographic, weather, documents and financial.

I created three designs to explore concepts, working with my product manager and UX team to gain feedback of what works and what doesn't. The designs are disucced in brief below.

Concept 1

This design does a good job at minimizing the complexity, albeit at the expense of readability. The consolidated filter condition removes too much information, requiring the user to click into the item to understand the full definition of the filter. Additionally, the portability of the filter conditions does not offer much in the way of clearly defining boolean grouping logic.

Concept 2

This design is clear and functional allowing flexibility and clarity, however, limits the amount of complexity a user can define. Filters are confined to group, located a static depth.While this would likely serve the needs of most users, the server-side model allows for infinite nesting of groups of filter definitions, which is realized in the next design iteration.

Concept 3

This approach extends the previous design by allowing for the creation of groups within groups. Indeed, the data structure can quickly become complex, but only as much as the user desires. The graphical group structure does well to demonstrate boolean relationships while serving as combiner user input.

I created a functional prototype of the final design to test with users. The prototype was built using React and consumed static data. The prototype was used to catch any usability issues as well as to validade the generated object structure. Most of the React components were reused in the final deliverable.

After buliding the production version of this component, it was implemented in several disparate areas of the client/admin apps. The current version has undergone design iterations, however has served as a model for other filtering applications within the organization. The example below shows an implementation with a real-time data preview to validate filter results.

Initial concepts presented to willing participants for general concept feedback and rough interface development. Initially, the central idea was called a Bright Idea: a suggestion to preform some relevant task, how to do it, average difficulty, time needed, etc. Some of the suggestions had the option to hire a professional, if we had the contract and pricing setup.

Secondary functionality is a "Punchlist," or a to-do list automatically created by scheduling a service professional or from a Bright Idea. Items entered on the Punchlist are also a source for automated recommendations.

To identify functional requirements to start on development, I created concept flows for each section of the application. Flows start with an input, provide the possible actions and outcomes, then define an exit point. With this defined, a server-side developer can begin to created the application API.

The web interface was developed in parallel with the mobile app, both utilizing the API. The major difference between the two is how a user sorts through Bright Ideas. Instead of a seeming infinite feed, like Facebook or Instagram, we pursued a card stack concept, as the user may only have a handful of suggestions at any given moment.

Another interesting concept was the input mechanism. For each service we were able to compile a formula to generate a finite price for the service processing a few input variables from the homeowner. Instead of a standard form, we used a Mad Lib. While this was arguably more verbose, it made the data collection feel more personal and fun.

The app was public and we were driving traffic through promotions and advertising, however our customer base was still small. We formed a list of customers and potential customers who fit our target demographic and I constructed a semi-structured interview to sus out what we were doing wrong and what we should be doing.

The two main takeaways from the interviews were:

• The app is nice but too complex for what they wanted
• The homeowner would like to talk to someone, either over text or phone

Design iteration and refinement was ongoing through out the project. We used a subset of customers for feedback on the application in exchange for service.

The app was public and we drove traffic through promotions and advertising, however our customer base was still small. We formed a list of customers and potential customers who fit our target demographic and I constructed a semi-structured interview to sus out what we were doing wrong and what we should be doing.

The two main takeaways from the interviews were:

• The app is nice but too complex for what they wanted
• The homeowner would like to talk to someone, either over text or phone

The solution we came up with to address the barriers of use was something called "Haven Now." It served as an asynchronous request to our customer CRM. A customer could call or text member services to discuss and schedule service. They would place the order in the admin site, which would then be reflected in the customer app as a transaction and item placed on their Punchlist.

The two major issues I saw with the original idea were those of patient experience and practicality.

After completing the original RFP, I drafted and presented a project outline as an alternative to the requested project. Here are the main take-aways:

• Re-develop the Flash application to use HTML/Javascript
• Package the new application into an iOS app
• Purchase iPads in favor of single-purpose kiosks (cost-savings of 75% per device)
• Once distributed, develop additional apps to deploy remotely, leveraging existing capital investment

A patient would be presented with the iPad at check-in to complete the quiz seated while waiting.

The benefit for patient:

• A more private, comfortable experience

Benefits for client:

• Smaller capital investment
• Opportunity to utilize hardware in the future

Benefit for our company:

• Larger project with increased likelihood for future work

Before starting on design and development, I spent a day in the office of an eye care professional, observing how a patients interact with the staff and their physical environment. Data collection included who they spoke with, where they were within the office and for how long, average idle time and opportunity for engagement with the product.

Take-aways:

• If patients are to complete the quiz within the average wait time, it needs to be short and efficient
• Having a portable device allows the practice to be flexible in implementing

In addition to these, a very useful feature was discovered. After completing the quiz, the patient often referenced the results. To facilitate this the results are automatically emailed to the practice, printed out and included in the patient's chart. Patients, stakeholders and eye care professionals really liked this addition.

Two high-fidelity interactive prototypes were made. The desktop version looked and behaved as a direct port from the existing Flash application. The mobile was completely re-designed for a touch interface and to make better use of the iPad's screen size and shape. Special consideration was given to contrast and size, given the end-user inherently has less than perfect vision. Both versions utilized a mocked API, as it was in development.

User-testing was preformed with 12 participants from a recruiting company with criteria of age and glasses-wearers, among others. They were given tasks to preform on each interface, half using the iPad first and the other half using the desktop first. Participants were recorded preforming each task both on screen and on video for post-analysis. They completed SUS then had a structured, open-ended interview about their experiences.

The main take-aways from user-testing:

• Provide better instructions
• Improve interface responsiveness (feedback as a result of user action)
• Inform the user of length and their progress (status bar)

The client stakeholders distributed the application to the top 100 practices by their metrics, with some locations having multiple. Usage measures included tracking by practice, quiz starts, completions and abandon rates. These numbers were used to compare sales within the practice, and indeed there was a positive correlation with quiz completions and sales.

The quiz and hardware were incorporated into a subsequent project, a product education and reward program for eye care professionals. Part of the curriculum involved how best to utilize the EyeGlass Guide in-office. Additionally, completing enough modules allowed practices to receive an iPad preloaded with the quiz and other branded tools.