Functional → Usable →Delightful

A very simple framework for assessing your product’s features


Functional = Does it work?

Usable = Can users actually use it without extensive training or handholding?

Delightful = Does this give users pleasure? Enough pleasure that they use it…a lot. Enough pleasure that they actually smile the first time they try it. Enough pleasure that they will tell others about it.


Functional is a technical problem. Solve the technology and move the slider here. I would classify many Gmail features in this state. They work, but they are very difficult to find or operate. One could argue many of the features in Salesforce are the same way.

Usable is a technical problem combined with a UX problem. Solve those and you’ve got a usable feature. I would consider Tumblr’s feed Usable. It works and I can use it. But I don’t love spending time in it.

Delightful, however, is something different. You don’t have to be Delightful to be usable. But you do need to be Delightful to have significant impact. Delightful takes talent. Delightful takes time. Delightful takes understanding, caring & craftsmanship. Much of what you find in Medium is Delightful. The content editor that pops up when a word is highlighted is Delightful. The ability to edit on the same page the post is published is Delightful. The simple analytics (as well as the “Read” metric) — Delightful.

Delightful is what separates the good from the great.


I like to keep this spectrum in mind when building out a new product. New products are almost always resource constrained. This means it’s impossible to make every piece of your new product delightful before launching it to the world. Not everything, not every feature, can be completely built out to this state. Many non-technical founders/execs/boards tend to push for EVERYTHING to be delightful. But the reality is that if you focus on making everything Delightful before shipping, you will be never ship anything.

At the same time, if you only make every feature Functional or barely Usable, you’ll ship quickly, but not many people will care. A lot of times engineers will push more for Functional. Make it Functional and move on.

Thus the healthy internal conflict of building a software product. The good news, if you treat it as such, is that this conflict will help you focus your energies the right way. It will help you focus on the 1-3 features that define your app and make sure that you make them special. Delightful as possible.

Then be ok with leaving other features/pieces at the Usable level.

And there will be some things that you need to have, but that can remain at a Functional state for a while (maybe forever). They aren’t worth the resources.

As you work through all you major features and as the business grows, you will be able to circle back on features left in lower states and push them further down the spectrum.


Want a fun exercise? Have the team rank your features

This is a fun exercise. In the coming weeks, put together a quick survey (I recommend Typeform), and ask your team to rank the features in your app on this spectrum. Compile the results and look for surprises. You may get a few (both bad and good).

Rank your features on the spectrum — a fun exercise ☺

Map out each feature on a map like the one above and make sure everyone on the product team sees it. Decide which features should be further down the spectrum and get the team to help you understand how to make this happen.

This simple framework may help facilitate some great leaps in your product.

Would love to hear your thoughts/comments. Email me anytime (derek@knowtify.io).

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.