The difference between developers and product designers

Our company is bidding on the re-development of an existing product that has outgrown the technical framework on which it was originally built. The customer has received a handful of offers, and the range of costs and technologies found in those proposals is causing him considerable uncertainty in his choice.

In response to that uncertainty, we’re nudging him to look beyond whether to use Ruby on Rails (our choice), Meteor or Laravel since, at the end of the day, the success or failure of his business will not hinge on technology. Instead, we’re encouraging him to consider the difference between a developer and a product designer, and focus on the critical question of who is capable of creating a product that will ultimately prove successful to his business.

To illustrate, let’s consider what happens when you signup for an account in their existing platform. Upon first login, you see something like this:

The original specifications for this product probably contained something along the lines of, “The system will have an accounts screen that lists all colleagues associated with the organization.” The developer then went about the task of satisfying the requirements, thinking:

When the account screen is accessed, I’ll query the database for all colleagues. And to account for the case there are no colleagues, I’ll show the message, ‘No colleagues found’.

Most developers focus on requirements and technology—i.e. the database query, the message to show if the query returns nothing, etc.—and fail to reflect deeply on the actual use of the product they’re building. In this case, the developer didn’t consider the one instance—and a critical one in terms of product success—of an empty database query that every single user will experience—Their very first engagement with this screen as a new user.

As a new user in this system, I’m left disoriented and confused:

  • Where am I, and what am I supposed to do?
  • The “No colleagues found” text seems like an error message. One minute in, and I’ve already done something wrong?
  • “Show blocked colleagues?” What is a blocked colleague? If I click that, the only thing that happens is that the text changes to “Hide blocked colleague”.

Had I created this account as a potential new customer wanting to “kick-the-tires,” there’s a good chance that I’d leave and not return, since experiencing friction in my very first interaction with the product is probably a good indication of what’s to come should I stay.

A good product designer is continually putting himself or herself in the shoes of the user, taking into account their context, their mindset, their knowledge and expectations, and looking to resolve any aspects of interaction with the product which potentially introduces friction.

In this example, a good product designer would identify the need for a “blank slate” version of the account screen, that’s welcoming and orientating for first-time users. Perhaps something like:

And therein lies the enormous difference in value between the average developer, and the very few who are good product designers. The former creates collections of features that “satisfy requirements”, while the latter creates coherent, effective and ultimately successful products.

Authenticating support requests

I experienced something today that’s frustratingly becoming quite common. I emailed the support address of a financial institution I use, and they replied that they can only provide support if I contact them from the email address registered to my account.

The problem here is that as the owner of my own domain, I can receive email sent to [email protected], and I take advantage of that by using unique email addresses for most services I sign up for. (If for nothing else, this makes it easy to determine who’s passing on my email address to spammers.) But I can not easily send emails from all those different addresses, since that would require adding each one manually to Mail.app.

What I find irritating, is the company’s assumption that the “from” address serves as any kind of authentication, since it’s dead easy to spoof the from address on an email!

Any company that wants to provide authenticated support must provide a mechanism to initiate the conversation only from within a logged-in authenticated session at their website (or app). After that, it’s fine to continue the conversation outside the authenticated session—e.g. using ZenDesk, HelpScout or whatever support tool they use—because regardless of the email address I use from that point forward in the conversation, I wouldn’t be in a position to even respond if I hadn’t been the one who securely initiated the conversation in the first place.

The design of one-click feedback

Today I received helpful support from Kimberly Castleberry, who works at Yoast. At the bottom of her email was a mechanism to provide feedback:

I’m busy, but at the same time do want to “give back” in appreciation to Kimberly, because lord knows how shitty customer support has gotten these days.

So what’s my expectation—or rather hope—when clicking on this button? That it’s a one-click operation, just like unsubscribing from most email newsletters. But even then, those one-click email unsubscribes aren’t truly one click, because you still have to close the “You’ve successfully unsubscribed!” window.

That might seem insignificant, but that one little extra step actually registers a small amount of irritation in my mind. I’m not sure why, but perhaps it’s because I hate wasting time, and closing the window triggers an awareness of the cumulative amount of time I lose in a valueless component of the process of unsubscribing from the countless newsletters I somehow get signed up for.

But back to this feedback workflow: Yoast use HelpScout — and I love HelpScout! We use them too, so no knock on them—and after clicking the smiley face, I again registered that slight feeling of irritation having landed on a page where I have to take at minimum two further actions: (1) clicking the “Send” button and (2) closing the window.

The unfortunate consequence is that I’m unlikely to participate in those types of feedback opportunities again, so this is an area I feel could use some workflow design improvement, targeted towards making it a truly one-click, friction-free interaction.

Deteriorating user experience design at Apple

In a recent Philip Greenspan post questioning Apple’s competitive edge going forward, I found myself sympathizing with this anecdote:

What about Apple’s supposed leadership in user experience? Plainly the Apple Health programmers didn’t get the memo, but surely the core iOS has a better/cleaner user interface than any Android or (gasp!) Windows phone? I might have thought so until I visited a neighbor. She is intelligent and well-educated, but not passionate about technology. She said that she had hardly gotten any phone calls for weeks. I discovered that her phone was in “Do Not Disturb” mode. She had entered this inadvertently by mistakenly swiping up from the bottom of the screen then touching the moon symbol (a nice icon but there is no explanation of what it means). No programmer at Apple had thought to have the phone display a confirmation dialog box after a few days in DnD mode.

The pace of user interface innovation at Spanish airports

Back in 2003, I posted this paragon of user interface design that I discovered at the Malaga airport, when trying to pay for my parking ticket:

While visiting the Malaga airport this weekend, I thought I’d check to see how things have things have progressed over the past 13 years—yes, thirteen years!! As you can see, the size of smartphone images has increased over that period, but unfortunately the user interface design of Spanish airport parking machines hasn’t seen much progress:

As far as I can tell, the only change to the machine is the addition of some stuck-on signs helping to explain how the crazy contraption works!