The prototype integrated the kind of video-game UI that DARPA was after. Swink said that the developers made this a priority, even using some of the same artists with whom they’d designed video games to achieve the effect Maeda envisioned.

“What she said made sense to me,” Swink said, “but, not having worked with the military before, I was stunned that they didn’t have it.”

The other main TIGR selling point Swink emphasized was giving small units the ability to access and update maps, and use them in planning patrols. Intelligence officers at brigade level and above already had the capability, but those going outside the wire did not.

“They found it really difficult to get up-to-date maps of the areas they were going to patrol,” Swink explained. “They loved that they could load in the latest maps at platoon level, print them, and walk out the door with them right before patrol.”

Swink knew this from experience, from sitting beside soldiers in Camp Victory or Camp Taji in Iraq and talking to those who went on patrol. With that input, Swink could make coding improvements to TIGR on the fly. The 1st Cavalry, 1st Brigade Combat Team, Funk, and Michaelis had made this possible, teaming with DARPA to experiment with TIGR during exercises in 2005-2006. The feedback from soldiers was immediate, Maeda remembered.

Said Maeda, “We had a construct [in the TIGR environment] including ‘Events, People, Reports.’ One of the soldiers pointed out the need for a [repository] called ‘Collection,’ saying that when about to embark on the next patrol, he wanted to look for relevant events in a single folder, i.e. Collection.”

The feedback was embraced by TIGR developers, who brought an agile development mind-set to the system. Unlike more formal Army software, TIGR didn’t have to be fully perfected before it rolled out. Eighty percent was good enough, with successive iteration in the field improving the product more effectively.