Destiny Companion v1

Role: UI Design and UX Introduction

Initially responsible for the UI design of Entrusted to full UI design vision holder of the entire companion team.
Lead: Kevin McGinnis & Garrett Morlan


My first role for the team at first was to create a visual language for the team and make sure that the UI design was "Destiny" but for mobile. This presented a number of challenges. 

  1. The Destiny UI was very clean and text based which meant a lot of care and forethought on spacing and localization needed to go into it. 
  2. The app had wildly different sections (something it still struggles with today) and that in itself presents a consistency issue. 


Consistency throughout the entire app proved to be the most difficult. The app was coming online with the bulk of its game-facing features late, much like Destiny itself. Bounties, the Grimoire, and Advisors had not actually been hooked up, but where being built into the app as if they were. 

Companion 1.0 iOS

Companion 1.0 Android


Early designs for the mobile app always had a problem with consistency, but not just from a UI perspective. The features were just different. A feed in one section was totally unique and had different goals and utility than a feed in another. This presented all sorts of challenges. 

Working with the UI artists on the game, I found a fundamental baseline for all sections in the app. Using iconography, clear typography, and contextual game terms, I was able to leverage a lot of what the game was already telling users and continue that UI and UX consistency. 


This meant a lot less 'custom' work and more clean, reusable UI. I created detailed red-line documents the ensure that each pixel was accounted for.

This was only as useful as the engineers wanted it to be, however. We were still in growing pains of how to develop and deliver a AAA game's companion app.


Certain sections of the app, however, suffered from being directly 'ripped' from the game. They were great UI and UX for a console game, but were not built for mobile. 

iOS Tower / Vendor Screens - Nearly 1 to 1 with the game in design and functionality... minus walking around of course. 

This consistency with the game, however, came at a great cost to standard UX principles of mobile and web.

UI to UX


The UX/UI of the game does not always translate to UX/UI of an app.

The game is on console, controlled by a free-cursor and controller, and the app and website are used by thumbs and mice. Almost three completely different worlds were accessing one UX through one UI... and the problems only became worse as we added features to the app.

Android Gear / Gear Scrolled / Gear Details


As the app grew, there also grew a need for me to grow into a hybrid role of UX/UI designer. Most companies balk at the idea of having a split role, but by modestly taking on small UX problems, such as interacting of a single feature and worked from "problem to polish".



Moving and equipping gear.  

First implementation steps:

  1. Navigate to Gear
  2. Select "Item Bucket Type" (Essentially the slot of the weapon that would push in a view that had the rest of the items you had of that type)
  3. Select an alternate item (push to item details).
  4. Select 'Manage' from the bottom of the screen and tap action.


Updated Experience:

  1. Select item from item list
  2. Pop up overlay that displays actions
    • View

    • Equip

    • Transfer

    • Lock

  3. Perform Action

This may seem like an obvious interaction, but hindsight is 20/20. Initially we thought gear inspection would be the determining factor in managing different items. The users would go into the item's detail to figure out if they needed that item or not. 


But after seeing how the game was being played, it was determined that the users who were doing the bulk of the item management already knew what items they wanted, or that there was more than enough information on the item listview to make a meaningful decision. Basically, we moved the actions up a level to alleviate the need to view the item's detail before performing an action. 


Destiny Companion v2 Android

Role: UX and UI Design

Responsible for the User experience design, feature design, and UI design for the Companion Tablet Update

Lead: David Sinclair


The Destiny Companion had no existing footprint on any tablet device


Proposed Solution:

Design a Native Tablet Experience

The first solution we went after was a full design for all tablets, including iOS. This involved scoping for work, looking at navigation options, and designing in feature versions to roll out as we completed them.



The features had become so intertwined that the app could not be shipped without a complete feature load. 


New Problem 2:

Android had just launched their new Material Design update, and with it a whole new set of rules and paradigms for app design. This meant that the apps had to be designed and built differently to live in their respective ecosystems and act natively. 


Navigation was the biggest issue between the two systems.



Feeling like we had a better idea of how the Android Tablet system was working, we decided to focus on creating designs for that only.


We also decided to make one install for both mobile and tablet, essentially getting an update to mobile for 'free' because we were working on tablet.

Early Exploration of the Android Tablet Menu


The project started out as a waterfall of design to development. We were operating with no real timeframe on the project. The developers needed weeks to set up new frameworks, as we were throwing out a lot of old work.


Designs were being created and reviewed, but seldom implemented correctly, if at all. Pill-up of design debt became an issue and the developers felt like they would never catch up.


It was determined a new approach was needed and all members involved were invited to three 4 hour (or more) long design scrums and we would continue this until a cohesive plan and design emerged.




Milestone 2:

What came out of those meetings, reviews and designs was a well understood scope, a clear direction, and an execution path.


We took a brand new, simpler, and more user friendly approach to all the interactions and major features of the app. 


This meant, like the iOS changes I had made, moving the most used interactions and features up and presented them in a much more simple design. Again, we pulled the "gear management" from the "details view" and made it highly accessible. 

