Most software companies ignore user behavior

Small, a few hundred, but was in a medical speciality so it was a reasonable number. In addition, that pool included all of our clinical investigators, the “thought leaders” you’d think most likely to have been consulted.

It's really difficult to understand how a large complicated appplication should be used if you have no use for it yourself. I spent most of the last twenty years workin g on design software for transformers (the electrical kind not the newly fashionabloe machine learning stuff) but I have never designed a transformer in my life. There is no way of dogfooding such a product the developers have no use for it at all.

So we do our best, observe the users, try to provide shortcuts and hints. But watching a user work is really difficult too because in a large application the users don't all use all of the application all of the time so getting a realistic picture of the whole use of the program is extremely time consuming which means expensive and the client departments just want to use it, they very often aren't interested in optimizing it.

I play games all the time and I don't want games preinstalled. And it's not just that it's a casual game like Candy Crush. I don't care if it's the latest Call of Duty or whatever you young whippersnappers play nowadays. My work PC is for work and my gaming PC is for games I choose to download. Even if it came with Minecraft I'd go and download the Java version instead for mod support.

> I imagine this is how windows gets bloated with candy crush saga

Who knows, it's possible the Windows team just watched a lot of people install Candy Crush, and decided it would be a good addition to Minesweeper/Solitaire/Hearts (and what employer wants those on their computers?).

I've also observed the problem where analysts or product managers cherry pick the data that validates their assumptions.

A "funny" example I ran into was product wanted to ship a notification that "test better" (i.e., had a higher interaction rate) in A/B testing. Some developers pointed out that the notification was likely seeing higher click-throughs because it was incredibly vague and users clicked through to figure out what it was about, and this would likely result in user frustration. Well, this insight was ignored and the notification change was shipped.

Our notification opt-out rate spiked a few weeks later.

Can we get telemetry that reports on cognitive steps for developers working on code and minimize for that?

I know there is cyclomatic complexity. Mostly you can look at a method and tell "this is a clusterfuck" without needing to break out a specialized tool. I still feel like a lot of devs don't appreciate the simple philosophy of "don't make me think."

Isn't that what Ribbons are supposed to do, raise the visibility of oft-used functions, respecting context.

>Well, mcDonalds draws maps of where their workers put their feet, and then designs the kitchens to minimize the number of steps the workers needs to take to complete their jobs.

In a completely different field (architecture, public spaces, parks) it has become common (and I find it a particularly smart approach) to create a new garden/public space/park with no "paths" and open it to the public.

And put some benches "here and there" semi-randomly.

Soon the grass will be worn out where people actually walks (i.e. people that needs to cross the park because it needs to go from point A to point B), so there you make the actual paved paths and the same goes for benches, some will have a path in the grass leading to them and some will look like never used, etc.

But when it comes to Excel (or similar software) there is a difference.

In the case of McDonalds personnel are instructed on exactly what they have to do and how exactly do it, i.e. their footsteps are their own optimization of an exactly specified chore.

In the case of the people on public parks there is no need for instructions, as people actually needs to go through the park to get from point A to point B and knows where they love to seat down.

In the case of Excel (or similar software) the issue is IMHO that most often than not the user doesn't actually know what he/she is doing, in the sense that user may (and often does) take a "wrong" or exceedingly convoluted path to get to the actual wanted result (when/if he/she actually gets to the result AND the result is actually correct).

I often deal with people that (most probably in good faith) bluffed their way in "familiarity with Office" on their resumè and never actually learned to work in Excel, the spreadsheet they make are "terrible", with material (and sometimes also conceptual) mistakes that are all fine if you are using Excel to - say - keep your monthly budget under control but that cause (big) issues if you are using it at work to manage a project expenses/production/forecasts, a bid offer or similar.

Feedback/telemetry from these users would "dumbify" the product and probably even make it much worse.

>I could go on all day.

I could too, I have seen things ...

I agree, I think doing a deep dive interview with a small set of users is better than just collecting telemetry. Ask them questions, carry on conversations, notice when they become frustrated trying to do something.

All the users could be using the right-click context menu to copy text not out of preference but instead ignorance - telemetry can tell you what's wrong but you miss out on most of the chance to tell why.

I, for one, love the ribbon...

