Hacker News Reader

Comment by logicalmonster | Hacker News Reader

> Executives would sometimes take customer service shifts.

This won't happen among most companies, but I'd love to see that become a common practice with at least some high-level developers.

There's so many pain points in many customer service organizations that are easily solvable if a developer understood the frustration and waste with many customer service tasks. Nothing motivates more than having to do some annoying manual billing process that's error prone or looking up customer information by logging into 5 different systems.

Alas, Google has no customer service, so their developers shall be placed in the void until morale improves.

View on HN

This should absolutely be a thing for vertical integration developers. If you're developing cashier software for Target, you should have to use it under realistic circumstances sometimes. Same for Amazon driving software, helpdesk software, sales, etc.

When I worked for a large logistics company we’d have a few days a year where we’d go downstairs and shadow someone using our software. It was very informative. The UX people were redesigning workflow to be “easier” and less information dense and the experienced people (who worked mostly on commissions mind you) where very pissed and wanted their hot keys and their at a glance information.

It was very eye opening.

> The UX people were redesigning workflow to be “easier” and less information dense

I never really understood why they focus on these two things. They're good for rank beginners, I suppose, but once you've even approached competency, those "easier" workflows inevitably end up being a huge pain in the ass, and lower information density is actively a terrible thing.

> They're good for rank beginners, I suppose, but once you've even approached competency,

It's because you're aiming for a system where you don't need to reward the competency of long term employees and can instead just pluck random people off the street, pay them next to nothing and replace them when they quit.

> The UX people were redesigning workflow to be “easier” and less information dense and the experienced people (who worked mostly on commissions mind you) where very pissed and wanted their hot keys and their at a glance information. It was very eye opening.

Just curious. Many applications have some kind of "Settings" or "Preferences" section with some kind of App UI customization being possible. Often it's just a set of fairly simple features like picking a favorite background color for your App or being able to upload your own avatar or something.

But are there Apps out there where you can pick between say "Beginner and Expert" modes and have a radically different UI and UX depending on how experienced and comfortable you are? (Gmail sort of has a touch of that concept with the ability to either have a dense or comfortable email layout, but that's barely scratching the surface of what's possible)

PS: I realize that trying to develop, maintain, and support mobile and desktop versions of different versions of the same App would morph into a significant and unpleasant challenge, but being able to pick the type of UI might be a possible solution that pleases more types of users.

> But are there Apps out there where you can pick between say "Beginner and Expert" modes

Yes, plenty. They've never been particularly popular, because they tend to impose an "all or nothing" switch to the user: by going Expert, you're suddenly overwhelmed by loads of options you don't know and don't understand. People mostly prefer a gentler path, where you become familiar with one feature at a time when you need it particularly badly.

This, in theory, would suggest that the best approach is to morph the interface over time, making those advanced-but-useful features easier to access once discovered. But most people also hate interfaces that change, so in practice that approach doesn't work well. Maybe it will all be solved by a ML engine that looks at what you do every day and automatically serves you the features it thinks you'll want; but Microsoft kinda tried that in a bunch of places and I don't think it was particularly successful.

1) Just thinking out loud here, but some games have the most complex and information dense user interfaces you'll ever see. And sometimes they solve this problem by introducing new features in sort of a well-designed, first-class tutorial over the course of a few missions in a single-player campaign. Maybe Apps can try the same approach?

2) I can't help but think that many UI problems would be solved by Apps replacing meaningless icons with actual text labels. I can't remember what half the random symbols on software I use daily for hours means. If something is a sharing icon or a saving icon, I have no clue half the time. But simply having text labels on buttons and links everywhere would make all software a lot more explorable and understandable.

> some games have the most complex and information dense user interfaces

Completely different audiences and incentives. Gamers game because they want to; most people use apps because they have to, to get shit done and pay the rent. Gamers are motivated to inspect capabilities in order to get an advantage, to solve the gameplay puzzle, even just to kill time; people are motivated to get the hell out of apps as quickly as possible and go shopping.

I don't care about the capabilities of MS Word, I just want to type some stuff out. I don't care that Outlook can read RSS feeds, I just want to send an email. I skip every single onboarding wizard I can skip, because I honestly don't give a shit about 90% of "features" out there. If people cared about advanced features, we'd all be using Emacs.

> many UI problems would be solved by Apps replacing meaningless icons with actual text labels

I don't disagree in principle, but the reality is that text takes a lot of screen real estate, scales badly, and most people think text-heavy UIs just look ugly. We could definitely have better and more meaningful icons though; the "material" anti-skeuomorphing bullshit has inflicted a lot of damage on the credibility of UX practitioners, over the last decade. The 90s in comparison were a dream.

I don't think we really disagree on much, just having a conversation with some random points to feel out what I think about this.

