Meet terry.
"A device and system that slices your food bill, cuts your food waste and
intelligently plans your meals. He caters for fussy eaters, a strict diet and
the lazy cook. terry’s system is based around a control panel with a
receipt scanner, which can be used independently or enhanced with the
use of Wi-Fi, an app and a website."
terry was a response to the Waste Not Want Not brief set by RSA. The project was set by our school, and I worked on it as part of 'team hotdog', the brief challenges it's subjects to design a way to reduce food waste in society.
Our new product involved the introduction of an 'Internet of Things' device, who's main function was to scan food receipts, and remind users when food was due to be out of date. It incorporated a strong 'emotional design' element, as the device would become upset as your food went out of date. Out of this, to solve micro-problems, and to get more function out of the basic technology, there evolved a wide, wide range of features and neat-ish solutions including: communication via instant messaging with the terry system, local competitions, meal planning for the whole family, sharing leftovers with local strangers, price comparing local supermarkets, calorie counting, cloud sharing recipes with freinds ... and more.
In order to contain this sprawl of features, we produced an array of diagrams showing how the system would work and be organised;
User Services
System Diagram
And the 'touchpoints' of the service design system were quite carefully designed, I would argue that the industrial design of the main physical product is both neutrual, clever, and confident; the capacitive, clicky bezel is the control surface - similar technology to the apple magic mouse - and aims to keep greasy fingers off the screen.
A lot of work went into containing the sprawl of features into a manageable interface - again quite good visually, and makes some sense when you get into it.
However, despite a very good work ethic from the team, large amounts of research, brainstorming, decent graphic design, product design iteration, technical explanation, and prototyping, the project got nowhere. We neither achieved a particularly good grade, nor processed in any way in the RSA competition.
After time to reflect on why, the answer becomes clear. terry was a Complex Solution to a Complex Problem. Our efforts have merely transformed the problem of food waste itself into a product that lis likely to be a christmas one-hit-wonder - and likely become a big product waste problem. We have also turned the difficulty of managing food waste in the home into the difficulty of maintaining control over a large app ecosystem. I think there is a very low chance of this product gaining many 100% committed users.
I am still a student though, so I can learn some important things from the fact that this project went the wrong way.
Less is more, especially when proposing a new idea, or launching a new product. In 'solving' many small issues with new functions, the product lost a core focus, and instead of presenting one simple, clever and refined idea, the product became a mess of slightly interesting ideas. For a good example of this done the right way, we can look at the first iPhone.
A simpler, less useful terry, which perhaps only connects to an online meal plan and makes faces, would have perhaps been much more compelling. It would have certainly been easier to present.
In our case, when questioned on an issue with our product, we would give a quickly thought out, completely made up answer, commonly falling back on 'we use cloud data' or 'it's provided by the users' as excuses for holes in our concept. The concept was in fact, very good at giving us these fallbacks, it's a connected device with infinite power, connected to an infinite amount of users, with infinitely powerful servers. 'Forward thinking' one might say. So instead of refining our idea into a good concept, we added features to fill in holes.
A product is not always the answer. This is a hard one to 'learn' from, because it was our course that specifically asked for a product design solution, but not the RSA brief. Saying that, we could have been a bit more boisterous, and presented an app anyway, or at least in the RSA submission. Outside of the course though, we can take this as a lesson - our course prepares us primarily to design and to answer questions, that is our speciality, not to make new plastic things. This can be seen in the wider world as well, places like IDEO and Tangerine are increasingly offering 'advice' to their clients and not merely product designs - in the form of workshops, service designs, system thinking et cetera.
Terry would have made perfect sense as just a standalone app, we worked out what we needed technology wise, all that we really needed was the device for scanning receipts, which was questionable in itself when we have perfectly good phone cameras. As designers we should realise our wide, transferable skill set, and if we remain agile, then the world will see less useless things, questions will be answered properly, and we will maintain good job prospects.
You can't polish a turd. As the common saying goes. The focus in the later stages of the design process fell on collecting and 'refining' the mass of features we had. This meant some very clever and careful interface design (for which no marks were necessarily awarded), and some hard-worked technical-ish explanations (which were pretty much made up with no chance of prototyping). Dozens of pages were produced to explain away every feature of the product, but we did't actually get anywhere in terms of proving and developing the concept.
Our man-hours would have been better spent on producing rough prototypes, or asking users about our proposal, finding out more about the actual problems that lead to food waste. Then, if needed we could tear up our concept and provide a rough but effective prototype - something that actually would have been 'thought out'. Our actual research only served to confirm what we had already designed.
In the end, the presentation went smoothly, we presented slicky, with great visual cohesion, and had an answer for every question. But in the real world, no amount of slick presentation can prevent a failure. At some point; detail design, production, marketing, sales, or even a year into the product's life on shelves, it's core issues will come to the fore.
***
In summary, this project was a learning one. The core issues of the product are feature bloat, design by committee, and a failure to be reasonable with what we expected users to actually bother to do. Having said that, we at least made a product which didn't require masses of external change - we weren't suggesting that Waitrose change their entire barcoding and inventory system to benefit our product- as I had seen in some other responses to the breif, and we had some great visual design. In future projects I should be attempting to 'tear up' the concept at any stage, and seek to reevaluate the problem throughout. And remember,
"Perfection is Achieved Not When There Is Nothing More to Add, But When There Is Nothing Left to Take Away"