Case Study: Using the Design Thinking process to create a native mobile application

Summary

In this case study I’ll show how the Design Thinking process was applied, and how this approach helped the team focus on solving the customer’s problem over the company’s problem.

• New features had to be added to an existing app that was approaching end-of-life, so resources were limited.
• Although a full facelift was not in the scope of the project, I was able to design a product that met the customer’s needs but stay within the business requirements.
• The result was an intuitive interface that became the roadmap for future products.

Background

• Vantage is a subsidiary of Legrand
• Equinox is a line of smart home products sold through a network of Vantage dealer-installers

Equinox Smart Home systems bring millions in annual revenue

• The business impact is highEquinox Lite is an app that controls Equinox smart home systems
• It is a legacy product that is approaching end-of-life but must be supported for 2 more years
• The UI is 10 years old and needs refreshing

The screenshots from the app store show how dated the UI had become

The Problem

• The app doesn’t have HVAC controls (Smart Thermostat)
• Because the app is approaching end-of-life, a full facelift is not in the scope of this project
• The HVAC controls must meet modern design standards, but fit into the existing app

“We want you to design something that looks new… but not too new, because it’s going to live next to something that looks old and we’re probably not going to update the old part.”

Getting Started

• In the past, the Product Requirements Document (PRD) was the typically only information that was given to the UX team
• This was the extent of UX research and discovery
• UX Designers in the past had been used just for graphic design tasks.
• The Vantage team was not familiar with the Design Thinking approach.
• This was a training opportunity.

These are slides from a training presentation that we created to help kick off projects like this.

Empathy/Research

Is the problem really the problem?

• The problem is not “the app doesn’t have HVAC controls,” the problem is, “the customers can’t control the heat and AC from their phones.”
• Are we solving our problem or their problem?

Personas and journey maps were created for this project. The assumptions

Personas and journey maps are some of the tools that were used to help ensure we were addressing the users’ needs. This helped guide our user research.

Questions that needed to be answered during this phase:

• Who is my user?
• What matters to this person?
• Why are they a customer?

Throughout this phase of the project, the aim is to validate our assumptions about the user. We want to make sure we fully understand their needs, and that the product team really understands the “why.”

Define

In this phase of the project the aim is to define all the features and user interactions that are required for a minimum viable product (MVP).

A user flow chart helps map out all the user interactions

This phase of the project is when we would typically work with the product owner to finalize other documents such as the Product Requirements Document (PRD) and/or Business Requirements Document (BRD).

Important considerations during the define phase include:

• Do I fully understand the product requirements and deliverables?
• Do I have a realistic timeline for delivery?
• Have I covered all of the expected features in my user flow?

Ideate

This is an example of the low-fidelity wireframes that are created so we can begin testing the user flow.

This is when the product really starts to take shape. Unfortunately, this is a step that is often skipped. It’s tempting at this point to jump straight into hi-fidelity mockups, but in my experience, every hour spent in lo-fi saves two hours in hi-fi.

Important considerations in this phase:

• Do my wireframes include all the features and interactions that have been outlined in the user flow? Is anything missing?
• Have I created the shortest path for each interaction?
• Is this intuitive, even without the supporting design aesthetic?

Prototype

This shows some of the dozens of screens that were mocked up for this project

Prototyping is what people think of first when you tell them you’re a UX Designer (this includes people that actually work in tech). But this type of design work is only about 25% of any given project.

Important considerations in the prototype phase:

• Are my design files clean, sustainable, and transferable to another designer?
• Is this design as intuitive as possible? Can a new user get from point A to point B without help or on-screen instruction?
• Have I followed best practices for Android Material You and Apple HIG standards?
• Does this meet WCAG 2.1 accessibility standards?
• Have I considered the context where this will be used? (Inferior hardware screens, low-bandwidth connections, etc.)

Test

“In God we trust. All others must bring data.”

No matter how great your designs look, you don’t know what you don’t know. The only way to uncover these blind spots is to get the voice of the user. A lot of data had already been gathered through user interviews but now that we had a prototype it was important to continue to validate our assumptions.

Important considerations during the test phase:

• In preparing my test cases, have I been clear on my discovery questions?
• Is my test methodology or medium best suited for answering these questions?
• Am I introducing bias in my test methods?
• Are the friction points a result of the design or the testing vehicle?
• Does the sample user group accurately reflect my target personas?
• Is my testing data a large enough sample size?

Launch

Product development can usually go one of two ways. Agile development usually means that the dev team will be building and releasing while the designs are still being perfected. Waterfall development usually means that the designs have to be pixel-perfect because the devs are going to be working asynchronously with the developers. There are advantages and disadvantages to both, and in this case, the waterfall approach meant that we were able to prioritize testing and validation before handing the prototype over to the dev team. This meant that we were able to go into development with a high degree of confidence in the prototype.

While we were confident that we had addressed the users’ needs as well as the business requirements, it’s still important to continue validating and collecting data.

Remember, the project might be complete, but that doesn’t mean the product is.

Keys to a successful launch:

• Alpha and Beta tests
• Apply analytics to collect quantitative and qualitative data
• Create a maintenance plan and begin working on future improvements
• Continue to iterate using by repeating the Design Thinking process

Outcomes

• Development went faster than normal because testing and revision were done in the prototype, rather than in the code base.
• Because the prototype was thoroughly tested prior to development, the beta launch was able to focus only on bug fixes, not feature improvements.
• Although the app is still scheduled to be sunsetted, the updated design became a roadmap for the future replacement product.

Key Takeaways

• We don’t always get what we want. This project had serious scope constraints that had to be adhered to. Teamwork sometimes means compromise.
• We can’t design in a vacuum. The larger ecosystem affected the product requirements. This design has to work on older LCD touch panels.
• You don’t know what you don’t know. Without usability tests, we wouldn’t have discovered some glaring blindspots
• Every scenario has to be accounted for. Even the edge cases have to be accommodated. The one-time-use features such as first-time setup are just as important as the everyday features.