Designing and Building IBM Security’s First Consumer Mobile App
Our design team at IBM in Austin, TX has been busy. Over the last 9 months, we’ve worked with a diverse team of developers and offering managers around the world to design and deliver IBM Security’s first consumer-facing mobile app: IBM Verify.
The solutions our team typically builds are complex, technical, desktop tools for highly-skilled knowledge workers, like security analysts, architects, and admins. These tools operate behind the scenes to secure companies around the world. But IBM Verify was different. Anyone, from an employee at a bank to your grandma, could and would be able to download and use it.
Authentication isn’t something that you normally think about. Its traditional form, usernames and passwords, have come to be a common, easily forgotten, and maligned interaction of everyday digital life. However, with the increased need for more personal security and ever-increasing news alerts of compromised companies, authentication is more frequently cast into the spotlight. Passwords are no longer worthwhile safeguards. They’re easily forgotten and just as easy to hack. Accordingly, there’s both a consumer and industry demand for something more.
Our team was challenged to create a better solution for users to log in to their accounts and to verify who they are without burdening them with the nuances of authentication. We wanted to provide users with both piece of mind and ease of use — all while including an additional step in their workflow, an idea counterintuitive to traditional user experience outcomes.
Our mission was to make high assurance authentication frictionless.
We identified four users at Federal Credit Union (FCU), our example client, who would touch different aspects of our experience. Based on our research, we developed four in-depth personas and three main “hills”, our guiding problem statements for the project.
Jessica, the End User
Jessica is focused on signing in to FCU and using her online account. Be it transferring money, changing her mailing address, or paying her credit card bill, she just wants to get it done and be on her way.
Anything that isn’t as easy as a fingerprint on my phone just gets in my way.
Scott, the Security Admin
Scott is responsible for the back-end administration of Identity and Access Management (IAM) at FCU. He sets policy for who can get into what, and how they do it.
I want a quick, expedient, stable way to get it in production quickly, so integration is super important.
Alice, the Mobile Developer
Alice is responsible for building new functionality into the FCU mobile app and investigating potential technologies to integrate into the experience.
I really look for ease of use. How easy is it to get up and running? If it takes more than a day, I’d just drop it.
Gabe, the Support Technician:
Gabe helps troubleshoot the problems of Jessica and any other customer at FCU.
The faster I can resolve a customer issue, the better.
We could write a novel on each of the solutions we developed for our users, but for this case study, we’ll focus on how we made high assurance authentication frictionless for Jessica, our consumer end-user.
We had an amazing 4 person design team:
- Haidy Francis, Design Lead
- Peter Vachon, Advisory Designer
- Ploy Buraparate, Design Researcher
- Patrick Chew, Visual Designer
Over the course of a 9-month span, we collaborated closely with awesome development and product management teams, in Gold Coast, Australia and Boston, Massachusetts respectively, from concept all the way to deploying apps in the Apple App Store and Google Play Store and an accompanying web experience.
We started with a six week envisioning phase, moving from blue sky ideas to a scoped set of user stories that we’d build together and then we ran 7 three-week design sprints to build out each experience.
We designed each experience using Sketch, and built prototypes using a tool called Flinto, as well as CSS and HTML, and conducted dozens of user tests with each prototype to inform the next one. Having so much testing really allowed us to gather rich feedback and to fine tune each micro-interaction. The experience in the App Store today is drastically different from the one we started with thanks to user testing, and we’re pretty damn proud of that.
One huge challenge we faced as a design team was translating our existing brand, tailored for enterprise-facing, technical tools, to a consumer mobile app. Our brand guide has a lot of thought, iteration, blood, sweat, and tears put into it. But when we started to apply it to our consumer app, it was, simply put, not working. The colors had to be refactored, icon sizes adjusted, type ramps redone, and illustration style fleshed out. We had to simplify and clarify our voice and tone, and come up with new patterns for touch.
As an example, the typical enterprise color palette we use today is very task focused. The UI is primarily white and gray, and when color appears, it’s used to indicate an issue’s severity, or how important it is to resolve that thing now. This is crucial for our technical users.
But as we started by taking pieces from our existing guide and translating them to mobile, it felt stale and uninspiring for an everyday user. To give the app life—a voice and a personality—we had to create our own mix, changing the proportions of colors and adding some highlights.
Like most teams, we faced countless challenges in our project. We had a globally distributed team, inexperience designing and developing native apps, and more. But I think the most unique problem we faced was that our solution wasn’t directly solving a user pain point.
If we weren’t making our user’s life easier, what were we doing?
At first, we had a lot of internal struggles with this. Our project didn’t fit the traditional pick the biggest pain point and solve for it strategy. Today, Jessica hardly ever thinks about authentication or security. We weren’t sure that our envisioned future workflow was any better than Jessica’s current workflow. If we weren’t making our user’s life easier, what were we doing?
Coming to terms with this meant reframing our problem. Instead of looking at the problem solely from Jessica’s perspective, we also included the perspective of her bank, who have great stake in insuring that users are who they say they are and are accessing the right information. Additionally, we realized that this solution would only be used by Jessica in specific contexts where she had vested interest in the security of her data. It wouldn’t be a catch all for authentication into every services, but only for places like her bank, healthcare provider, and other privacy-conscious services. And in these contexts, we would aim to provide a frictionless, delightful experience that provided Jessica and her service with peace of mind.
Finally, armed with a boatload of research and countless iterations, we felt we could effectively make “high assurance authentication frictionless” for Jessica. We designed a two-factor authentication app, IBM Verify, that Jessica could install on her phone to access her online accounts securely, with the tap of a button.
Importantly, using two-factor authentication moves past the password by combining multiple authentication factors. Instead of just asking Jessica for something that she knows, like her password, a PIN number, or her mother’s maiden name, she now signs in with a combination of something she has, her phone, and potentially something that she is, like her fingerprint, voice signature, or face.
Because with IBM Verify, Jessica can now log in without her password in the future. It’s easier for her, and safer for her and her bank.
The beautiful and terrible thing about digital product design is that the work never ends. This is only the beginning. Since the first release of the iOS app, we have continued to test and iterate on each of our flows, confident that while there’s much to continue to evolve, we have built a solid foundation for consumer multi-factor authentication at IBM.
Our next step is to continue to build out our solution to cover the entire product lifecycle, from Alice, our developer, to Scott, our security administrator, so that it will be just as easy to integrate and customize multi-factor authentication on the back end as it is for Jessica to use IBM Verify to sign in.