Sarah Kaiser
© Sarah Kaiser

Warhammer 40,000

The App

— PROJECT NAME

Warhammer 40,000 : The App


— ROLE

Product Design

User Research

UX Designer

Co – UI Designer


— DATE

Jul.2019 – Ongoing


The ultimate resource for Warhammer : 40,000 fans, a tabletop game by Games Workshop. The brief was to create an all-singing, all-dancing resource for army building, unit look-up, and more.


A tall order for a game published across more than 50 PDFs, with over 36 factions, 1,300 units, and 40+ years of context.


We were a team of 1 designer and 3 devs who would eventually become a team of 8 by time of launch, and we had roughly a year to do it. I was the product designer and took over many of the responsibilities of product owner during its development. This study will focus on my own contributions, but it’s key to consider that this incredible product was shaped by many talented, guiding hands.

Meet the Stakeholders

In every product there is a careful balance of needs between business owners and customers, and understanding both is key to success. However, in our case we had a few extra in the crowd.


Click a group below to find out more.

In addition to internal goals, our Business Stakeholders were looking to support key marketing and community growth KPIs. Besides providing a great experience, they were eager to make sure fans could reliably access new content based on ownership roles and share it with their friends and our wider ecosystem of products.

Our studio of Game Designers/Developers are the best in their field, and spend each waking day thinking up new and innovative rules to delight and challenge hobbyists. They have one eye to the past and another on the future when it comes to the ruleset, acting as our shepard as we worked to understand how to frame our product and what was to come.

Every product has different types of customers, but few contain demographics so starkly contrasted and unique as Warhammer fans. Gregarious, creative, and fiercely passionate, Warhammer fans new and old are interested in different aspects of the hobby, different approaches to how they build, play, paint, and collect. Due to NDAs, interviewing them required careful precautions.

User Research


I was starting from a place of first-hand knowledge, having been a hobbyist myself for nearly 10 years – but that also meant I was arriving at the problem with my own biases. In response, I ran qualitative tests nearly once a month in the first year, checking everything from how people started building their armies, to how they browsed lists of models, to validation tools + workflows they were already used to using.

Additionally, we conducted user research pre-kickoff on key personas that we were targeting, later pulling individuals from across our user base to take surveys and run through prototypes.


We used these to drive features and prioritise them in our initial feature maps, weighting them alongside business priorities.

Design Kickoff


At the time of our design kickoff I still lived in Boston, so I flew out for the occation.

Our department didn't do these kind of kickoffs at the time, beforehand developers and writers didn't often get to give feedback on designs or see them before they were completed. I wanted to change that.


Drafting up a speculative set of wireframes and exploratory designs, I invited the the stakeholders, developers, designers, and writers in and ran a classic design kickoff, complete with sketching exercises, design galleries, and markers with which to mark up the printed designs.


I wanted to try and welcome them to a collaborative space where they would all feel involved and invested from the start. That meant inviting them all to reinvent what they were looking at, present their own ideas, and draw over existing ones. It let them all hear from the stakeholders themselves so they could understand why things were prioritised just so. It also let our stakeholders get involved, and made them feel more informed about the process and the work going into it.

What’s a ‘Brood Brother?’


Woof, I’m glad you asked.


Warhammer comes chocked with 40+ years of lore. While what’s in a name might just be a variable at the end of the day, these complex proprietary terms inform underlying data structures in a way that requires comprehension of vast categories of data and their relationships. But if you don’t know the lore, it’s not always so straight-forward.


Turns out when have to carry 36 factions across ~12 different updates, many of which have legacy or inter-version dependancies, things get… complex. The answer to a lot of ‘is x a y?’ is often ‘sorta’ or ‘is it Tuesday?’ But for these structures to live in code, the legacy of unspoken rules and context-specific resolutions – ones war gamers are comfortable navigating and defining relative to their specific clubs or friendships – had to be solidified in a way they never were before.


To aid in this process I created dozens of diagrams, posters, write-ups and spreadsheets,

breaking down lingo and lore into phylum and diagram.

We invented vocabulary as we went along to solidify structures that hobbyists and game designers understood by natural language + context. Where they could get by on context, we needed concrete hierarchy and relationship.

Test, Design, Test


Figma was our secret weapon as we moved from paper prototype into the design and workflow stage. Dozens of different Figma prototypes exist for this particular project, delving into items as specific as adding items to models, to building an entire army end to end, to more strategic flows outlining different user roles.

When Adding Units, Easy is Essential


This was one of the areas of growth that could have never happened without extensive user testing.


