Reading the blog - sigh . . .

  • 2
  • Question
  • Updated 2 years ago
  • Answered
Archived and Closed

This conversation is no longer open for comments or replies and is no longer visible to community members.

So I was just reading the Automatic blog - and I know this is from a couple of months ago, but I don't usually read Automatic's blog.

Anyways, I was reading the post labelled "Personas didn’t work at Automatic. Design principles did."

I want to address a few things:

"A design system only works if the rules it is based on are followed."

Well - design is a bit more like art, and less like rule of law. Art tends to be "it's okay to break the rules, if you know what you're doing." Intentionally breaking an artistic "rule" can make a piece of art feel edgy or have more impact.

Even with rule of law, though - it's not quite as ironclad as we think. Emergency vehicles are allowed to be an exception to what would normally be minor traffic violations in order to serve their role properly. Self-defense is often considered an exception to what would normally be murder charges.

That said - I would agree that you don't break a rule for no reason whatsoever. After all, the rules themselves would be useless if they weren't followed at some level.

What I do value a lot is how a product serves its users. After all, that's the reason why we, as users, buy products such as Automatic: It serves us in some way. It helps us to accomplish our goals, such as increasing our awareness of bad driving habits, tracking miles for work, or telling us what that "check engine" light is trying to tell us.

So I do think the user experience is vital, and ought to be a core part of any product or service.

So my heart really sank when I read this:

"Avoid making exceptions (really!) even if it would improve the user experience."

The user experience should be part of the rules. It shouldn't be considered some sort of exceptional case. Your users are why your product exists.

Your target market isn't a set of rules. Rules don't buy products. Rules don't go on trips. Rules don't own cars. I've also gotten to the point in my life where "principles > people" is a philosophy I generally disagree with. I've seen too many people burned by some stickler who remembered "the letter of the law" but forgot "the spirit of the law." Design principles are the same way: They exist to lead you along a path that will benefit your users, not to be a burden upon them.

The purpose of the rules is to make a great product for your users. And it's that purpose that should be centerpiece of decision making, rather than the "rules" themselves. The rules merely serve as a guide to keep you on track to meet that purpose.

So, we get to this:

"Instead, consider the design system as a whole and make improvements there so the whole app benefits."

So who benefits? Not the app. The app itself doesn't have needs or desires. The app doesn't buy products. The app doesn't go on trips. The app doesn't own cars.

Ultimately, improvements to the app benefit the user. So again, it goes all the way back to the user.

So, let's tackle the example that is given:

"Just the other day we were debating whether or not to include disclosure indicators on tappable elements of the new app."

Okay, sounds like a reasonable thing to discuss.

"On one hand they seem unnecessary"

That's kind of a bit vague. If there were no other factors involved, I might consider that argument for the sake of a clean UI, but virtually any other argument would have a lot more weight to it.

"clutter the UI"

This is basically explaining why it "seems unnecessary." A more detailed restatement of the first point.

"and feel 'undesignerly'."

The only reason why things "feel designerly" to begin with is because designers put a lot of thought (and often research) into their designs. It may be possible to "feel" what good design is and what it isn't, but if you don't know the exact reasoning behind why they do what they do - then it's possible your "feelings" could make mistakes.

I'm also somebody who agrees with Don Norman: I agree with him that affordances, natural mappings, etc can lead to better design. While I completely understand that simplicity and avoiding clutter can be a noble design goal, I don't understand why many designers are taking a "simplicity at all costs" approach and essentially throwing out the baby with the bath water.

In the case of the "disclosure indicators," they really did serve a purpose: They exist to indicate to the user that "there's more here." Otherwise, the design looks identical to an average list.

Which is why you discovered this:

"But on the other, our user testing suggested tappable areas of the screen weren’t immediately obvious without them."

Yup. And that's really where I would have made the decision to include them. They had a clear benefit to the user. I do not believe that the desire to avoid clutter should take precedence over a clearly beneficial inclusion. The pointing to principle #3 ought to have been unnecessary.

I think I agree that "personas" was a bad idea. It sounds like a euphemism for stereotyping. In fact - reading the Wikipedia entry, it basically is stereotyping. I'm surprised anybody would seriously use such a technique. Being that it would be based on preconceived notions of what people are like, it would only give the appearance of being customer-centric, rather than being actually customer-centric.

Working with users directly, soliciting their feedback, and providing a forum like this one is IMO really the best way to get a sense of what users want.

Sorry for the long post, I guess I kinda got wound up about it . . .
Photo of jeremiah.moss


  • 962 Points 500 badge 2x thumb

Posted 2 years ago

  • 2
Photo of Ljuba


  • 3,536 Points 3k badge 2x thumb

Hi Jeremiah,

Thank you for the thoughtful response to my blog post about our design process. And while I’d love to get into a friendly debate about the relative merits of different design methodologies and mindsets, I can’t because I don’t disagree with anything you said.

If I may summarize your critique, it’s that our design principles seem insufficiently user-centered. I can see how they might come across that way to someone who doesn’t work here, but like I said in my post, these are not general principles for good design. These are principles for *our* team building *this* product.

The reason this matters is because in the past our team had a tendency to solve user problems in one area of the app that later ended up causing user problems in another. This was an outcome of caring about user needs without the guidance of strong design principles. That’s why we made them.

The statement “Avoid making exceptions (really!) even if it would improve the user experience" is deliberately provocative. It reminds our designers that local improvements to a user experience can have negative consequences elsewhere, for example by making the app less consistent. It’s there to remind us to think holistically.

As for language like “so the whole app benefits”, to our ears this could have no other meaning than the app benefits so that it can better serve our users. 

The product we’re working on is really complex, but it must not feel that way to our users. Regardless of the specific language used, these principles have had the effect of helping move towards that goal. That’s all we need from them. 


This conversation is no longer open for comments or replies.