I’ve had an iPad for a few months now, but only recently I started using it to read eBooks. Although for me an electronic device will never replace the texture of paper and the smell of the freshly pressed ink, using the iPad to read books is a delightful experience. I enjoyed it from the first moment.

Where the iPad excels in general is in the delight factor. It’s not only functional, but it’s pleasurable, even fun to use. You want to interact with it. You want to touch it!

The kindle, for example, has two buttons – a back and a forward. What else do you need? What else can you do with a book other than turn the pages? iBooks for the iPad has these buttons, but you can also pick the page up with your finger and drag it to the other side. You see a quaint animation of the page flipping, complete with a rustling paper sound effect. Not only is it slower to turn the page with this method, it’s also more cumbersome, as you have to move your hand that is holding the iPad, move it to the screen and make the swiping motion that turns the page. A book reader certainly doesn’t need this. You can’t do it on the kindle. But there it is on iBooks.

Why? Because it’s delightful. Because it’s fun to do; because the act of using your hands connects you emotionally to the book as you subconsciously reminisce on using a real paper book; and it’s fun to show people. “Look, you can even flick the pages with your finger!”

This, to me, is the difference between quality and delight. Quality is making the product work – flawlessly. If the software solves your key use cases in a predictable, intuitive and consistent manner, then it’s quality software. But people don’t buy quality – they buy an experience. They buy delight. When you buy an iPad you don’t just buy the aluminium, glass and engineering – you buy the right to show your friends how the pages turn on iBooks. You buy the ability to interact with software in a new, exciting and emotional way.

Pure quality is boring – but delight sells.

Are you designing a delightful experience? Unless you are writing software for insurance underwriters, you probably should be.