Users would want to add more models without the page closing, or if they could add whatever they liked – would lose track of what they had. A simple list (like seen in the section above) just wasn’t cutting it. Even a toast notification to inform a user a model had been added wasn’t helping as they would quickly forget.


In any other scenario, a solution like seen right here would be the easy solve. Numeric indicators with incremental buttons up and down – but, when models are customisable, how do you know you’re removing the right one? This in addition to some tricky validation questions meant we lost the negative incrementor – and added the detachment indicator above. This meant users knew how many they were adding and were gently informed when they added too many – and could return to the main screen to make an informed choice about which (possibly customised) models to remove.


Moving the mountain piece by piece


Adding Units wasn’t the only feature of our app that required special care. Warhammer 40,000 is filled with unique and exciting features that require innovative approaches, but with a small team we had to choose our battles carefully. We opted to let Google Material guide us and then innovate where situation required to help us maintain a high velocity without getting bogged down in the details.

Going to War with the

Troops We Had


The whole mental structure of how an army is created differs from user to user.


In testing, we broke down the two main methods into 'centerpiecers' who build an army around a few key units, and 'architects' who come to the table with a whole structure in mind.


To help facilitate that, we made use of Google's tabbing view structure to provide 'architects' with the means to build out groups of units quickly, and 'centerpiecers' the means to pick their favorite units right away and worry about the details later.

Old Faces, New Places


In Warhammer 40,000, units are defined in ‘datasheets’ which tell you all you need to know about a group of models. These are printed pages in a codex, and have been viewed in landscape since the early days.


To work on mid and low-range phones, datasheets would need to be vertical, and could now benefit from the digital capacity to pull together relevant, previously abbreviated information without tripling the size of a printed book. An opportunity and challenge both.


This required several rounds of redesign as well as additional UI elements to cover new functionality as we encountered new types and sets of data. This functionality grows even today, and will continue to evolve with each new release.

Divide and Conquer


Perhaps the longest week of my career is outlined below.

Describing it is complicated, so please forgive an overused analogy.

Imagine you're letting users customise and buy a car online.

To do that you need to know what features can be configured on that car. The wheels can be so big or the paint can be just so. This is all described in the car's book. Easy. You design that UI. It looks great.


But wait – you also need to sell someone a bicycle, and it's being served through the same system. Oh, well, according to the bicycle book, the wheels can also be defined in similar selectors and you need to choose a colour too – just like the cars. But wait, handlebars need selectors as well. Makes sense. You've got a good idea of how that can look.


Now imagine there's nearly 40 different vehicles that all have to be customised, saved, loaded, and sold through this UI. Unicycles, penny-farthings, monster trucks, airplanes, submarines, you name it. There's so many, in fact, that there is no one topic expert that can name off all their options with more than 99% certainty.


Now imagine this isn't a car, and is actually just single selector (Chapter Customisation Rules) for a sub-sub faction (Space Marines) that doesn't even always require configuration. You need to build it as cheaply and as quickly as possible.


What else is there to do but pull it all apart.


And then it was sealed in lead and buried under a lake.


But at least the users liked it!

Tools for Stakeholders


Long, complicated projects need clear, visible communication on what's in the pipeline so that stakeholders will understand the impact their decisions will have on the product and team. To support that, numerous posters, prototypes and diagrams were drafted to give them something more robust than Trello when it came to key decision making.

A cross-section of the product by feature and scope, with color indicating stage of completion. A heatmap of sorts to see just how done sections of the application were.

The biggest Figma Prototype I’ve ever created. I would not recommend this to the faint of heart, or slow of computer.

Continuing Support


With such a large and unique product, edge cases pop up on the daily. This requires ongoing comprehensive support in the form of diagrams, userstory specific design additions and design definitions.

‘Datasheets’ – the written instructions of how a unit acts and can be configured – come in the thousands, and change with each update. These definitions don’t always conform to our hopes and dreams for how selectors work. But where there is disorder, there are Sankey diagrams.

As the finish line drew near, we brought on a vendor to help us increase velocity. But with new faces that hadn’t been there at the initial whiteboarding it became more important than ever to establish ‘simple’ designs into a set of standards.

Lessons Learned + Next Steps


I don’t think I’ll ever work on another product quite like Warhammer 40,000 : The App, but I do know that since then no challenge has seemed too great. Mountains can be moved if you break them down piece by piece. I also know that I’ve never felt closer to a team or more proud of what we’ve done together.


Despite vast scope and complexity, this app was exciting and relatively clear from start to finish for me, and I chalk that down to rapid, constant testing, a talented team, and a passionate company devoted to making the best miniatures game out there.