The Kano model

    Using the example of the innovation of a customised home page from the early days of Flickr, this article helps break down how to delight users:

    Years ago, we came across the work of Noriaka Kano, a Japanese expert in customer satisfaction and quality management. In studying his writing, we learned about a model he created in the 1980s, known as the Kano Model.
    The article does a great job of explaining how you can implement great features but they don't particularly get users excited:
    Capabilities that users expect will frustrate those users when they don’t work. However, when they work well, they don’t delight those users. A basic expectation, at best, can reach a neutral satisfaction a point where it, in essence, becomes invisible to the user.

    Try as it might, Google’s development team can only reduce the file-save problems to the point of it working 100% of the time. However, users will never say, “Google Docs is an awesome product because it saves my documents so well.” They just expect files to always be saved correctly.

    So it’s a process of continual improvement, and marginal gains in some areas:

    One of the predictions that the Kano Model makes is that once customers become accustomed to excitement generator features, those features are not as delightful. The features initially become part of the performance payoff and then eventually migrate to basic expectations.
    Lots to think about here, particularly with Project MoodleNet.

    Source: UIE

    The Project Design Tetrahedron

    I had reason this week to revisit Dorian Taylor’s interview on Uses This. I fell into a rabbithole of his work, and came across a lengthy post he wrote back in 2014.

    I've given considerable thought throughout my career to the problem of resource management as it pertains to the development of software, and I believe my conclusions are generalizable to all forms of work which is dominated by the gathering, concentration, and representation of information, rather than the transportation and arrangement of physical stuff. This includes creative work like writing a novel, painting a picture, or crafting a brand or marketing message. Work like this is heavy on design or problem-solving, with negligible physical implementation overhead. Stuff-based work, by contrast, has copious examples in mature industries like construction, manufacturing, resource extraction and logistics.

    As you can see in the image above, he argues that the traditional engineering approach of having things either:

    • Fast and Good
    • Cheap and Fast
    • Good and Cheap

    ...is wrong, given a lean and iterative design process. You can actually make things that are immediately useful (i.e. 'Good'), relatively Cheap, and do so Fast. The thing you sacrifice in those situations, and hence the 'tetrahedron' is Predictable Results.

    If you can reduce a process to an algorithm, then you can make extremely accurate predictions about the performance of that algorithm. Considerably more difficult, however, is defining an algorithm for defining algorithms. Sure, every real-world process has well-defined parts, and those can indeed be subjected to this kind of treatment. There is still, however, that unknown factor that makes problem-solving processes unpredictable.

    In other words, we live in an unpredictable world, but we can still do awesome stuff. Nassim Nicholas Taleb would be proud.

    Source: Dorian Taylor

    The Project Design Tetrahedron

    I had reason this week to revisit Dorian Taylor’s interview on Uses This. I fell into a rabbithole of his work, and came across a lengthy post he wrote back in 2014.

    I've given considerable thought throughout my career to the problem of resource management as it pertains to the development of software, and I believe my conclusions are generalizable to all forms of work which is dominated by the gathering, concentration, and representation of information, rather than the transportation and arrangement of physical stuff. This includes creative work like writing a novel, painting a picture, or crafting a brand or marketing message. Work like this is heavy on design or problem-solving, with negligible physical implementation overhead. Stuff-based work, by contrast, has copious examples in mature industries like construction, manufacturing, resource extraction and logistics.

    As you can see in the image above, he argues that the traditional engineering approach of having things either:

    • Fast and Good
    • Cheap and Fast
    • Good and Cheap

    ...is wrong, given a lean and iterative design process. You can actually make things that are immediately useful (i.e. 'Good'), relatively Cheap, and do so Fast. The thing you sacrifice in those situations, and hence the 'tetrahedron' is Predictable Results.

    If you can reduce a process to an algorithm, then you can make extremely accurate predictions about the performance of that algorithm. Considerably more difficult, however, is defining an algorithm for defining algorithms. Sure, every real-world process has well-defined parts, and those can indeed be subjected to this kind of treatment. There is still, however, that unknown factor that makes problem-solving processes unpredictable.

    In other words, we live in an unpredictable world, but we can still do awesome stuff. Nassim Nicholas Taleb would be proud.

    Source: Dorian Taylor

    The backstory of Apple's emoji

    This is a lovely post, full of insights and humour. A designer, now at Google but originally an intern at Apple, talks about the first iterations of their emoji.

    My favourite part:

    Sometimes our emoji turned out more comical than intended and some have a backstory. For example, Raymond reused his happy poop swirl as the top of the ice cream cone. Now that you know, bet you’ll never forget. No one else who discovered this little detail did either.

    A fantastic read, really made my day.

    Source: Angela Guzman

    The backstory of Apple's emoji

    This is a lovely post, full of insights and humour. A designer, now at Google but originally an intern at Apple, talks about the first iterations of their emoji.

    My favourite part:

    Sometimes our emoji turned out more comical than intended and some have a backstory. For example, Raymond reused his happy poop swirl as the top of the ice cream cone. Now that you know, bet you’ll never forget. No one else who discovered this little detail did either.

    A fantastic read, really made my day.

    Source: Angela Guzman