Please note this is highly opinionated piece — please be aware of biases!

As you know, there are a plethora of apps out there. Some are “amazing” – they are easy to use, have useful features that make life easier, and they are a delight to use. We even tell our friends about them, or write about them. And then there are some products that are not so “amazing” – they fail in one in one of the above aspects that makes us abandon them — not good for businesses!

On my quest to understand what makes a product “amazing” and unearth a framework to help us make any product “amazing”, I’ve found one classification system that allows you to categorize products into one of the following three groups:

• Engineering-driven,
• Design-driven, and
• Product-driven

Let’s dive into each of these.

 

Engineering-driven products

I define Engineering-driven products (EDPs) as products that focus solely on a technical capability.

The issue is not with the product’s technical capability, but the issue is the focus of the product is solely on the technical capability. A little confused? Well let’s look at the perfect product that epitomizes EDPs: Google Maps.

When you look at Maps, all you see is a map. What can you do with this map? What are your options? I sometimes think the thought behind this product was simply this:

Let’s create a map! It’ll show everything about a given area!

The usability of Maps is atrocious (although it is getting better, notice the little hint box under the search input field box). Unless you’ve used this product previously, you wouldn’t be sure how to use it. Still not convinced? Try to think about the first time you used Google Maps…

At the time Google Maps launched, having such a capability to create an interactive map of a given area with so much data was amazing. But people don’t want to just see a technology, they want to know what they can do with it.

EDPs fail in the regard that place a high cognitive load on you to use their products. You need to figure out yourself what you can do with them first before you can use them.

On a side note, EDPs may sacrifice visual aesthetics or deem it not important enough.

Design-driven products

I define design-driven products (DDPs) as products that focus way too much on interactions and looking visually cool/appealing to a point (unlike some EDPs that don’t care about visual aesthetics) that they can be confusing. A good example of DDPs is the Chase Android app and Evernote.

Let’s take a look at the Chase Android App’s login flow:

 

Compared to the initial Android app (which was butt ugly), the login flow is very visually pleasing and it has the logo levitating to reveal the login fields, but as you can see I struggle to log in. Once you the keyboard comes up, I can’t see the Log In button anymore and it takes me a while to figure out that I cannot scroll the screen, then I have to think about how to log in guessing that perhaps that the Done button on the keyboard will sign me in.

Here’s the sad part: Although I think of myself to have a decent amount of intelligence, yet this login flow stumps me every time I open up the app!

Let’s now take a look at Evernote’s Web View when creating a new note:

 

It’s quite a beautiful interface! They’ve taken away all the other components of Evernote leaving only a white, blank page waiting for your thoughts to be transferred onto it. I’m not sure if they were inspired by Medium’s editor or WordPress’ editor (which I’m using to write this article), or perhaps by their own team, but I’m happy they did it as it’s a move in a good reaction.

The problem with this clean interface is that it’s too clean! Not sure what I mean? By just looking at the screenshot above, try answering the following questions:

1. How would you add a numbered list of items?
2. How would you cancel this note?
3. How would you go back?
4. Add a heading?

It’s hard to tell without interacting with the interface. Initially when they launched this feature, the top section of the page (where you can add tags, etc.) was grey and I never saw it, which meant I could not tell how to put a note in a particular notebook. As of writing this piece, Evernote has added a new piece of functionality that waits for a second or two of keyboard inactivity before removing the opacity layer on the top section so you can see what’s there clearly. Because of a bad design, they had to waste code to make it work better.

As illustrated above, DDPs focus on interaction and visual design over usability, making it hard for users to use and appreciate the beautiful work they are using.

Product-driven product

Product-driven products (PDPs) are the holy grail of products out of the three. This is where you want your product and every product you use (perhaps not your competitors!) to be a PDP.

So what is a PDP?

A PDP is a product that successfully leverages technology through well-designed (and usable) screens and workflows so that a user can easily complete a task with the least amount of mental and physical effort possible — but still be delighted with their experience.

The best example I can think of is the Citymapper app (available on both iOS and Android). Let’s take a look at the homescreen of somebody who lives in New York:

As you can see, you can do a lot! With a single tap you can do any of the following:

• See a map
• See the subway map
• Get directions to somewhere
• Get directions to a saved place
• See recent searches (if you scroll down – not pictured)

Citymapper focused exactly on what they users needed and leveraged good engineering and design to make it happen. Unliked Goolge Maps, they didn’t decide to do build every single thing possible you could do with a map, they looked at people who travelled and made their lives easier. A source of inspiration for all! Definitely one of my favorite apps and one of the few apps that I tell my friends and colleagues to download!

We need to follow in their example, focus on the users’ needs, make it easy and make it beautiful. I always think the following:

With great technology comes a greater need for thought + design.

Getting to PDPs

So your product isn’t a PDP and you’re wondering how to get it to a PDP. The first step is to identify whether your product is a EDP or a DDP, then from there we can outline a path to PDPness.

 

From EDPs to PDPs

If your product is an EDP, it is a product that is focused on an ability, which is usually a technical ability. They key to making to a PDP is to take a step back and investigate what your users are doing with the your product, and make it easier. Let’s look at the case of Google Maps:

Users can use Google Maps to do the following:

• Look at a map to get an understanding of an area including different views such as Terrain, Satellite, and Street views
• Get directions from Point A to Point B by:
  • Walking
  • Biking
  • Driving
  • Using public transport
• Find points of interests (POIs) such as restaurants, dry cleaners, stores, etc.
• See the Street View of certain places
• Create a custom map (eg. a company could create a map to show its various locations, you can create a custom map to show places to visit)

Once you’ve identified the use cases for your product, the next step is to understand which are the most common and make them easier to perform. In the case of Maps, let’s say the three most important use cases are to view the map, get directions and find POIs, then we might end up with this interface:

The user has the ability to view the map as they’ve always been able to do, but now they are being directed on what other things they can do with the product in a straightforward manner.

But the job isn’t finished yet! This new PDP needs to constantly evolve to keep it’s PDP status. A nice to have would be add some “delight” into this product. Perhaps when you click on the From box, a dropdown with your current location or last visited places shows up…I’ll leave that up to your creativity.

 

From DDPs to PDPs

The issue with DDPs are that they may be to confusing for the user due to certain elements in the workflow or on certain screens/interfaces.

To move from a DDP to a PDP requires you to study how actual and/or potential users interact with your app and see if it works for them (this is called a usability study). For actual customers, use both expert and novice users as both groups would notice different issues. I would also recommend always performing usability testing with people who have never used your product which will identify what could stop future potential users from using your products. Here are some quick, essential usability testing tips (disclaimer: I was the guest editor for this article).

 

PDPs are great for everybody, users are happy because they are effective and satisfied when using the product, and business stakeholders are happy because the users are using the products: win-win!

Getting to PDPs is not easy, otherwise there would be no reason to write this article since every product would be a PDP! Hopefully this article will help you and your product get there, but beware there is probably a lot more to make your product a PDP!

 

So what are your thoughts? Are PDPs the holy grail? Make sure you add your comment below!