Intro
I’m a Design Director at Brava, Inc. I design creatively-efficient and immersively-engaging products.
Read more >>
Read more >>
Research, user interviews, user stories, journey-mapping, and low-fidelity mockups.
Wireframes, graphic design, and style guides.
Animated, interactive, and high-fidelity prototypes.
Development and implementation of user interfaces.
I researched and designed a brand-new user interface to accommodate changes in the product business model. Key metrics such as content discoverability, quality ratings, and the product’s net promoter score were all improved due to this effort.
Meal kits, a vital component of Brava’s original product offerings, were considered too expensive by most users, despite rating their experience favorably. Because of the way Brava cooks with varying temperatures and multiple zones, this presented numerous challenges to the setup process. For one, the meal kits included fully prepared and measured ingredients, full-color instructions with photos, and bespoke “programs” which cook the food automatically. The Brava included recipe types other than meal kits that were not as fully developed near the product launch. Some recipe instructions were on the website, some were on the app, and others were only on the Brava’s screen. As a result, we received numerous calls about burnt or underdone food, primarily from users unaware they were doing anything wrong. Navigating these multiple, inoperable formats added to customer confusion; however, it provided a unique perspective into what media resonated with users in the short term.
Food cooks much differently in the Brava compared to other appliances. After release, I researched the most commonly cooked foods and common preparation issues. If food is too large, it might be too close to the heating elements, which could cause burning. We iterated on several methods to instruct users on the “maximum height” of foods. If food is improperly placed on the tray, it could cook improperly, so the culinary team added photos of the final tray arrangements to the recipe instructions.
Behind the scenes, I consolidated our database structure around a single format. I aimed to reduce the number of variables and provide a consistent, understandable foundation for scalability. The revised database allowed us to leverage features on all platforms, then hide or show only applicable information in context.
-Product Review
These changes made an immediate, noticeable impact on early product reception; the product’s net promoter score improved, and we saw more positive press on the news and social media.
As users became more familiar with the product, I found several helpful anecdotes from the community and Brava’s culinary team. In short, users wanted a way to sequence or pre-program commonly used functions on the device, like a macro; they wanted more personalization options. Using this information, I designed a minimum viable product called Custom Cooks that could fulfill several use cases while touching the fewest components.
The project scope was limited to on-device interaction only. The touchscreen was not an ideal method for typing instructions, or any form of text input, meaning the initial release was only accessible to the most patient of users. On the plus side, these constraints meant we focused only on the most essential features: creating, modifying, and sequencing recipe programs to share with other users via a nine-character key.
I utilized as much of the existing design system as possible for this feature, maintaining the lower tab structure for setup purposes. We extrapolated the core functions of the Brava into modular components, then sequenced them in a JSON script. With this feature, users can customize any preset of the Brava to their liking and add instructions. The Brava will run this program in order, stopping if the user needs to stir or flip foods.
We have improved the system to add many new features, such as app and web support. Over 20,000 such recipes have been created, shared, and cooked by our users since launch. A small percentage of highly-motivated users help guide new customers along the way. Sharing user-made content is vital to the feature's success because it allows users to see how the programs work, almost like viewing source code.
The Brava’s built-in software included around forty recipes called Combinations. These were simple procedures for cooking a protein and one or two vegetables simultaneously. The community showed considerable interest in receiving more of these combinations, specifically they wanted a wider assortment of ingredients. At the time, each recipe was entered individually and essentially from scratch, even if it shared content, like instructions, with other recipes. I had encountered similar quandaries in game development, and proposed a system where ingredients were treated like variables and “compiled” before release.
The hierarchy of the existing database proved challenging to build upon. Features initially suited to serve turnkey solutions, like the meal kits, needed rethinking. I was also working on a live product, which meant additional considerations for legacy content and deprecated features. Like with Custom Cooks, I aimed to reuse our existing design paradigms as much as possible.
Collaborating with culinary, QA, and engineering teams, I created a theoretical model of how this new format could work. I then iterated on wireframes, mockups, and prototypes using actual data from the product CMS.
The initial release added more than 7,000 new recipe programs. This feature also led to additional updates simplifying the core recipe format while leveraging procedurally- and user-generated content.
At Disney, Kiwi, and Jam City, I helped establish more efficient development pipelines through documentation, in-house tools, and automation. These efforts allowed us to dramatically scale our number of concurrent games, allowing live games to run with only a few developers.
Early smartphones came in various screen sizes, making broad distribution difficult. In particular, at Kiwi, we often had small teams working to resize assets and animations to fit a range of devices. Further complicating matters were development pipelines–when can designers and artists successfully hand off their work to engineers? Assets required extensive technical prep work to ensure compatibility with the code. Artists would spend hours painstakingly detailing animation properties without guarantees their expectations would translate into the game engine. Human error was also prevalent, given the time investment involved.
I researched every requisite task in the development paths for game sprites, effects animations, and UI layout. I started with the quickest fixes yielding the most significant impact. I learned about Photoshop tools development and scripted a few different automation utilities. Next, I researched our engine’s UI system and determined how we could be more efficient there, too, as designers followed the same treacherous handoff with engineers for their work. I reverse-engineered the games’ UI format and then scripted a utility that converted Photoshop files into this format. The utility evaluated layers individually and extrapolated properties to XML during export.
Artists no longer spent hours manually scaling and renaming files to game- and platform-specific specifications. Engineers now had a consistent and reliable pool of instantly repurposable game assets. The company could launch more, higher-quality games faster. More importantly, our development team, as a whole, could focus on higher-priority tasks.
While at Kiwi, I worked on a pitch project with six other developers. The plan was to make an online-focused strategy game for mobile in Unity. I worked extensively on front-end coding for this project, mainly for the controls, HUD, and UI effects.
The game had a hastened development cycle of only a few months. For many of us on the team, this was our first time using Unity professionally. Being a mobile game, Ballistics was very UI-dependent, which Unity struggled with in earlier versions. Fortunately, we built from the 4.6 version of the engine, which included a beta version of the current Unity UI tools.
We assembled a working multiplayer prototype in less than a month, which then allowed us to hold nightly playtest sessions with the rest of the company. We would interview participants at the end of each session to get feedback on gameplay, controls, visuals, level design, etc. The following morning, the team would discuss the playtest feedback and how to incorporate some of the most common remarks. This process continued day after day for a few weeks, eventually culminating in a public release on Android. We continued playtesting sessions and used the game's built-in chat to interview players directly!
Because we were primarily working with scratch assets, we could make many pivotal game balance and interface changes before devoting too much time to visuals. An initial focus on gameplay also allowed the artists to spend more time in the concept phase of their work.
This project was a great introduction to Unity and led to our eventual acquisition by a larger studio. It was also a quality exercise in building a game from start to finish in a few months.
Before starting this project, I had observed that fellow instructors inevitably hit a point of writer’s block when preparing their routines. I sought to build a simple app to assist with routine creation.
Unfortunately, the official site, while filled with information, is a mess. It is also not friendly on mobile browsers because it is using dated markup. Other instructors I had spoken with indicated that whatever methods they used to create and organize their routines were also a mess. Word documents scattered around their desktop and various folders, numerous Google docs with confusing names, etc.
Other fitness programs, such as Schwinn Indoor Cycling, have had handy teacher resources, and I wondered how Lagree could benefit from something similar.
The prototypes gave users something tangible, which led to vital feedback I applied to future revisions of this app.
"Welcome to the longest-running deathmatch in the known universe. Fighters from every corner of every dimension engage one another in combat on these accursed battlegrounds. Mörkal Komborg takes place in the Mörkvärld, a floating castle-island surrounded by the shards of countless realms that it has absorbed."
