
Focus on the high-expectation customer - skilled
https://uxdesign.cc/stop-designing-products-for-random-people-4734423cbfe6
======
nnq
Hallelujah! Maybe this will put a dent in the current _dumbification_ trend of
all apps/UIs etc. that's probably due to 'designing for the lowest common
denominator'.

Hint: _any app /tool/etc. that's "designed for the average user", will only
help its user be(come) average and below average!_

Now try imagining selling a product with the slogan _" XYZ - Helping you stay
mediocre, and even drop below the average! Use us every day, keep greatness
away!_ ...if you're doing data-driven-product-design targeting the "average
user", you're building just such a product!

~~~
gtirloni
That was my initial gut feeling as well but high-expectation doesn't
necessarily mean "more features" or "more customization". It could mean
"simply works without much trouble" and then the dumbification trend fits
perfectly.

~~~
vinceguidry
The article was pretty specific about what it meant. She meant 1) someone who
benefited from the solution 2) already had a hacked-together solution, and 3)
had other people looking up to them in their field.

------
asdfman123
Funny story. My dad was a city planner for a small town who also ran the
inspections department.

He would get frequent letters and calls from a particular citizen about
inspection violations, who was kind of a pain in his ass.

So my dad hired him. And he became the best inspector he'd ever worked with.

~~~
bluetwo
I like working with people with high expectations because you learn the most
from them but you can't let them dictate your self-worth.

------
arvidkahl
It's also important to note that the high-expectation customer is not the
high-frequency complainer that you will have in your customer base. Don't
confuse the two, they are opposites.

In my experience with my own company, there were customers who would reach out
very often with ideas, complaints, and questions.

I learned at some point that these customers often were just confused did not
even really understand their own problems. Figuring out a solution to help
someone in that position is a very ineffective way to think about the product.

In terms of the model presented by the article, those vocal customers often
lacked the hacker spirit, they benefitted marginally and were never considered
experts in their field.

Took me a while to understand that the volume of feedback is not correlated
with meaningful gains of information.

~~~
playpause
For this reason, I'm not sure "high-expectation customer" is a good term.

It also doesn't capture this part well: "someone who will benefit the most
from your product, whether they realise this yet or not". If they don't
realise it, their expectations are zero.

Maybe 'high potential benefit' would be a better term ("HPB customers").

~~~
phkahler
I would say "high performance customer". The one that is going to push your
product to its limits, trying to make it do more than you thought it could.
Those limits are where you need to add features so people don't have to hack
around the limitations.

~~~
balfirevic
So, "power customer" (analogous to power user)?

~~~
arvidkahl
I would invoke the "skin in the game" metaphor. Listen to customers who have a
vested interest, for their own reasons (brand building, networking, the
"expert" part) as well as for optimizing some part of their professional
workflow, making your service a catalyst of their moneymaking abilities (the
benefitter part). The hacker part to me is mostly a consequence of frustration
or necessity, and that is different for every industry.

If a publicly outspoken professional uses your software, engage them. That has
been very helpful for our company every single time. It resulted in great
publicity, brand building and in almost all cases meaningful insight into the
what and why of their actual business problems.

