Hacker News Reader

Comment by dfxm12 | Hacker News Reader

I had to read The Design of Everyday Things in college and was nodding along the whole time: yes, of course, this is so simple! It feels like common sense, but it is good to see it written out so plainly. It should be required reading for anyone creative, i.e., anyone who might create something, anything.

I get why some commercial websites fall into dark patterns (it's because they want your money). I get that years of iterations can make old software feel clunky. I just can't believe how poorly designed some new internal business applications are, even with how easy modern low code application platforms make designing interfaces/processes.

View on HN

Design, real design, is HARD.

Basic things like line length, contrast (black and white people) get screwed up by most app/web designers and devs. Then we gave all sorts of font tweaks to web monkeys and its been down hill for readability...

But a lot of it sucks because everyone feels like they can bike shed the interface, somehow design is "opinion" and not an art/skill.

Here is a blast from the past: https://getlevelten.com/blog/randall-knutson/why-web-develop...

Somethings haven't changed.

Actually design is not hard, it's mainly common sense and iteration + book learning. Where people go wrong is being unable to leave their ego at the door so they insist their design is right and don't look at the facts.

Where people go wrong is by letting management dictate design.

> It should be required reading for anyone creative, i.e., anyone who might create something, anything.

I agree. I have found that designers refuse to read it. They don't like usability at all.

My experience is that designers want users to admire the UI, as opposed to use it.

This is easy to fix:

Find 8 people to use your app, get their feedback, record them using it (what they do and say)...

Do this once or twice, when the mortals complain and stumble over the same things every one in the company did designers get the memo pretty quick.

That is exactly what I did (50 people).

The designer thinks I'm a big ol' meanie with control issues (they're right), but they do listen to feedback.

That's why I have been running such a long beta test. The others wanted to ship, six months ago.

> My experience is that designers want users to admire the UI, as opposed to use it.

This is a biased generalization, like "engineers are nerds that don't like to interact with other people." Which is wrong.

I work as head of UX, and my career path started in computer science, and I became more interested in user interfaces.

Today's UI results from the legacy of designers from diverse backgrounds (like Alan Cooper, Brendan Laurel, Larry Tesler, Donald Norman, Maeda, and many anonymous ones who worked on successful products).

No matter what the background is, most designers care about usability.

But where does the prejudice of "designers only care about visuals" come from?

Many founders, CEOs, CTOs, etc; the people defining a product don't have a background in product design. That influences the hiring and company structure.

When you hire a designer only by its visual portfolio or outsource a crucial part of your product experience to an agency with the mandate of "make it look pretty." That's what you get: a pretty-looking but shallow UI. You can see that on Behance and Dribble: most of the designs are nice-looking dashboards that are useless. The intention is to show the visuals because understanding user needs and defining the information architecture is unattractive (and takes more time).

The core of the problem is what we understand by design.

If you want to create a good product, design is the result of the work of many people. It includes testing ideas, re-working things that don't work well, and interacting with many roles in the company to understand the business and the technical constraints. It requires a lot of collaboration. People like Steve Jobs are often praised because doing those things requires leaders who see that as a priority. But that's rare. Most leaders would love top-notch product experiences but underestimate the work needed.

If you see design only as the result that a designer handed you in Figma to enter into a mini-waterfall process, then yes, the result is probably a UI designed to be admired and not used. Because that's the output, your organization asks for the designer role.

Fair point.

I apologize for the apparent generalization, and appreciate the reply.

However, it has been quite common.

Back in the day, my company worked with Pentagram for visual design, and DDO, for interaction.

We found that we could not get a single entity to deliver a comprehensive solution.

But, as a bit of a riposte, I did say "It has been my experience." It wasn't a generalization. It was a report of 30 years' worth of experience.

You are forgiven, no worries. :)

My extended response is because this is something that I see very often. The blame is put on "the designers" (in the abstract), but it is deeper than that.

> We found that we could not get a single entity to deliver a comprehensive solution.

I can relate to that. But the problem is more than just the designers. It's a mixture of things. A comprehensive solution should include a comprehensive approach. That's the hard part.

It's hard to prioritize as a designer when user experience is not a priority. Take, for example, "undo". Every usability guideline will recommend you have an undo (a "trash" area in an email UI is an undo, too).

But having that functionality is an architectural decision (like most UX decisions). You can design that without issues if the whole team is on board. But when "design" is merely the "V" in MVC terms, there is a strong push for showing a visual confirmation: easier to develop and design.

When an agency does the design, you also have a monetary incentive: it's better for the agency to hand off the nice-looking design rather than enter into a negotiation with the engineering team about why it's essential to expend a month having the architecture to support that "undo" button.

Also, the "undo" button should be paired with principles applied across the product. You spent a month adding undo to a single part of the product, but another part doesn't have it, and instead of doing things better, it makes it worse. This piecemeal growth is also common in engineering; the difference is that most users don't see that mess. I wish to have a simple solution, but there isn't one. It requires a lot of work, from business strategy to process organization.

I really appreciate your answers!

I feel like the tech world could use many more discussions, like this.

Thanks!

> But where does the prejudice of "designers only care about visuals" come from?

This isn't prejudice, it's just observed factual reality in the world. The entire flat UI thing came about as a fashion, and had as its consequences the removal of affordances (scroll bars, buttons that were clearly buttons, etc.) You might not like that people question it, but it's nevertheless a thing that happened and is still happening.

It's also an observed factual reality that there were many terrible software development trends: XML everywhere, SOAP, microservices architectures (even if they do not apply), YAML in every config file, etc.

Every specialization has those trends, which are often copied without analysis.

I don't have any problem with questioning those trends. However, criticizing that YAML may not be the best way to build a DSL is not the same as saying that all engineers don't care about systems architecture and only use the latest framework.

> But where does the prejudice of "designers only care about visuals" come from?

Probably from modern computer UI design, where this seems like a reasonable conclusion based on how common it is for UIs to be really hard to use.

Internal business applications are going to be a lot clunkier than a publicly available web interface.

The reasons are typically:

1. They are designed for a few number of users, so they can automate an internal task. The application seems complicated and uses a lot of language specific to the domain.

2. Generally under invested in. These are great learning projects for people to do, but it also means the implementation will probably be substandard. Work arounds will be discovered for the known bugs, since the users all in the same company anyway. These projects reduce OPEX/COGS, they don't directly contribute to Sales/Revenue, so they aren't as important for the company.

I know I didn't give any examples, but this has nothing to do with funding or domain knowledge. I'm talking about people going out of their way for bad design. Like a form with a submit button that was tiny compared to a very prominent reset button, or background colors that changed jarringly on hover. These are deliberate choices in this era of LCAPs.

> I had to read The Design of Everyday Things in college and was nodding along the whole time

Same here. I started reading it twice, but quit each time, because it was telling the obvious.

Reply on news.ycombinator.com