Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Sanding UI

blog.jim-nielsen.com

Post reply on HN
Print view View original

281–290 of 414 posts

Re: Sanding UI

#281

Post by __MatrixMan__ »

swiftcoder wrote: post #276
ibash wrote: post #260

Earlier quoted context omitted.

> The customer probably notices this kind of a thing but it’s a miracle if the customer bothers to report it, and another miracle if it eventually turns into a ticket, and another miracle if someone prioritises it enough to spend time fixing it. I report a lot of bugs. But it seems like a lot of customer support people view their jobs as “protect engineers from bug reports and deflect responsibility”. That’s if you g…

In most companies customer support doesn't have any authority to retask engineers. Maybe if a customer reports a security issue, or a truly application-breaking bug. Otherwise all that customer feedback just gets rolled up into a slide deck once per quarter, and ignored

A neat quirk of having an open source saas product is that really it's customer support that's the product (after all, you can get the software for free). I think it makes for a higher percentage of tickets that are directly related to user experience--although there's still plenty of make-sales-happy type tickets too: gotta put a really shiny bezel around the open source thing.

Re: Sanding UI

#282

Post by Viliam1234 »

necovek wrote: post #131
aetherspawn wrote: post #83

This is so lost in Agile. Engineers should get the time to “sand” their products, but we just don’t. If QA doesn’t make a ticket for the space between, it’ll never get fixed. The customer probably notices this kind of a thing but it’s a miracle if the customer bothers to report it, and another miracle if it eventually turns into a ticket, and another miracle if someone prioritises it enough to spend time fixing it. […

The idea behind "agile" is to recognize when something isn't working and improve it. You obviously have a process that does not serve your customers' needs: work with your team to fix it. If you have SCRUM ceremonies, a retrospective is where you can raise it, but really, any time works (retrospectives are to purposely look at the past few weeks, but things you notice along the way, look to solve along the way).

Fun fact: most companies doing "scrum" actually don't have retrospectives.

(I understand that this goes completely against the textbook idea of scrum, but there is always the textbook and "the way we do scrum at our company", and those two often have very little in common.)

Re: Sanding UI

#283

Post by __MatrixMan__ »

Viliam1234 wrote: post #266
richardlblair wrote: post #214

Earlier quoted context omitted.

Agile isn't entirely irrelevant, it's also not the main issue. It's a cultural one. If someone tells me they work on an 'Agile Development' team my immediate perception is that they are a culture of cargo culting and bike shedding, without putting a ton of thought or care into their product, process, or users. These systems are designed to maximize output, not the quality of the output. Management is likely out of to…

Business is trying to maximize money. It seems like quality has much less of an impact on sales than many of us would wish. I am not sure why it is like that, but as long as it is... it is a financially rational decision to throw unpolished products on the market as fast as possible. It would be easy to blame the customers. But let's look in the mirror -- how do I make purchase decisions as a customer? Actually, not…

I wish users more aggressive about their software. At least once a week I hear something along the lines of:

> I'm not a technology person, so I can't make X do Y

It would be so much better if the go to response was:

> This technology sucks, so I can't make X do Y. And if it can't even manage to make Y easy, then I'm sure not going to trust it with Z, and I'm going to tell my friends that they shouldn't either.

If the business types need to be reminded that the quality problem is hurting them, then we should coordinate among ourselves to ensure that it hurts even more until they notice.

Re: Sanding UI

#284

Post by magicalhippo »

8n4vidtmkvmk wrote: post #141
crazygringo wrote: post #86

Earlier quoted context omitted.

What does agile have to do with anything? You think waterfall explicitly provided time to test out the UI and "sand" it? This is a process that generally requires a product manager to choose to prioritize, together with a capable UX engineer and/or designer. That prioritization can be inserted into any development methodology if you want it. Agile is irrelevant here.

I don't think you even need PMs and UX to be involved here. Let the eng get a little bored and they'll find stuff to fix. The way it actually works though is we set some arbitrary impossible deadline, rush to meet it, creating a wake of tech debt, launch, and then straight on to the next thing.

Even better, let the devs just watch the users use the product.

I often join support when they have a call with a customer demonstrating an issue. I also sometimes get to join support when they're on-site for training or similar.

Every time I watch users use our product, I learn so much about what to do and what not to do.

Re: Sanding UI

#285

Post by mrighele »

xyst wrote: post #80

I wonder what’s the most polished or “sanded” UI out there? You would think FAANG would have a half decent UI and UX with the amount of money they have. But anybody that has used Amazon.com or AWS, GCP, or even Azure would beg to differ. Personally, off the top of my head. The most polished UI/UX has to be “mcmaster.com”. I can find anything I need in what seems like a couple minutes. Compare this to big box stores l…

> You would think FAANG would have a half decent UI and UX with the amount of money they have.

There is no point in sanding something that someone else is using hammer and chisel on. FAANGS are the companies of continuously delivered websites, self-updating evergreen software, churners of framework-du-jour that are deprecated sooner than you can say "FAANG". Even if took the time to sand something, it would be replaced by something else the following day.

Re: Sanding UI

#286

Post by Viliam1234 »

steve_taylor wrote: post #244
youssefarizk wrote: post #216

I'm always torn whether this is a good use of time or not. If you're an early stage startup, it feels like shipping features (that work) quickly is your biggest differentiator, not how nice your UI is. I guess this is true if you're doing something in a not so saturated field, but understand that if you're in a saturated space, you probably do need the design to be natural os as to set yourself apart.

People tend to underestimate the competitive advantage of a nice UI.

Is there actually a competition where the UI could decide the winner?

I mean, it is probably very rare to have two products that have the same features, and the only difference is how nicely done they are. For example, MediaWiki is in my opinion 100x better than Confluence, but Confluence has some extra features that I don't care about but managers do (stuff like easily attaching PowerPoint presentations to web pages), so the managers decide that the company uses Confluence. And I keep silently screaming in frustration every time I lose a part of text during editing, or the links break when a typo in a page name is fixed (because there is no option to add a redirect), etc.

The extra feature often wins, when the salesman describes the product to the manager who makes the buying decision. That's why we have the "checkbox features" that most end users don't care about, but it allows the product to seem better in comparison. Feature creep is how stuff gets sold.

The situation of two featurewise identical products competing only on better UI would probably be highly unstable, even if it happened somehow. There are network effects, so if one product starts winning, most people will switch to that product because "that's what everyone else is using". The other product will be left without money to pay for development, and will go out of business. Afterwards, the winning product does not have to care about their UI anymore.

Re: Sanding UI

#287

Post by wruza »

ryandrake wrote: post #275
wruza wrote: post #250

Earlier quoted context omitted.

Yep, they used flexbox to nicely do… absolutely nothing useful beyond blogspam. Next up “how I made my ui responsive but then heroically stopped labels wrapping away from radio marks”. There’s a reason, even if accidental, why writing custom controls was sort of a black magic in traditional ui. And that reason is, most people are clueless about how fragile ui actually will be in their hands.

I guess what I learned from the article is how crazy it is that developers are still putting UIs together with text labels and padding and flexbox-this and align-that. What kind of stone age shit is this? Back in the '90s we were putting UIs together with controls already polished and perfected by the OS vendor, presumably backed by man-years of UX research from those companies. The controls themselves had styling, b…

Absolutely agree, there’s so much to lose with completed ui controls. It’s akin to the situation when you disassemble a device for the first time, then reassemble it and it’s always some parts left on the table.

Styling and customization are useful and interesting topics in ui. But instead of thinking it through, most libs today just throw a ball of wires at the developer who is clueless and often couldn’t care less even.

Re: Sanding UI

#288

Post by Vegenoid »

ibash wrote: post #260
aetherspawn wrote: post #83

This is so lost in Agile. Engineers should get the time to “sand” their products, but we just don’t. If QA doesn’t make a ticket for the space between, it’ll never get fixed. The customer probably notices this kind of a thing but it’s a miracle if the customer bothers to report it, and another miracle if it eventually turns into a ticket, and another miracle if someone prioritises it enough to spend time fixing it. […

> The customer probably notices this kind of a thing but it’s a miracle if the customer bothers to report it, and another miracle if it eventually turns into a ticket, and another miracle if someone prioritises it enough to spend time fixing it. I report a lot of bugs. But it seems like a lot of customer support people view their jobs as “protect engineers from bug reports and deflect responsibility”. That’s if you g…

I worked as a sysadmin in a large physical services company. We had in-house software that integrated with almost all levels of our operations, most employees were using this software throughout their day. The whole IT staff, including the team of ~10 devs who built and maintained this software, worked in-person on the same floor.

L1 support was constantly escalating issues that the sysadmin team could not assist with, because they had to do with this software. Either bugs, or new corner cases, or something changed, or they didn’t know how to do something.

We would tell them again and again “we cannot help with operating this software” (it was outside our scope of responsibilities and knowledge - our job was to make sure the computers, servers, and network were all functioning properly).

Despite the team of devs sitting 10 meters away, support would never, ever, talk to them. I think this was probably a dictate from management. It made no sense to me - these support staff were constantly using and helping people use this software, discovering the problems with it and the ways people wanted to use it, and all that feedback just died with them. The devs never interacted with the users of the software at all.

You can probably guess how user-friendly that software was, and how much the users liked it.

Re: Sanding UI

#290

Post by madeofpalk »

aetherspawn wrote: post #83

This is so lost in Agile. Engineers should get the time to “sand” their products, but we just don’t. If QA doesn’t make a ticket for the space between, it’ll never get fixed. The customer probably notices this kind of a thing but it’s a miracle if the customer bothers to report it, and another miracle if it eventually turns into a ticket, and another miracle if someone prioritises it enough to spend time fixing it. […

I don’t know what we’re calling “agile”, but it’s explicitly supposed to capture this. You use the product, get feedback (from either yourself or users), and iterate on it.

It sounds like you have organisational failures that prevent you from getting the feedback or iterating on it.

Post reply on HN