1) I understand that the motivation for playing games is far different from the motivation for work. My main point is just to indicate that there's some games that basically simulate entire economies (on a planetary or even galaxy-wide scale) and a large amount of intricate detail. Using some approaches from games to display UI might help in the business world too. (and might have other benefits)

2) Text taking up more real estate than an icon can in a sense sometimes be considered a big feature rather than a bug. A big part of good UI design is picking and choosing what UI items belong on a particular screen. Icons IMO can lend themselves to bad overall practices because you can fit more junk into every single screen. If you need to fit every single possible command into one screen, the command line is the best method for that.

>The UX people were redesigning workflow to be “easier” and less information dense and the experienced people (who worked mostly on commissions mind you) where very pissed and wanted their hot keys and their at a glance information.

That doesn't necessarily mean that the UX people were wrong though. Even if their changes made the experienced people slightly slower, it could be worth it if it significantly sped up onboarding.

You only onboard someone once. In theory, that person will have to be using the system every day for years.

Why optimize for the one-time thing at the expense of the everyday use?

The math isn't straightforward. With a high enough rate of churn, there can be more onboarding work hours than post-onboarding work hours, especially if the onboarding ramp up time takes a while (as it presumably would if you only optimized for experienced use). And high rates of churn are not exactly uncommon.

Also, everybody goes through onboarding, and initial impressions have a lot of power. It's pretty easy to create a system that everyone hates just because it's a little difficult during onboarding. Social reinforcement can be stronger than reality.

(Personally, I still lean towards optimizing for experienced use, if you can do it without sacrificing the onboarding experience too much. Hotkeys that the new employee never needs to see or know about are a typical example, though I prefer a smoother ramp by mentioning the key on applicable menu items. The newbie can ignore it, the intermediate user can learn from it, the experienced user can ignore the menu.)

I suppose that the Devil's Advocate sort of counterargument is that for many startups or businesses on the bubble of survival, their most important task is for paying customers to understand the basics of their software and get hooked with a paid subscription quickly. From that perspective, it's ok if customers don't absolutely LOVE the software in a year or two, as long as they like it just enough to be paying today.

Perhaps, but I have no sympathy for companies using that business model.

> Why optimize for the one-time thing at the expense of the everyday use?

I'm not necessarily endorsing this perspective, and it depends on the specifics, but there are cases where this makes business sense. If you take a task that requires an expensive expert and make it something that an unskilled worker can do then you you can lower overall labor costs even if each user is less efficient in the new system.

It's a bit more complicated than that. Here's a great article that explains how users can be sorted into categories (from beginner to student to expert) and what each of them wants and needs.

https://breakingpoint.substack.com/p/your-three-kinds-of-cus...

It is possible to achieve both. Making an explicit choice to degrade the ability and satisfaction of experienced employees is just optimizing for staff churn.

This is a constant fight. The UI design people want a bunch of pretty white space, and the actual users want dense information. Despite people insisting they're "data driven", the design people rarely seem to appreciate the feedback.

> There's so many pain points in many customer service organizations that are easily solvable if a developer understood

AND if a developer actually has the opportunity to do something about it. Many companies overbook their developers time such that deadlines are constantly missed, where in that prioritization is their room for significant improvements to other services?

If the Engineering Manager is judged by their project throughput how does the EM feel about their reports working outside of that scope?

If there's value in Customer Service there should be a distinct team working on it and it shouldn't become a second job existing employees have to work.

100% agree, especially if it is industry specific specialty software. Seen so many applications that have processes that only make sense to the people that developed it and are at best tolerated by the users that have no other choice than to use it.

This rings so true. As a designer it's invaluable to have teammates with domain expertise—they have a much better idea about customer pain points. Honestly, they can usually articulate the problems better than customers can in interviews.

Where I work it's not uncommon for people to come into engineering through support > support engineering > software engineering. At one point our top AE decided he didn't want the stress of selling and went from AE > PM > UI Engineer. These have always been some of my favorite engineers to work with.

> Alas, Google has no customer service, so their developers shall be placed in the void until morale improves.

We had customer support for Google Fiber, and engineers could pair with a CSR to listen to calls whenever they wanted to. We were widely regarded as having excellent customer support, and of course, customers were calling us about our highest priority but most difficult to fix bugs.

Doordash devs went ballistic when they were asked to do a few PAID deliveries every month.

When i started at Shopify we had to setup a store and do some customer support. It was a great way to understand the product, especially since my role wasn't going to be customer facing at all.

If developers spent more time in sales or customer service...many of them would quit out of frustration, but some would refactor the world, also out of frustration.

Don't worry, with no customer service the customers will also be placed into a void too.

Reply on news.ycombinator.com