When setting goals for a product, one of the most important questions a designer can ask is “why?” Why are we choosing to solve this problem? Is this the right problem? Without a shared understanding of the goals and priorities, you may optimize towards the solutions that are easiest to measure. You may, in effect, game your own system.

The nature of the game

Years ago, my design team at the time hosted a contest during our company’s annual technology summit. Being a large, global company, these yearly summits were often the only time employees could get a glimpse of other activities and teams. The company was still having a bit of trouble merging different values after a change in leadership years before, so any opportunity to foster a spirit of collaboration was sorely needed. This design-led event would be a welcome break from the panels and presentations.

The contest was this: create a game from a box of miscellaneous parts, such as a breadboard, sensors, LEDs, plastic containers, straws, etc. I was paired with two engineers in different areas of the company. As we introduced ourselves, I asked which designers they knew so I’d know where they were coming from, and to put in a good word about those designers. After looking through our parts and discussing two or three potential games, we decided to try the most ambitious idea: a counting game that used a plastic bucket, beads, straws, and sensors.

While scavenging parts for it, I happened to learn that the measurement of success would be the amount of time the judges would spend with the game. I rejoined my team to share what I learned. After joking about ways we could game the system, we shifted back to where we were at and realized that we had yet to get the electronic parts working as intended. The engineers tinkered away, a little rusty on their electrical engineering knowledge but having fun.

Meanwhile, the physical game itself was ready so I thought through each step of the experience surrounding the game. I took the cardboard box and wrote instructions, a story, and even some instructional graphics on it. In the final 10 minutes I decorated the rest of the box and the plastic parts of the game with some flourishes so they would match each other, and wrote some bombastic copy on the box about the overall awesomeness of the game.

Time was up…and unfortunately, we were unable to get the sensors working properly. The game didn’t work. As we packed up the pieces into the box, we were disappointed that we’d run out of time, but we’d had some fun with the tinkering and had a few ideas about how to truly make it work, given more time. We turned it in together, said some friendly goodbyes, and split off to go to other sessions.

What you measure, you build

Later that afternoon, I found out that we won.

This wasn’t an “A for effort” kind of win, either. We won because we were the most successful in achieving what was measured: the length of time spent with the game. Since the game looked complete, the judges assumed that they were just having trouble setting it up. They spent the least amount of time with the games that worked, the games that were simple enough to figure out right away, play briefly, then move on. They spent much longer with our game because they were reading the box and attempting to set up the sensor correctly.

I’m not sure whether the contest yielded the results the organizers wanted, but I do know it yielded what they asked for. That got me thinking about how other goals or measurements would have different results. If engineering collaboration was a goal, simple surveys before and after could have measured their sentiment about the design team. Better yet, the designers could have been enlisted beforehand to come up with hypotheses about working with the engineers to try out and report back on what they learned. If design innovation was a goal, the rewards could incentivize that particular approach. Perhaps the winning team could play their game with someone noteworthy, or be profiled in a presentation, video, or blog post.

In the absence of a team-level goal, my goal was to leave the engineers with a favorable impression of designers as colleagues. Based on their level of collaboration during the event, I considered it a success. We had fun, we all contributed, and we successfully shared ownership over the outcome from start to finish. For me, this was the right problem to solve.