Designing Platforms and Apps

This is a diagram I have drawn on hundreds of whiteboards. It’s simple yet shows a fundamental part about design. In order to work creatively, you need to step into the problem and immerse yourself, but to get a sense of how well you are doing you need to step back out and take a look at the problem from outside. This is what critiques and presentations help you do, and then you step back into the problem, out again and so on till you are done.

This diagram however, can also be used to talk about how you need to work when designing platforms. First you sketch out some components, then you build some apps, realise what you are missing and build more platform, then more apps, and so on.

Often you’ll structure your team around platforms and apps with some people making the reusable components and others using them to build showcase apps and providing feedback.

Nothing provides more feedback than the visceral feeling of working through a problem and not being able to complete it with the building blocks you have. In the past I’ve seen platforms being more successful when people working on apps also have responsibility for reusable components and people mainly working on the framework also have day to day responsibility for actual shipping apps. Not showcase apps. Real shipping apps that have to be great and serve a real purpose with real quality constraints. Here illustrated with my second most drawn whiteboard drawing. It’s 80/20 for platform and app people. Some spend 20% energy on apps and 80% on platforms. Others the reverse. None spend a 100% anywhere .

Things may still go wrong when building a platform but that can usually be ascribed to the apps not being real enough. They don’t drive the right requirements to the platform.

Take a look at iOS then look at Pages, Numbers, and Keynote and see how they have had to jump through all kinds of hoops to make those apps work. The same problem can be seen on Windows Phone with Microsoft Office and was for years a point of contention between the Office and Windows divisions at Microsoft. It’s typically because the platform folks make what amounts to toy apps instead of real meaty apps that ultimately is what the ecosystem most platforms ultimately depend on will want to build.