Artificial intelligence plays an increasingly big role in our lives, and whether we realize it or not, we interact with it everyday. Some of these touch-points are fairly innocuous — we talk with chatbots online, stream from personalized media playlists, and click “buy” after receiving tailor-made shopping recommendations. However, other AI influences can have a dramatic impact on us — negating our ability to get a bank loan, affecting our likelihood of being hired, or even impacting the kind of healthcare we receive. Given AI’s power to influence both positively and negatively, it’s critical that organizations understand exactly how their machine learning models work.
Unfortunately, complex machine learning models are black boxes — no one really understands what’s going on inside. My team tackled this core problem.
As the AR/VR Design Lead, I led a cross-functional group of designers, developers, and data scientists as we created a virtual reality experience that lets users dive into an AI model and start making sense of it. My responsibilities included:
As a small team, we were forced to wear many hats, so in addition to my responsibilities above, I also planned and conducted user research, ideated and sketched concepts, prototyped, conducted user testing, and did anything else that needed doing.
We identified data scientists as our target user, since they are the ones that typically build machine learning models for their organizations. We conducted user research with dozens of data scientists to better understand their core needs and workflow.
A key learning from user research was that machine learning models fall into two categories, each with trade-offs. Models can be easy to understand but not very accurate, or they can be hard to understand but much more accurate. Ideally, data scientists wouldn’t need to make this compromise.
In addition to identifying the need to make sense of mysterious AI models, we learned that data scientists wanted to:
Based on our domain and user research, we built the following VR demo that shows the internal workings of a machine learning model for making loan decisions.
If you’re interested in learning more about what you see above, please take a look at my Medium blog post where I do a deeper dive into the AI interpretation mechanisms we used as well as what makes this product so valuable.
Rather than rehashing what I wrote in that blog post here, I’ll instead address some of the challenges we faced and the decisions I made when leading this product journey.
This project built upon our previous work building data visualizations in augmented reality (learn more about that in this case study). Over time, there were several reasons I felt AR was not the optimal platform for this work. First and foremost, we were not taking advantage of the world view (AR is ideal for overlaying content on real-world objects). Secondly, if the user was in a cluttered or busy environment, the added distraction made it hard to focus on the data visualization. Thirdly, we struggled to design color palettes and render colors in a way that they would be accessible to those who are color blind. Accurate color depiction is an integral part of our product because color is a way of encoding meaning in a data visualization. When designing for the web, it’s possible to design for color accessibility by creating color palettes that have a good background contrast ratio. Unfortunately with AR, there is no background! This means colors are overlaid on the user’s environment (e.g. home or office) and affected by the user’s lighting situation, leading to unpredictable outcomes. To make matters worse, color in AR often renders differently on different mobile devices (not to mention different platforms like holographic headsets).
When I took ownership of this product, I made the decision to shift our focus from AR to VR. The Oculus Quest had recently become available, and as an untethered device with a low price tag and great graphics quality, it was an excellent option for exploration. While this choice resulted in extra work beyond the core data visualization aspects (e.g. needing to design environments and map hand controllers), the control it afforded us over the holistic user experience outweighed the added work. In addition, our long term goal was to become a hardware-agnostic product, so this decision moved us a step closer to that objective.
Designing for virtual reality meant designing without the benefit of established design languages, systems, or patterns. Although there are some guidelines in existence, most VR products on the market are entertainment-based (e.g. games) and we found that existing design patterns didn’t cover our use cases and needs.
Without clear patterns to adopt, it was up to us to figure out new ways of doing things. We borrowed principles and processes from game development in order to improve our design and development workflow. I also looked for ways to prototype faster. Prototyping in the medium is great in theory, but designers can’t always jump into the code. We designed with paper, storyboards, sketch/illustrator, various 3D modeling tools — anything that would get the job done quickly. Sometimes we would “Wizard of Oz” the experience in order to develop rapid proofs of concept and solicit feedback from stakeholders and users. In short, there was a lot of trial and error — we had to simply make and test things to see if they would work.
I created simple 3D models (like the one above) and launched them in AR to provide a sense of dimensionality. This relationship graph doesn’t have any functionality, but I find that “Wizard of Oz-ing” the experience is a good way to quickly show a concept in the medium and get feedback.
Our original augmented reality product focused on bringing 3D data visualizations to data scientists. While the product was well-received, we wanted to push it further in order to compel data scientists to use it. This target user group already has many data science tools at their disposal, and we were aware that picking up an AR/VR tool requires learning a new technology (not to mention potentially purchasing a new piece of hardware). The software’s usefulness needed to outweigh the costs in order to reduce friction to adoption.
Rather than focus on pure data visualization, I decided to shift our product’s functionality to center around machine learning model interpretation. We identified a core problem in data science (the difficulty in cracking open the AI black box) and found a way to offer data scientists a solution that isn’t easily achieved with their existing 2D tools.
Working on this new core functionality meant that the design team needed to quickly ramp up on AI and understand things like how machine learning models are built, trained, and interpreted. This is a highly complex domain that the designers had no prior exposure to.
I joined forces with members of our emerging tech department in order to bring internal data scientists and those with analytical experience into the fold. By working closely with this department (which develops many AI solutions), we were able to leverage their strengths. This cross-functional team approach meant designers had easy access to SMEs to fill knowledge gaps, we could be more certain of the accuracy of our product solutions, and we had an inside track for integrating our VR tool with their desktop software.
Sizing work for web or mobile design often involves things like T-shirt sizes or story points. Sizing for mixed reality projects often involves headaches. Almost always, tasks take longer than first thought, and occasionally they prove completely impossible (there are a lot of technical constraints in this space and sometimes you have to wait for updates to the hardware or software used for development).
This project did not have a dedicated product manager, so I took on the role in addition to my design responsibilities. Knowing that things would move slowly, I carefully prioritized feature development and took a phased approach towards our long term objectives. We would often work on a few different tasks/goals in parallel — the advantage of this approach was that you could take a break when you “hit a wall” on something and still make progress in another area. We used GitHub/Zenhub to track issues and designers picked tasks to suit their strengths, while continuing to grow and develop others.
This virtual reality experience generated a lot of excitement both internally within IBM, as well as externally. IBM’s Chief Product Officer chose to highlight our product during the AI Summit in San Francisco.
I also demonstrated the product during a keynote at the Miami Data & AI Forum. Our clients and business partners were extremely eager to learn more and get involved as sponsor users.
In addition, our team won an internal IBM award for our work on this project.
While the work shown in the demo above was well-received, there was plenty more to do. My product improvement task list included things like:
While we made headway on a number of these issues, for reasons beyond our control, we had to drop this project before we could implement all of our intended changes. You can take a peek at some of the iterations below.
A major takeaway after working on this project was how tightly design and development are intertwined when it comes to creating a mixed reality product. In an ideal world, designers and developers would always work closely together, but in practice, that doesn’t necessarily happen. However, with mixed reality it’s imperative that designers don't work in a silo. By working as a cross-functional team where developers and designers come together in every meeting, we were able to draw upon the strengths of each individual to ideate and implement in more novel ways. The developers’ understanding of technical constraints as well as their knowledge of emerging hardware & software capabilities is crucial to the generation of enhanced designs and experiences.
Mixed reality also faces additional challenges related to stakeholder and customer buy-in. A lot of people don’t see the value in augmented and virtual reality, especially as they pertain to enterprise solutions. This can lead to a lot of challenges operationalizing the mixed reality product. As a result, I learned a lot about the art of selling a concept. By evaluating and understanding market trends, business goals, user pain points, and client needs, I was able to better educate and persuade others on the value of our mixed reality solutions.