There’s a lot of interesting history that I think this comment ignores. The office 2007 project was one of their more heavily feedback-driven initiatives; had they been paying attention the same way for Windows 8, it likely would have looked a lot more like Windows 10.

Really interesting talk: https://youtu.be/AHiNeUTgGkk

They had really good reasons for using the ribbon, not the least of which was that people weren’t finding the features they needed. That was all driven by telemetry back before it was considered the evilest of evils.

I’m amazed that you’re still bitter after 13 years. Afaict actual user preference is strongly for the ribbon, minus a very vocal minority that were bothered by the change. Office 2007 was in fact not the boon for OpenOffice that was predicted.

edit: tone, realized it came across as not as respectful as I intended

Here's a blog post from 2006 discussing how usage data statistics were used in designing the original ribbon from Office 2007: https://blogs.msdn.microsoft.com/jensenh/2006/04/11/grading-...

@contextfree: I'm not arguing with you.

@nxc18: Or you (but as for "Afaict actual user preference is strongly for the ribbon" show me the stats. All else is talk).

Both of your points are IRRELEVANT to the point I made. LMHY: "choice". Not anti-ribbon, not pro-menu.

IntelliJ IDEA has a plugin that will prompt you with the keys for commands you click. Pretty neat. Not exactly what you're saying (no compound actions). Still neat.

IntelliJ has a plugin for that. https://plugins.jetbrains.com/plugin/9792-key-promoter-x/

Interesting to hear. One thing I never understood about Excel is why the cells which have formulas don't look different than cells which contain leaf-data. That I think would make it a lot more "user-friendly".

2ndly why not allow users name their columns, why do they have to always be "A", "B", "C", .. ?

Thanks for sharing this.

Totally agree with the nowadays lack of craftsmanship. I guess it goes with the "maximum profitability" focus we got to have.

This is good stuff. Excel was (and in many ways still is) extremely well designed UI-wise (thanks for that).

In fact a lot of windows is (up to 7), and MS can be very good at UIs when they try. It's remarkable what an extraordinary amount of work went into making the interface usable without a mouse - for example, selecting something in the taskbar without a mouse:

Press ctrl-esc, press escape, press tab, then press the right arrow to move along the taskbar, the press return when you're on the one you want. It is actually logical too!

>One thing we do is look at which features are used most (and least). We make it easier to find and use the most popular features and we make rarely used features less prominent (and in some rare cases we might remove them altogether).

Well, with all due respect, this is not about making a "better" product, it is about making a product "easier to use" and possibly even "more popular" (which not necessarily are the same thing).

>We have about 30 power users who we work with continuously. Some of them are nearby, and we often go look over their shoulder and pick their brains. Some of them are in other regions where we get valuable global feedback that we wouldn't otherwise get from those regions. They get early access to new features and they get to help shape the product that they rely on for their livelihood and help us decide on what we should be working on next. It's win/win and I would recommend forming this kind of relationship with a subset of your user base if you can.

On the other hand this can be a much more productive approach, the program will "evolve" following the lead of these "power users", until it will become "almost perfect" (and more complex, and less popular because it has so many functions ...)

In other words, both approaches have their merits (and downsides), and IMHO you have a good process in having both, but ultimately it is the "common sense" applied to the choices you make for your product that may make a difference.

It's not a different topic at all. If you don't design it in from the start, it is very hard to get right later.

If you go through that site's (very long) history, you'll see their conclusions that quantitative UX research isn't useful for single projects.

For discovering features of the population, yes, quantitative research is great. But for making your software better, you are much better iterating small qualitative tests.

The point of usability testing is primarily to identify sources of roadblocks and confusion. It helps you understand where people can get stuck and why, but not the frequency.

Doing usability testing is both expensive and time consuming. It requires someone to analyze the videos and the testers are typically paid. So it's a very poor choice for creating frequency data.

Once the usability issues have been uncovered, it might make sense to look at the relevant analytics or add better tagging to get that frequency data.

No problem. I think

    table { 
      overflow-x: auto;
    }

Should do it

I'd rather not include a third party either. Then I would have to do all the GDPR work to disclose what do they get, how do they store it and so on. Ideally Apple would provide some framework to do basic functionality analytics.