Early WIP for the Gear section on Android Tablet

Moving key interaction and flows up to higher levels greatly increased usability. 

These new feature shifts and designs landed us a 4.3 rating in the app store (still current rating).



Overall the update took more time than it probably needed to take, but for the people involved in the revamp, it was critical we hit the walls we did. We learned how to work better, improve our process, and were able to deliver a better, improved product.

Destiny Companion v2 iPad


Role: Project UX and UI Design





The iOS app does not have a native iPad experience. 

This was the big one. We had just come off of working for months on the Android update, kept up with the content of the game (two game updates), and were splitting the team into two halfs to perform more as an agile team.


Needless to say we, the two devs and myself, were still trying to juggle the amount of work needed to keep 2 android platforms, and iOS app, and a website afloat with the same feature sets.


Using what we learned from the Android development, we jumped into design meetings and wireframed out much of the same functionality and UX for the iPad app. 


However, I spent more time prototyping and designing our new ribbon/tab navigation that has become the norm for iOS in general. This was a bigger task than anyone realized.


Features in the app do not bucket together well and have overlap. 

Sub Problem:

No one involved in the design could come to an agreement of the arrangement of the app because of different perspectives on who uses the app - hardcore/power users vs. causal.


We never did actually come to a refined agreement on how we all saw the app being used. We had at our disposal a mountain of data to support our decisions, but it really depended on interpretation of that data. Kind of like reading hieroglyphics. It's all in how you read it. 


This did gave us an insight into what the basic spring off points for the app should be. Each of these sections had a fundamental guiding principle behind it that kept us honest about what features fell under what category.


  • Legend - My game progression
  • Community - I want to play with friends
  • Destiny - What's going on in the world of Destiny
  • App Level Stuff - Settings and other app features
  • More - Everything else


Our new navigation followed those categories.



Twitch Integration with


"Make 'em famous."

One of the large epics we set out to create was to promote "celebrities" in our own community. Basically giving most support and tools for our users on to become as popular as Twitch and YouTube Destiny Streamers and Content creators. 

On of the first approaches was to create a section of the Companion for users to post and share their art, stories, and videos. We created a "Bungie Creations" section where users could do just that.

Streaming was the next logical step, but we had a mountain of problems to solve that were mostly engineering in nature. 

The features for this experiences were too many to count. We wanted everything, but we knew we had limited time and resources, like any project. We also were up against a clock with a release of the game. 

We got the priorities down to a simple few rules:

1. We cannot be just a "clone of twitch". The experience had to offer more than just what offers.

2. We needed to be able to promote a user's stream to satisfy the goal of "promoting our community celebrities".

3. We had to accurately reward users for accomplishing our incentive goal of "streaming for 77 hours". 

We collaborated with our community team and bribed game team testers to squeeze in an in game reward for streaming in the form of an emblem. This would ultimately effect our data for 'success', but at the time we wanted to rewards people and push them to the companion because we knew what we were going to be able to provide them with. Article



Site wide banner during a live broadcast.

Pop over when broadcast is live. Only on homepage

Something that popped up during our early investigation, something that is painfully obvious now, was that when Bungie was streaming on Twitch the only place that had no idea or no advertisement of that fact was We had advertised streams on every social channel excluding our home.


There is no way for a user to know if Bungie is Streaming on Twitch via Companion/


Using our content 'firehose', we deploy a content set that looks for a broadcast from the Bungie channel on twitch and a banner is the displayed on the site prompting a model to pop open for the stream.

Successful isn't even the term to use for this feature. 

This feature wildly exceeded our expectations. Users by the thousands would see the model and watch the stream before closing it. 



Profile with Twitch linking slat.

Profile view when user is streaming.


Linking the Twitch account to the Bungie profile was a simple UX problem to solve since we weren't allowing authentication of one through the other. This was just a simple handshake that pointed on account at the other, enabling users to find each other on either service. 

 Browsing Library

Browsing Library

Streaming View with Gear Viewer

Gear Modal for Details on selected item


When we set out to build a Twitch streaming environment, we set the goal to be "better than a clone of Twitch". This meant that whatever we decided to launch with it had to have something more relevant or better than Twitch itself, otherwise what was the point.

We were able to include in our browsing library a Game Mode tab and trending viewers which is a proprietary algorithm we defined to ensure that our view wasn't going to just be the popular streams but all streams rising and falling. 

This ensured we could fulfill our goal of promoting our community celebrities.  

We shipped this feature full functional and with all the intended parts. 

Post Mortem

What was most interesting is that we found that, while all the feedback was universally positive, the feature fizzled and began to see diminishing returns. Streamers and viewers a like rejoiced in being able to see the gear being used, but in the end, still chose to use as their primary viewing experience. 

This could have been for so many reason, but we suspected it was just habitual. Additionally, this could have been because of the rate at which users follow streamer from game to game. only having Destiny could have made that an added hoop for them to jump through. 

We learned a lot from this experience both from a "what do users want vs. say they want" and internally on our team.