------
javajosh
If you take this advice, you'll run straight into the famous Innovators
Dilemma
([https://en.wikipedia.org/wiki/The_Innovator%27s_Dilemma](https://en.wikipedia.org/wiki/The_Innovator%27s_Dilemma)).

And, I have personally experienced at least one counter-example to this
advice. Your product can be pushed into a direction that meets only one
person's needs, and confuses everyone else.

This is fine for a personal tool, and deadly to a tool that wants to be widely
and frequently used.

Free advice is a risk-free way to get others to test your hypothesis for you.

~~~
cjblomqvist
Either I'm greatly misinterpreting your comment, or you mean something
different than the innovators dilemma (maybe crossing the chasm?).

The innovators dilemma (and CC) refers to incumbents (established and huge)
having issues handling disruptive /revolutionary innovation (in particular low
value ones) due to issues with creating new markets due to not seeing enough
size initially, path dependency, etc. This article seems to be targeted at
startups.

~~~
bluetwo
Yes, but companies don't see that they are running into this problem unless
they get outside their own bubble.

When they keep doing what worked for them yesterday, they run into trouble.

------
josefrichter
This is actually a very narrow way of looking at users. There are plenty of
situations that the users aren't aware of their "problem" or "need". In other
words, they are not aware, that they could do something more easily,
comfortably, etc. Or maybe they are aware, but don't have a solution. These
people never fulfil the "hacker" or "expert" condition.

I would even argue, that designing primarily for anyone who could be described
as "hacker" or "expert", is a highway to hell. These people have significantly
different mind and way of using products (especially tech products), than mass
market. So picking up this particular segment is a bad choice for most (not
all) products.

~~~
ben509
> These people have significantly different mind and way of using products
> (especially tech products), than mass market.

I think the point the article is trying to make is the high-expectation
customers have or quickly find a way that definitely works for them. Whereas
the typical customer will poke at it, say it doesn't work, and move on.

From a design standpoint, you want to start with an overall system that
definitely works with some motivation and then solve the problems that block
other customers from using it.

And I think it's implicit in their argument that you won't solve these
problems for everyone who could potentially use the product, and that's a
business tradeoff you have to make.

------
deltron3030
>Once you identify your benefiter, you need to understand how your product can
help them get where they want to be.

How can you identify a benefiter of a product, without knowing the problem
that the product is going to solve (help them where they want to be)?

>hacks are temporary fixes at best. They _(the high expectation customers)_
need a single solution that meets all their demands.

This isn't true, a hack doesn't imply that it's temporary, its longevity
depends on the underlying problem and problem space. And even if they would be
temporary, quick hacks can be more flexible and make it easier to react to a
changing environment, so if that's important..

~~~
bluGill
> How can you identify a benefiter of a product, without knowing the problem
> that the product is going to solve (help them where they want to be)?

The two go hand in hand. You need to have an idea of where you want to be.
However once you find the customer willing to spend money (if you are a
business make sure they are willing to spend money!), you should chase the and
ensure they are satisfied first. Don't make them regret giving you money by
prioritizing features that they don't need over features they need. Make sure
they are satisfied first, and use their satisfaction to drive more customers
who are treated the same way.

Of course you need to be careful. If you want more than one customer you may
eventually need to do a feature your customer doesn't need because future
customers will, even at the expense of losing your one customer. This is a
complex decision that you need to consider carefully - in part because how you
treat your customer gets out and may drive away potential customers. There are
a lot of products out there with exactly one customer, one more consideration.
You need to figure out how this applies to your product yourself.

~~~
deltron3030
Wouldn't it be smarter to be the customer yourself, basically develop
something for your own (business) progress or job to be done, and then sell it
optionally to those in a similar situation?

The market first approach (developing a product for demand) only seems to
really work with more generic products without high development cost, where
the product advantages that result from deeper customer insights can't really
play out. Where you don't run the risk of being outcompeted by a company that
has those insights and customer trust from "wearing the same shoes" as their
customers.

Market first could also work if you anticipate a future demand and it's a
completely new market without any players yet, where you'd become the trusted
choice over time because you're then seen as the original brand. But without
funding it could be impossible to sustain to the point until you have enough
customers.

~~~
bluGill
Only if you are your own customer. There is a lot of need for software where
the user is not a developer, and has better things to do with their time than
write software.

------
jrochkind1
Hm. I've always thought that building for the hacker/expert is a mistake,
because it means building for someone who is willing to invest more time in
figuring out what your software can do for them and figure out your UX (and
has more skill at doing so) than many, and you're going to wind up with a UX
that less expert non-hackers find confusing and too hard to figure out, and
give up on without finding value.

The hacker/expert understands the problem domain better than most (expert),
and is willing to invest more time in figuring out how to find value in the
software (hacker) than most users. Unless you only want to target
hackers/experts (which you can if you think there are enough of them), it
seems dangerous to your UX to focus on them.

Am I wrong?

(Focus, at first anyway, on those who will get the most benefit from the
product "whether they realise this yet or not" \-- seems unproblematic good
advice to me).

------
gatestone
I have high expectations for free apps/services: They need to work immediately
without a learning curve. See "hallway testing". They need to be competent but
only modestly useful, if better alternatives are not available.

I have different high expectations for something I pay for. They need to be
marketed to me, proving to me that they solve my real life problems
competently. They can have a reasonable learning curve.

~~~
barking
You could reject some very good free apps then. But I kinda agree with you.
It's partly the phenomenon of attaching little value to something one gets for
cheap/free. And conversely, people can bend over backwards to be impressed by
something they pay a lot of money for.

~~~
GrinningFool
I think the difference is that if it's a free app[1], the developer wants me
to use it and I need to be convinced that it's worth my time.

If it's a paid app, I've already decided that it's worth money. If the app
offers enough value for me to pay, then it offers enough value for me to learn
what I need to learn.

[1] excluding open source - sure they want me to use it, but that's more like
"here it is, use it if you want it". My expectations there are very different,
particularly since I can often change things if it doesn't quite do what I
want.

------
vladojsem
Great article. When you design in that niche in your mind, it gives you a
different perspective. It is a similar approach to what feature to have in the
product is equally important to what features not to have there.

~~~
reallydontask
> It is a similar approach to what feature to have in the product is equally
> important to what features not to have there.

1000 times this. I used to work for a company that would add features if a
customer asked for them and was willing to pay for them. Needless to say the
product felt bloated, was hard to develop and maintain.

It was almost comical to see the Tech lead get incensed when a feature he'd
lovingly crafted was completely and utterly unknown to the support team
because no customer had used it, not even the customer that nominally had paid
for it.

Unfortunately, this happened more than once.

edit:

I should add that our official day rate was comically low and sometimes would
go lower to match what the sales person thought the customer would be willing
to pay while nominally making a profit, I wish I were making this up.

------
mschuster91
> You won’t just end with a product that solves real problems, you will win
> loyal customers who are vested in improving the product.

This is so true - but customers, especially the high expectations / nerd
crowd, have grown incredibly tired of the industry trend that after product
takeoff, sales/VC demand takes over and their (valuable) feedback is outright
ignored. Just look how fucked up Twitter became over the years, the latest UI
change is just another part of a string of shitload of management failures.

What this means: do not be sure this strategy will work out because customers
have learned from other startups in history.

------
nimbius
I know this is bound to get modded to oblivion but, what about customers who
want utility based on real engineers and hackers and not magic marketing
fluff. My day job is a diesel engine mechanic so im sure as shit not a
"benefiter" or a runner or any of that. I dont have any kefir cultures or
micro-greens unless somethings turned bad in the fridge.

Example: I own a ramnode VM, and it lets me do 90% of the studying and hacking
i like because the people who make it happen are probably really interested in
Linux like me. ramnode gives me space to really, really screw up a lot and
learn how to recover or learn how to push forward. I get a good back-door to
un-screw whatever it was i thought was a good idea (last week it was dd)

why not listen to the sysadmins and the SRE?

~~~
Majestic121
I'm not sure I get your point. People creating products specifically for SRE
and sysadmins definitely listen to them (or they should)

But not all products are for SRE or sysadmins (I'd venture to say most are
not), so why would people listen to SRE and sysadmins specifically if they're
not the target of the product ?

------
antisemiotic
>A gig economy worker (startup founder, ...)

That made me chuckle a bit.

------
barking
The Blog has its own domain but is actually part of Medium.com? I don't think
I've seen this before.

~~~
Nextgrid
It's quite common, and unfortunately awful given there's extra redirects (to
medium.com and then back to the custom domain) to make their auth work. This
is quite slow on a less than perfect internet connection.

------
snain
Such a strong way to think about problems and products. Way better than
segments and personas.

------
crispinb
Writers: stop being so damned bossy.

The imperative title has had its run in the fussy etiquette pieces that so
often pass as 'opinion' in newspapers. It wasn't any good there, and doesn't
merit wider adoption.

~~~
KineticLensman
> Writers: stop being so damned bossy.

Yes.

The article itself is very slightly more nuanced than its title, but it still
describes a very targeted range of user ('hipster', 'geek'), that doesn't
include 'employee' and 'tourist', for example.

> The imperative title has had its run in the fussy etiquette pieces

I agree that it is important to understand possible users, but the specific
imperative of this title is not appropriate given the range of all the
different types of possible users that developers may need to support.

