This article shows 3 simple design techniques we use to clearly define goals early in our projects.
Bohemia Interactive Simulations (BISim) is spinoff studio of Bohemia Interactive (BI). While BI has been making games such as Arma and DayZ, for over 15 years BISim, now a separate company, has been leveraging the technology behind them to make games for real military training. Hundreds of thousands of soldiers have trained for combat using our flagship product Virtual Battlespace.
Our business model requires us to be highly efficient in our development process. Most of our development is funded through fixed price contracts. This means the customer gives us a set of requirements (“your software must do X, Y, and Z”) which we (and others) bid against. If we win, we have a fixed amount of time and money to satisfy a fixed scope.
According to the project management iron triangle, this leaves us little margin for error without having to either hack quality, blow out the budget, or resort to massive crunch times. Dropping features just isn’t an option. To succeed, we have to smoothly design, develop, and test feature after feature that consistently satisfy customers as well as internal stakeholders.
Slow is Smooth and Smooth is Fast
There’s an old military saying: “slow is smooth and smooth is fast”. You hear this when practicing things like weapon handling or casualty evacuation. The idea is that if you try rushing something when you’re under pressure—like reloading your weapon while being shot at—you’ll end up making mistakes and the whole thing will take longer than if you had moved slower and more thoughtfully in the first place.
Does this sound applicable to software development projects? It is for us. When a project starts, our temptation is to just start coding something right away! But often this rush to build something ends up costing us in the long run if we build the wrong thing to begin with. By slowing down for just a moment and getting everyone agreed on the end-goal (customers, the dev team, internal stakeholders), we can smoothly move forward on each feature, which leads to fast, efficient development.
These techniques are drawn from the fields of User Experience Design and Business Analysis. Both fields are highly professionalized and used extensively to do smooth software development—though not always as much in the games industry.
Technique #1: Storyboards
The technique: Storyboards are sets of sketches (or screenshots, mockups, etc.) showing a scene or scenario playing out over time. It originated in the film industry as a way to plan a scene before actually filming or animating it.
Games and software may be non-linear, but this technique is still relevant. In this context, think of a storyboard as showing a movie of someone using the future game, product, or feature. The movie could be “in-game” footage (showing the target gameplay), or could be showing the user in their real-life environment (showing the context and needs of a user IRL).
Best use: Storyboards are awesome for quickly getting everyone on the same page about the “big picture” goal of a feature set. They’re interesting and fast to understand compared to a written summary. Discussions are easy with them because you can literally point to a frame and say “I’m talking about this thing HERE.” This is most valuable early in a project, when goals aren’t solidified yet and you don’t have anything else concrete to discuss around.
Case study: We had a customer who was training soldiers on how to call close air support (CAS) during night operations. CAS is dangerous and expensive to train IRL and even more dangerous to do for real in combat. When called incorrectly, CAS can cause friendly or civilian casualties. Simulations are used extensively to train this task before doing it for real.
We already had a lot of gameplay features relating to CAS as well as general night operations. However, for training CAS during night operations the customer needed a number of additions and changes across seemingly unrelated features.
The customer requirements only referred to each change in isolation, not the big picture. For example, one requirement read:
The software shall allow the targeting pod model on the aircraft to have the capability to create a laser IR beam that will sparkle and designate. The term “designate” is the marking of a target with laser energy that is not visible to the naked eye of the user, must include the ability to add a Pulse Repetition Frequency (PRF) code to the designation ability. The term “sparkle” means to use an IR laser pointer to mark a target, either from ground or aerial assets.
Here’s the problem: do you think everyone on our team understood the complexities of using CAS during the day, let alone at night? Of course not! This means they lacked a shared vision of the end goal, and had difficulty understanding these detail-level requirements.
Technique in action: Jeremy, the lead designer on the project, was a milsim nerd (like most of our designers). Furthermore, his father was a former Forward Air Controller who called in CAS during the 1983 U.S. invasion of Grenada. Jeremy had a solid understanding of both the customer’s end goal and the related features of our product around CAS.
Jeremy put together a briefing for the project team explaining what CAS is, and the different people, processes and equipment involved. Storyboards were put together using modified in-game screenshots to show the purpose of the requested features.
End result: Having a shared vision allowed everyone on the team to see how their work fit in with the end goal. For example, bugs could easily be triaged by QA as either critical or not. Programmers could see which parts of the rendering code was most important. The team could organize playtests around the target usage scenario, and could identify and fix product issues that would have become a problem for the end user when they used the feature.
Technique #2: Flow Diagrams
The technique: User flow diagrams are commonly used in UX design to show a user’s path through a UI (e.g., from a login form to a checkout screen). Data flow diagrams are used in business analysis to show data flowing between systems (e.g., between an accounting system and a customer database). Both are basically forms of flow charts, where each node can be broken out into more detail at a later time or place.
Best use: Fast, early designs visualizing how different how the pieces relate together. Allows you to play around with different flows and connections, without having to design each piece in detail.
Case study: One time, a certain large customer wanted us to make the mortars in our game “more realistic”—but they couldn’t easily specify what they meant by that, or why they wanted it.
#/media/File:Soldiers_firing_a_M120_120mm_mortar_(Iraq).jpg){kind=link}
There are lots of people, processes, and equipment involved with mortars. For example, multiple soldiers aim and operate the weapon itself. A spotter observes the target and radios where to shoot. A fire direction center listens to the radio, does calculations, and passes target info to the weapon crews.
We had some of this simulated—but not all of it, and not in great detail. Which parts should we change? With limited resources, we couldn’t do everything. Discussions internally and with the customer were going around in circles, as not everyone had the same level of knowledge of the real-world processes and equipment or the current in-game feature set. We needed something concrete to talk around.
Technique in action: Gary, the designer on the feature, was a milsim nerd who was familiar with the basics of mortars. After some more detailed research, Gary put together a simple flow diagram (below) showing how the people, processes, and equipment involved interact IRL. Gary marked the areas that were already covered by in-game features, and then highlighted the areas where he proposed we add or modify features.
End result: This diagram made a complex process simple for the team and stakeholders to understand and discuss around. After some quick revisions, everyone agreed on the general features and flows that would be made more “realistic.” Later, as each feature was designed in more detail, they were linked back to the overall big-picture flow diagram to show how they fit together.
Technique #3: Use Cases
The technique: Use cases are deceptively simple, yet incredibly powerful. Basically they are a written set of steps describing what a user will do when they perform some task with the product. Here’s a simple use case describing the “Super Star” power-up in Mario Bros for NES:
- The player hits a block containing a star
- The star bounces to the right across the screen
- If the player touches the star, he turns into Super Mario
- The player’s sprite changes to Super Mario
- The game music changes to the Super Mario theme
- While Super Mario, the player has new powers
- The player is invincible to enemy attacks
- If the player touches an enemy (from any direction), the enemy is destroyed
- After 60 seconds, the effect ends
- The game music returns to the regular music of that level
- The player returns to the normal Mario state (see “normal Mario” use case)
Usually a bit of extra information is added describing who would perform the use case, when it would be started, and what happens once it is completed. Use cases can first be written as high-level steps, later breaking them into more detail when needed.
Note: Use cases are not the same as user stories, which are a technique for describing a development task to a team. Often, multiple user stories would be required in order to completely develop a single use case.
Best use: Writing down what’s in your head, and then realizing you haven’t thought it through entirely yet. Use cases are fast to write, yet the structured format forces you to think through things you (or your team) may have “handwaved” over without realizing it.
Think of use cases as a “scouting technique” that lets you quickly “look ahead” of the rest of the design and development on some feature. They can uncover potential problems in advance, letting you solve or avoid them before they surprise you. We’ve found them so useful, we now write them at the concept phase for every project we consider doing.
We often refine and update the use cases during production, especially for complex features. Since they describe the intended behavior of the system (and, implicitly, what needs to be built), they can also be used as a foundation for all sorts of things later such as UI mockups, user stories, technical architecture, test plans, documentation, and more.
Case study: In 2017, the Swedish Armed Forces contracted us to build a highly complex and detailed CV9040 gunnery simulator. The intent was to train the vehicle gunner and commander how to do specific gunnery procedures using the exact dials, switches, etc., as found in the real vehicle. The system needed to replicate 50+ crew procedures, as well as 20+ behaviors of the vehicle’s Firing Control System (which controls the main cannon).
A large part of the project’s complexity was simply understanding how the vehicle was supposed to work. The development team didn’t have anything aside from operator’s manuals and the customer’s military subject matter expert (SME) for reference. The procedures would range in size from 5-20 steps each and were all interconnected in some way. The scope of the project was huge, and there wasn’t much time to rework any mistakes.
Technique in action #1: I was the team lead, and I’m a milsim nerd, but I had no idea how this vehicle was operated. I asked the team research each procedure in the operator’s manual and write them out as use cases. We would review these line-by-line with the customer’s SME to validate them as correct. Sometimes, the SME would have to physically get into the real vehicle (on his military base) and try out the procedure to confirm some details. Once written in this way, we had the details we needed to start implementing the features from scratch.
Technique in action #2: Another challenge was implementing the vehicle’s fire control system (FCS), which the crew uses to control the weapon, turret, sights and ammunition. The vehicle had a number of possible firing modes and behaviors (eg ground target, air target, silent observation, manual backup procedures, etc). There were also a number of system errors we had to implement if the vehicle had suffered certain damage.
Our game already had a partial set of technologies related to this. So not only did we need to identify how it should work IRL, we also had to clearly identify how we could use what we already have in the simulation—without building everything from scratch.
Konrad, the senior designer on the project, was a milsim nerd who also had worked on armored vehicle simulators in his previous job. He was the one person on the team who had a good understanding of how different FCS worked, but he had a hard time explaining what needed to be changed to the rest of us. Once again, use cases proved to be the best structure for coming up with a development plan we could all cooperate on.
As before, we had him write out use cases and validate them with the customer SME. For implementation, however, we had him color each step in the use case according to whether the step was currently possible to perform in-game with our existing FCS, like this:
- Green = Possible
- Yellow = Partially but there are some bugs / limitations
- Red = No
We then made user stories (development tasks) out of each yellow or red step, which the whole team worked together on implementing.
End result: The dev team didn’t start implementing a given use case until it was fully understood and validated as correct. We made sure there was always a full backlog of finished use cases and supporting technology ready to implement, so development was never blocked by the design process.
This prevented time being wasted on writing code only to later find out it wasn’t what was originally needed. The use cases were also directly used as testing guidelines, making for a faster handoff to QA.
Organizing our work in this way gave us clear, measurable goals and a smooth flow of quality work. No crunch time was required to close out the project, despite the large, ambitious scope.
Final Thoughts
These are just a few of the techniques that are most useful to us. They help get everyone on the same page, speed up development, and improve the quality of design. When combined with other best-practices and techniques such as an Agile production approach, they become even more powerful.
Feel free to reach out to me with your thoughts and feedback on this topic. 🙂 info@andrewbarron.net