Through a series of wheelings and dealings, I have gotten myself infiltrated into the Aakash project, which (if you live on a different planet and therefore haven’t heard yet) is the Indian Government’s plan to make a $35 tablet and universally distribute it to students. There was a review meeting yesterday for Aakash 3 (Aakash 2 is now shipping, as I understand it) and I have some strong opinions about the process by which it is conceptualized.
First, I must say the people engaged in this project nation-wide are very forward-thinking about the kind of applications that Aakash will have. I can’t reveal specifics, but I came away from yesterday’s meeting with a very upbeat feeling that this device, widely deployed, could revolutionize education in the country. The promise justifies the investment of time and effort that people are making on the project.
It was interesting to see the way Aakash is being designed (by committee), and contrast it with the way I designed Avaz (almost alone). And the way I was taught to design products in my first year in college…
The objective of product design is to build something that is useful to the customer, with the least amount of effort and cost, and in a reasonable amount of time. (As Steve Jobs said, ‘Real engineers ship.’) However, making a product involves making literally thousands of design decisions, from the color of the casing to the clock speed of the microprocessor. And this is true even if a product doesn’t need fundamental invention. What differentiates the good product engineers from the bad, is the way in which they are able to make those decisions quickly and efficiently, while being able to think outside the box, while always keeping the customer’s interest in mind.
It is not at all easy to do this. The problem is cross-linkages; if you add muscle power to a car, you increase its weight. If you add rich user experience to a tablet, you increase its cost. How do you make those trade-offs?
There are a lot of good engineers and product managers who make those decisions by the gut. They know the rough countours of a product spec (usually from competing products out there) and are able to tweak in the right areas to get things moving. However, if you are making a ‘first-of-a-kind’ machine, you’ll have to use some kind of process to stay on top of the Engineering beast.
When I started designing Avaz, I started with ‘use cases’. I visualized ten kids who would be the ‘power users’ of Avaz three years from its launch. They would use Avaz in different ways: some would talk to their teachers and parents using Avaz, some would achieve independence with their daily activities, some would use it for taking exams and finishing schooling, some would use it for creative expression. I visualized them to an incredible level of detail: their age, their gender, the occupation of their parents, the town where they lived, the number of aunts and uncles in their families… Then I visualized how these ten kids would use Avaz in their daily lives. I must emphasize that though none of the kids were real, they were all composites of real people (and I kept track of which real kids they were modeled from). This formed the basis of my ‘customer stories’. I wrote my customers’ success stories even before I had a product concept!
Then I used these stories to create a list of ‘user specifications’. These are specs for what the user would want to do with the product. For example, one spec was ‘should be able to demonstrate my personality through Avaz’. Another was ‘it should not break when I drop it’. Though I made the first list using my imaginary users, I showed this list to about 20 people (parents, kids, teachers) and fleshed it out, adding new requirements as people came up with them.
Then the difficult bit: figuring out how to convert the user specifications into technical specifications. This requires solid engineering understanding and deep product knowledge. For example, you need to figure out that the ability to control the pitch of a voice synthesizer would be critical in helping an Avaz user individualize the product, or that the drop-test performance of an enclosure would directly relate to its ruggedness.
What you do with the user specs and the tech specs next depends on who taught you design. What I do is something called QFD – quality function deployment. This is a table which maps ‘Whats’ – the customer requirements – to ‘Hows’ – how the engineer will implement them. In this table, you capture cross-relations between Whats, between Hows, and between the Whats vs Hows. QFD provides detailed guidelines also on how to assign quantitative measures to each of the Whats, and allows you to rank the Hows based on how difficult or resource-intensive they would be to implement.
If you have successfully built a House of Quality, you now have everything you need to make quick, good design decisions. You could create a weighted list of technical features, and order them based on how important each one is to each type of customer. You could do market research to figure out the segmentation of different customer types, and weigh their importance accordingly. And finally, you would come up with engineering specifications for your product.
At that point, the QA team takes over. I’ve always insisted, on all the products I’ve worked on, that when the designers get their pencils out, so should the testers; for each engineering spec, there should be a way to figure out the extent to which it is being met. Only then does the implementation team even get formed.
So that’s how I do design. I swear by QFD, I swear by testing, and I believe my customers.
I think the incredible potential of Aakash – and the sheer amount of resources the Government is planning to put behind it – means that some form of design quantification should be done before the pencils come down on drawing sheets. I’ll do my best to steer this agenda from the inside, but I have no idea how successful I’ll end up being. Wish me luck!