Design and Businesslearning to speak both languages

Design teams get outmanoeuvred in product decisions when they cannot translate their reasoning into the language the decision-making system uses. Business decisions happen in the language of metrics: retention, conversion, activation, lifetime value, cost of acquisition. A designer who cannot move fluently between the design vocabulary and the business vocabulary is always one step removed from the decision, so the design call gets reversed or made by someone else.

It can also go the other way. My team rebuilt a loyalty app in 2020 for one of the country’s largest convenience-store chains. We had done everything properly: field study, user research, concept testing, prototyping, usability testing. The findings held, and the room agreed with them, until one of the most senior people on the business side asked us to prioritise a single feature above everything else. Redeem by QR: a customer shows their membership code at the till, the cashier scans it, and the point-of-sale deducts the purchase from their points balance. If any one feature defined the app, he told us, it was that one.

We nodded and said we would come back with a proposal, because I already knew from the engineering team what the feature would cost to build. It meant host-to-host exchanges between the app and the POS, sitting on top of the configuration quirks of more than 2,500 stores, no two of them wired quite the same. It was the largest single build in the project.

Before the next meeting I went to the data team and asked how customers actually earned and spent their points. On average a customer redeemed once every three weeks, and the discount they took was rarely more than a quarter of a dollar. We were being asked to point the project’s biggest engineering effort at twenty-five cents, when there were cheaper ways to make the app stickier.