Feature Creation

ABOUT - Storm Runners was a mobile, ARPG (action role-play) Rogue-like game that was released in New Zealand, Singapore, Philippines and Australia. After building the core game, Lead Designers created different options to make strategy more meaningful and finalized on a new feature called the "Chapter Map". In our development process, once a designer or PM decided on a problem or a solution, it is pitched to directors. If it passes, it will then go to UX for building the flows, wires, prototype, testing and requirements document. This was the first large feature that implemented the full process changes I advocated for.

MY CONTRIBUTION - My main goal at Amazon was to grow UX maturity within game development. This example highlights testing individual features early on, creating a requirements doc format to help us scale from pre-production to production and creating a "ready for development" feature. I tested the game designers' prototype with internal players to catch usability issues and iterated on the design based off that feedback. I conducted the full process of testing, building screen flows of the holistic experience, prototyped mid-fi wireframes and wrote out a requirements doc (UXDD). I demonstrated the importance of intentionally working collaboratively by getting Figma approved for my team's use and workshopping like we had prior to remote work.

DESIGN CHALLENGES - We needed to build a large, highly visible feature that had multiple stake holders with competing goals in a short period of time. A lack of consistency when creating requirements docs lead to extra work either having a Senior review to level of almost designing or due to unseen work that would bloat time estimates across the board. I was the only one writing requirements at the time and quickly became a bottleneck. Working remotely made it difficult to have effective communication with multiple people, brainstorm and have creative collisions.

Amazon Games - Storm Runners

3 months

10 stakeholders

Research Design, Testing, User Experience Design, Product Management, Prototyping


  • The Creative Director and Franchise Lead had just finalized a process update where I advocated adding UX methods, artifacts and traditional design process into the game development's process. This included items like testing earlier, journeying, clickable prototypes and consistent documentation. We were loosely doing this prior, but our team had doubled in just a few months so we needed to have a more official process for scale.

  • I advocated for KPIs being added to the initial design pitch so that it was easier to compare ideas more objectively.


  • This was a larger feature that needed to be tested with actual gameplay to get the full feeling, so game designers built a prototype in engine to test with the team first to see how the core loop worked.
  • I collaborated with game designers on my team to show them how to build out player journeys and got them into the design pitch process before final approval could be made. The designers working on this created a journey and rough wireframes to help them capture the end to end experience in their prototype.
  • Once design was happy with the core loop experience they had, I designed and moderated a usability test for 6 internal employees that worked outside of the games org. I used Tomer Sharon's Rainbow Spreadsheet to be able to find broad issues and test specific actions. I already knew that this feature would be too large to build in the time allotted and we would need a MVP version. Having this information would help me prioritize which interactions and flows were the most important to advocate for.
Using the Rainbow Spreadsheet for usability testing and behavior observations


  • Once we knew the core loop and the important things we needed out of it, we started building the UXDD (UX Design Doc/requirements). I created and iterated on this UXDD format multiple times taking the team's feedback into consideration. Having introduced this to multiple teams I've been on, the only thing that makes it valuable is if others would read and write it, so it's always slightly tailored to the team style and where the project is at. The info needed can also change depending on project life cycle, so this is an example for one that would work well for a mid-size team when they are working on features that need to be more polished or if you have multiple people creating the UX.
  • Making sure everyone is on the same page from the beginning is very important. I check that the Player and Product Goals are still the same and build upon them if the team thinks we need to adjust.
  • I hold a Journey building session with the Game Designer and PM based off what we have so far and we dive deeper. I want to look at how a Player experiences this feature at different points to capture different motivations and use cases. In this example we looked at the "First Time User Experience" (FTUE) and why it's meaningful after they have have been playing for 7 days (D7 Player). Once the flows feel good, we reach out to UI and engineering to add their questions and get their feedback.
  • I build screen flows with feedback from engineering, design and PM to capture use cases and build a mid-fi prototype.
Exploring different ways the Player will interact with the game
Screen flow that will expose use cases
  • Now we have a detailed plan for what we need and I will build the prototype in Axure to make sure things flow how we think they are going to. We want to make sure that taps feels comfortable and information is clear. In addition to a click through prototype, I also create a walk through video to show the expected path(s) since click throughs can become confusing if only half the UI is functional. This is also a quick way to go through during meetings.

  • As I am building the click through, I am filling out the UXDD details that we want to capture. Once the prototype is approved, I will then keep adding details to the document so that we can prepare for a sign off meeting where PO's and ultimate stakeholders will approve the final design and we'll start creating the tasks list for all the departments. This should be an easy to digest instruction manual that will make the scope of the project accurate from the beginning so everyone knows what they are getting into. Even though there is more design work up front, it streamlines the process and will save engineering time, found work that blows out scope or broken design.
Sample of what a part of a UXDD requirement might look like


  • The team was able to build an extra large feature in about 4 months with all departments collaborating and having transparency throughout the process. Testing the game team's prototype of finding the right flow and achieving the Players' goals gave us quick feedback and let us iterate before investing in deeper design thinking. The team believed that this feature was one of the smoothest and predictable on the project. Having an honest look at the work needed, gave us a clear understanding of what a MVL (most lovable product) would be and better fit polish time into sprints.
  • Having a UXDD format allowed more UX and Game Designers to write reliable requirements for development. Having consistency increased confidence that use cases were being addressed and features were being evaluated more holistically and consistently.