An attendee asked about how you can shift an engineering driven company to become more user centered.
It is true that at the very first kind of thought, you may say it’s more important to develop a feature than have a good quality feature. But it’s actually I don’t think it’s true because that’s what I was talking of, calling the utility gap versus usability gap. And it’s still the gap is you don’t have a feature, and that’s certainly wrong. But the usability gap is you have the feature, but people can use it and that’s just as wrong. And so that’s the argument you have to make, is that it’s wasted to have all these brilliant engineers develop and implement all these fancy features if they’re not being used. And you will most likely, if you do any kind of analytics statistics, see that people usually tend to stay in a small corner of the product and use a relatively small amount of the total feature set. And that is the cost, a penalty of bad usability that you’ve spent.
You know, you spend like more than half of your engineering budget and developing things that are not being hotly being used. Maybe a few super users can use them, but most people cannot. And yet, if you spend like an hour using recommendations like 10 percent of the total budget, if you spend 10 percent of the budget on finding out how to make it such that people can use it, you will make the other 90 percent of your budget spent better because people will use it, let’s say, twice as much. And so you can basically double the usefulness of the impact of your product. So 100 percent gain by 10 percent of investments, that’s a huge return on investment. So those are the type of arguments I would I would try to make. And then, of course, we have a lot of other arguments as well as sort of like why shouldn’t engineers be the ones to design a user interface? And this is where you can appeal to their advantage to say you are just too smart, you know too much about computers and ultimately you are not representative and customers, which is true in every case except if you are developing a developer product, you know, and even then the people who are working on that, you know, sovereignty nearing tool, they still know more and more about their tool than the average programmer will know. So even then, the people on the development team themselves are not going to be the best at judging what’s easy, what’s hard, what’s going to be convenient for the, you know, the great masses of users to use.
I mean, there’s a lot of arguments, but I would like to just go back to kind of our return on investment argument that says spend 10 percent of your budget on making sure that you double the use of the other 90 percent of your budget.