In the next few paragraphs I am going to share some practical examples and learnings from projects we have run with clients where we have applied these principles and gathered some experience along the way.
The first looks at a simple example of Customer Desirability. One of our clients in the Mining and Construction industry needed to understand how to increase adoption and engagement of their consumer application. To solve this need, we conducted a usability test using Google Ventures Design Sprint methodology. Our test yielded a number of interesting findings, one of them standing out in particular. The application used complicated business language such as ‘cubic centimeters squared’ and ‘volume’ when our users spoke in terms of wheelbarrows and bags as a form of measurement. In our country, where English is not a first language for the majority, using practical terms which are easily understood is a great way to engage a customer and make them feel like they are seen. Our recommendation to the client was to add in this type of functionality and speak the user’s language, which would naturally result in greater adoption and engagement.
The second example looks at Business Viability. We partnered with one of our clients in the Telecommunication industry to drive human-centered design and agile delivery of digital products and services. This involved working in an agile manner in cross-functional squads, very far from the comfortable norms of milestones and 100-page functional spec documents. Due to our setup, we had the customer desirability part ticked; we conducted various interviews, looked at data and designed solutions which we tested with customers on a regular basis. We also had the luxury of setting up our technical environment in a sandbox manner, separate to how the rest of the business operated. Our customer and technical circles were covered. The last fundamental circle of business viability, however, was a tough one. The ‘soft’ requirement of encouraging traditional, old school employees to come along on a digital, agile ride cannot be underestimated. Our digital team challenged the corporate norms from ways of work (agile vs waterfall), how squads were costed for (hourly rate vs milestone) and how success was recognised (outcomes vs outputs). This ultimately resulted in a lot of push back from business and slow go to market.
The third example focuses on Technical Feasibility and is a pretty common, ugly problem which ultimately leaves developers in a tricky situation. I head up a team which specialises in the strategy and user experience design aspect of building products and services and so we are generally the first to engage with a customer, understand their needs and design according to what the business and customer defines. On one such project in the Entertainment industry, the technical difficultly of the backend platform we needed to integrate into was underestimated, resulting in delayed go to market. We had designed an amazing experience but could not support that experience technically. As they say sometimes your failures are your biggest lessons, and we were reminded why valuing each of IDEOs three circles equally is so important.
The question we were left after all of this practical experience was how do we practically, within each project, ensure customer, business and tech are equally accounted for? At EOH Digital, our approach has been to adopt cross-functional, agile squads who iterate through the process of discovery, definition, design, build and launch.
In the next article I will be looking at why cross-functional, agile teams are the new way of building successful products and services.