When users never use the features they asked for
web.eecs.utk.edu
web.eecs.utk.edu
So, somehow, It is arrived at that a website will be created that encodes MS's proprietary data, but doesn't store it, but also our algorithm is implemented server side, so there's no leakage of proprietary stuff.
A month later, the app is done and tested and I'm decoding data from the website on real hardware. I move on to the next project.
Three years later, the Xbox 360 is out, I decide I'm tired of filling out reimbursement forms for Heroku and its got to be a security risk with no updates in 3 years... so I take a look at the apps stats to see if its feasible to shut it down--exactly zero users. Nobody ever attempted to use it, not even once.
Ironically and unknown to me, the source code had been lost in a freak accident and when I deleted the Heroku account that was the only copy of the source left.
Even worse, a year later someone claimed to have a use for the app and where was it please? And I had to explain we no longer had the source. I remember a very long e-mail about how irresponsible we were.
If they were that serious about security-- the chips we made also implemented this same compression algorithm. It would have been trivial to hook one up to an arduino and feed it the data you wanted to encode. I assume someone realized this, or they never really had a need to encode their own data (we provided a extensive library of encoded data).
I strenuously disagreed with the business justification for keeping all this stuff secret. But it was my job to respect those decisions.
It was a lot of fun writing the (rails) app itself.
I was working for a place that had a service running from a Java app that was customized for each customer, about 200 copies of roughly the same app. There was source control at some point, and when a new customer was being on boarded they’d just make the customizations they required, compile the app, and deploy it.
By the time I worked there (years later), all source code had been lost, and I was tasked with creating a CI/CD system that included managing these apps (they’d now decided they needed to be maintained).
For each one I had to decompile the whole thing, rewrite the code into a human readable format, redeploy and test it. They were filled with all sorts of horrible anti-patterns too, like hard coded file paths, and some of them were only used once a year (but for an absolutely business critical process).
About half way through we had a major data center failure that meant we had to do a failover, which of course broke most of these apps with all their hard coded configuration. So instead of having months to work through all of this garbage, I was asked to get them all working immediately.
I got them all working in 3 days, which I thought was quite a monumental accomplishment. But my CEO was very dissatisfied that it took so long. I quit a couple weeks later, and still almost regret putting so much effort in to saving them. A friend of mine still works there and apparently all of these applications are in exactly the same state as I left them.
There's a certain personality type that will never appreciate or reward hard work.
But I did get a lot out of the few years I worked there, even though a lot of it sucked. It was my first proper job and they’d basically let me work on anything I wanted to, even though I was incredibly green and was just figuring it all out as I went. I definitely fit a lot more experience and learning into those years than you’d reasonably expect a person to. I think a lot of my success today came from turning their incompetence into opportunities.
Maybe this is something every junior should do - try a bit of everything and see what you like.
Plus, in my experience consulting companies are more focused in employee well-being as it's their only asset.
Now, how would someone figure out these personality types ahead of time? Any red flags to detect people or workplaces to avoid in a professional capacity?
PASS !
2. "I(boss) coded the first version..."
50% of the time it means:
Your solutions or design decision will never be "as good as his" and you will forever hear "I did it like this and that. It should be fast to implement xyz"
There's a book called "Dangerous Personalities" which takes a dive into practical psychology for these sorts of people.
Looking back on it, that likely would have been the best approach. But at the time the complexity of designing something like that was a bit beyond me.
Instead the OP fed the old version into a tool (Disassembler) which spat out terrible source code, worse than the original with no comments and bad variable names.
This was the only way to get source at all.
Then they made the disassembled source compile in a really nice way.
Finally the boss asked them to make huge changes to this horrible source with time pressure.
A lot of the work would have been roughly equivalent to trying to de-minify some JS.
With a modern IDE the task would have been a lot easier. I don’t know if Eclipse had refactoring assistance built into back then, but if it did, I’d never even heard of the idea. I was sitting on not much more than a year of programming experience at the time.
Hence why it had, and still keeps it, a Smalltalk like code navigation.
Because of that, a better approach might be to compare the byte codes of the variants first to find out in what classes the variants differ.
Then treat the different class files as source code until you need to change any of them (so, variant 1 has foo1.class, bar.class, and baz.class, variant 2 has foo.class, bar2.class and baz.class, etc). Don’t immediately try to clean up their code, but ‘just’ try to figure out what they are doing (for many of them, that, hopefully, can be done from function names)
Often there are gurus too and monks live in the caves next to the relics, trying to guard the sacred grounds and spreading the gospel.
Given the Xbox One SOC had a lot more security in mind, I could see how Microsoft was more cautious about these things. [1]
[1] https://m.youtube.com/watch?v=U7VwtOrwceo&feature=emb_title
I guess I don't mind talking about it so much-- we made a sub $1 component that could compress certain specific waveforms and play them back-- the trick was that they were highly structured, so the compressed data basically just parameterized the silicon in what might be considered to be essentially an assembly instruction-- frequency, carrier wave, data to be sent, etc. The chip then would generate the signal and you could shove it out the electromagnetic radiator of choice with a little amplification a diode and couple of resistors. The problem with these signals was they required very precise timing-- they weren't super complex, but not something a general CPU could handle-- the variability in the timing was too high.
Now yes, you could use a general purpose DAC and an amp and generate the signals, but we sold you a turnkey thing-- with 10 lines of code you could be transmitting signals and the whole thing only use a few kb of ram.
It wasn't super high tech, but our value add was high. I'd say most of the major electronics companies used our chips at one time or another.
Regarding web services, like I said, we had a library of these waveforms and that was our cash cow-- you got the chips for only a few cents over cost. You got the API that operated them for free, but access to out database cost a fair bit.
Basically what you need to build a universal remote control, or a remote control for a specific device that includes controlling capabilities for other manufacturers' devices.
If I had to take another guess, I would even nail it down on him having been employed by a company called Universal Electronics, which produced a series of universal remotes called "JP1 remotes" in hardware hacker circles (see for example http://www.hifi-remote.com/files/help/The%20WHAT%20and%20WHY...) and also acted as an OEM for a lot of other companies, so their tech could be found in various remotes of different brands.
[edit] I was slightly wrong. He was working for Zilog (which sold their universal remote business to Universal Electronics Inc. in 2009 however) and probably involved with a cool-named product called "Crimzon RC Blaster": https://www.zilog.com/docs/ir/PB0171.pdf
Edit: I was wrong about the frequency range, a sibling comment to yours mentions IR, not radio. Though, their mention of "radiator of choice" sounds like this same chip (or related chip) could be fed into an RF modulator/demodulator to build a software defined radio.
What I've learned - although I've never had a PM role - is not to blindly just give customers what they ask for, but to figure out what they really need. Their feature requests are often a proxy for something else they aren't able to articulate.
Another thing to be careful about is adding that one thing a customer asks for but nobody else does. You end up wasting cycles and bloating the product with these one-off asks. Sometimes you have to stand your ground and say "no", because the ROI just isn't there. Startups in particular are vulnerable to this because they haven't got a large enough customer base and capital yet to comfortably say "no", and end up with features jammed into the codebase that are still there, years later, when the original customer that asked for them are long gone.
There are exceptions of course - perhaps the feature is for some legal requirement e.g. "we need to show this specific set of Terms & Conditions before the user clicks Yes" they must have and can't live without.
I as a PM for a platform may sound arrogant, however I strictly adhere to the phrase: Only what customerS need, not what they want. I also rely on numbers and classification: does this feature help one or more user? Which type? Power User(s)? Everyday normal users? Is this just emotional, a want or need? How much does a user benefit from the change? Can we do better, are we missing something (symptom vs. root cause)?
Product development is incredibly hard to get it right. However, do less as a general advice. Think about Word and its feature overload. There is a downside to customer feature wants: clutter and distraction. Users of all kind are allergic to noise. Keep that in mind. I call this "friction free".
I think in systems, as a general abstraction and modules. I classify features. For example Power Users can get a special Role and Admin area where you can abstract there needs away. Their productivity is different.
I learned as a rule of thumb, that you should talk a lot to your customers and blend that with data. Data itself (usage tracking) is highly misleading.
This is hard and I aim for general satisfaction level. People who like your products tend "get" your idea and don't fight it.
Have fun! :)
It's actually worse than this - additional information and option hinders the users. It make them less able to find, understand and successfully perform otherwise easy tasks. At some point, it also make them stop use the product. Those major drawbacks are important to state to all stakeholders.
This is so true. Why is a feature unused? It could be:
* It is not needed
* Nobody can find it
* Nobody understands what it does or how it works
* The name is misleading people into thinking it's not what they want
* You left the feature flag off, the feature isn't even live
* It doesn't actually work
* It works sometimes, but frustrates users when it breaks so they don't come back
* Your data is wrong, and they do use it
* etc.
Lots of folks stop thinking at the first one.
Sales people, depending on their experience, are not a whole lot better. They'll happily sell solutions that don't yet exists for problems that the customer insists they have and then confront their company with requirements that don't make sense. Closes the deal but sets everyone up for failure.
1. Push a product (or these days, service) at people. Preferably a captive audience. In B2B, that may involve growing an "internal champion" at a customer company, preferably a manager that doesn't need the software themselves, that can be bamboozled by your sales people.
2. Don't explain how the product works or what it does to your sales people. That's techie stuff. Also, once you give your sales people the license to bullshit, it literally doesn't matter what the product does[0].
3. Don't ask your users what they want or like. They don't know what they need. Rely on thorough surveillance instead, as a good "data-driven" shop you are.
4. If some users manage to somehow deliver feedback to you, ignore it. Users don't know what they want, and can't articulate solutions.
5. If the client does not understand how the software should be used, that again means they just don't know what they want. Interfaces are designed to be intuitive. No training is ever necessary. Software manuals? That's so 1990.
6. The so-called "power users" are making point 5 harder. Ignore them with extreme prejudice. After all, them being more productive doesn't earn us more money.
It's a self-reinforcing pattern of industry-wide self-delusion. No wonder so many non-tech people hate technology.
On the "XY problem" someone mentioned in this thread: one of the biggest problems on StackOverflow and other forums, and previously on IRC, is that quite often, the person asking for X actually wants to know X, not the Y, and they especially don't want to have their sanity or competence questioned.
--
[0] - Per HG Frankfurt, bullshit is when you don't care if what you say is true or false, as the reality is orthogonal to the goal you want to accomplish.
My solution is to listen to sales and get involved in early in the sales pipeline to figure out what it is that our customers need and manage our roadmap accordingly. After the deal is closed is too late to do anything. Two things I've noticed with this is that sales people are selling what you don't have and not selling what you do have. Whenever that happens either you have the wrong product or you need to get your sales people up to speed with what the product actually is about. The worst is having features that would solve a problem that sales is simply not aware off or misunderstanding and therefore not selling to the companies they talk to.
The key thing is involving the right people throughout the sales and requirements process and closing deals that align with roadmap & product and ensuring that near future product work aligns with what our sales people need to be able to close deals.
When talking to customers, it's important to realize that the person purchasing is not going to be the person using the software typically. So there's a big risk of a he said that she said that he thinks that's what our users need summarized by the sales person as "the customer needs X, when can you deliver that". Most SAAS products sell a promise to IT managers that don't actually use the stuff directly but instead manage people that manage people that actually have to use the software. With sales in between development and all that, that's four levels of indirection.
Breaking, through that and getting to the core of the issues is important. Having people in the room that understand both the business and technical constraints as well as the actual domain and users is key.
Our usual answer for this is: What are you trying to do?™
One of the difficulties is the users don't really know what's possible, so they'll come up with ideas based on the current solution. Often if you listen to them you'll realise they're actually battling against the current solution anyway and adding more features won't help with that.
Then, and only then, does the development team actually implement the feature.
Classically called an xy problem: https://xyproblem.info/
I actually had a senior manager at a large company I once worked for tell me after we demoed a new feature that had been added for his team: "that may be what I asked for but its not what I want".
It can be hard to come up with a constructive reply to stuff like that.... :-)
Edit: We eventually found out it was pure office politics, nothing to do with what we had actually built.
I've had a boss who was very "pragmatic". Used to come up with concrete and practical solutions all the time. "We need to add a button here" or "We need an extra tab that only X can see" and so on.
Wasn't pragmatic at all, just listened to the customers, then translated their requests into what he thought would be the simplest (cheapest, fastest) to implement. While this sounds Lean, it really is a sure way to accumulate an immense mess of complexity, legacy and clutter in no time.
What we really needed was some design sessions to translate the customers' request into something that fit the product and matched a vision (or to disregard it, it that fit is not found).
One "trick/lesson" I learned from working with a "big dist system" (think scraping-jobs) with lots of clients(read unique errors) and requirements was:
Never-ever-ever do:
if(client->id=123){
//do special workaround,process,feature or magic-dance
}else{
//normal non-magic-dance,process,flow
}
The only "allowed method" for implementing such code was to add a "JobOption" to the client-config.
Thus you have:
if (client->joboptions->magic_dance){
//magic-dance-feature-workaround
You'd be surprised that over time how many clients have "similar requirements" but different combinations and just being able to do a checkbox-check on their job-config (enable magic-dance) was gold for maintenance and keeping out the spaghetti code!
It was the 'greatest of sin's in our org to write "if client->id=123"
If you're ever user facing it's a harsh but quick lesson that you can't really count on any users to follow any real pattern. Different persons latch onto different things, with adamant proponents and opponents of everything with a huge swatch of grey shades in-between. At a certain point you just need to decide when the "grey" is no longer grey for you on a particular subject and start to optimize for the part that cares while checking why the grey part isn't as interested.
A lot of conversations with clients I have are with those in the grey territory, where they don't quite know what they want but they know they want it. Often times, they're more looking for a reference architecture and something to compare their current processes/workflows to, and this usually is pretty simple to work with. Those that are proponents of a feature N are typically vocal and picky, but the feedback tends to be pretty good and the guidance is clear on how they envision it, since there's a clear workflow on their side a lot of times that they want to optimize. Opponents of feature N typically bring out the edge cases and demand a solution, and are equally, if not more vocal than the proponents.
It's really a tricky thing, and it's never really clear which is going to be "best" for users/the dev team.
Users not knowing what they want but knowing that they want it is a useful phrase.
Nobody was yelling at anyone to actually use it.
I know, that's a lot of work. But what's the point of fixing things if you never tell someone it's fixed.
and if it's not good enough to be automatic or enabled by default, then keep iterating until it is.
They're a bad way to communicate specifics because they're literally a long list of changes, most of which are boring/irrelevant to most people.
If you're releasing new features you need more ceremony. Maybe an email with targeted specifics, or at least a section on your website which highlights big important new features.
I read them religiously for software I'm passionate about as a user, and when I solo'd a product for a decade I was regularly surprised how familiar some of my customers were with mine (most often when they had dedicated IT resources or were similarly small boutique outfits themselves). I've also managed large, custom enterprise projects where subject matter experts on the other end relied on them (in addition to other channels of communication).
What drives me nuts is how some companies decided to water them down. e.g. Windows Update's long list of "security related update" where you have to google KB's to find out what they are, and another company that just always puts in "various fixes and improvements".
That begs the question: Why bother growing the application beyond the smallest set of explicit use cases? When you are the primary user AND the only use environment or input samples are written by you life is simple. The moment you must analyze something not written by you, even if this usage is only for you, the problem cases blossom. If your application refuses to solve for those cases then you need to add more features or use a different application.
Those two scenarios seem to feed each other which becomes evident by traffic or usage numbers as you pull your hair out keeping up with some hobby application.
I run an email forwarding services(https://hanami.run) basically you add your domains in and add some records.
We had this one heavy users who has like hundreds of domains. So our UI isn't design for that. Who has hundreds of domains? So they approach and asked us for a way to organize those domains into a hierarchy structure.
All good.
They are paid our highest tier ($30 per month) so we prioritize the requests and work on it.
2 days later that same user downgrade to the lowest plan and delete all of their hundred of domains...
That complicated features remain unused to nowadays...
It was also quite expensive, my employer billed them €300,000 for the work.
They accepted it.... and then didn't use it.
There was some use in the first few weeks, but then it petered off - despite this they kept paying us to manage the hosting and suuport of the system.
After a few months our manager approached them to ask if everything was Okay. Their response was to say the thought it was an amazing system, but now they realised it was way over-specced and using it was more of a burden than they expected it to be.
I suppose it was the software development equivalent of ordering the biggest thing on the menu and then regretting it.
So if a savvy writer is reading my comment, here is my hope in that it'll be picked up! :)
We delivered it under a lot of pressure from the sales team (I was in a shitty company, with few employees) and the contract was in multiple millions euros. That was literally one of our 2 or 3 customer.
We delivered. One day we eventually get paid (our customer was well known in the industry to pay only when they are forced to - yeah, shitty customer too).
The project is finished, customer is happy with what we demoed and delivered.
Then maybe a year later, we decided to add a feature to this product to be able to sell it to another client. I got pull and build this damn thing. Nothing worked. Like, nothing. The login form was broken.
Then I remember. A full year and not a single support ticket. The company owner « joking » about how our sales team used alcohol, parties and embarrassing photos to make their customer buy our software. The insane amount of pressure we had to deliver this technically hard project.
I left this company the day this popped in my head.
But meh, I left this company and I now work at a nicer company where I’m truly motivated knowing our end users enjoy using our products.
That was an episode in House of Lies where the consultants sell their idea only through blackmail.
Code review is too late for most automated analysis (at the level of: "parameter isn't validated" as seen in the screenshot), it should ideally be done as a compiler/lint check in the IDE, and at worst as a git pre-commit hook.
In most cases it's not worth sending a code review if there is automated feedback which can and should be addressed before a human sees it. It streamlines the reviews for reviewers, and gives new contributors a much better experience as they have less feedback to address, and more confidence that their code is correct.
It's so nice to be able to write a compiler/lint rule with a quick fix and then see it catch both my own mistakes, and potentially remove a concern/checkbox from the code review template
But, of course, if the decision was out of your hands, people that do that are usually the same that enable all linter rules. Neither decision makes for a good development practice.
> implaying
and
> srsbsns
to toggle it off/on.
Obviously there's cases where this is code smell, but plenty of times it isn't. It's not something that you would want to block shipping. But if you do want to ship code like this, you should do so with the reviewer(s) fully seeing where it came from, to make sure everyone agrees that's the best way.
No one has implemented a bot for us that would add such comment for use but I do think it would be a huge win.
It's possible to wire things up so that it runs when you open a merge request and notifies you via email the results.
It's not a silver bullet though.
It also has a linter plugin for vscode (and possibly other editors) that DID NOT work well, atleast the last time I checked which was before February this year. Just thought you should know, incase you decided to just use the linter.
Internal tools definitely require a close relationship with some set of users to really validate what’s being worked on. It’s just too easy for teams to make unused internal tools. The feedback loop is generally just not there initially. You really have to go and find some users. In this way it’s similar to pre-seed stage startup life.
Like when multiple users asked me to add monitor brightness dimming when the sky is covered with clouds in the Location Mode of my app for controlling monitors: Lunar (https://lunar.fyi)
Turns out cloud cover reported by weather APIs isn't a good predictor of the ambient light. The feature was so useless (and expensive because weather APIs are not cheap) that it never made it into a release.
What the users really wanted was an external ambient light sensor that they could place where they're working and have the app adjust the monitor based on that: https://lunar.fyi/sensor
Even with the high entry barrier (buy sensor parts, assemble, flash firmware) it was still more accurate and used by more people than the location based approach.
Just FYI, you can get free hourly (or 30/15 minute, I forget) cloud coverage data from the likes of EUMETSAT (and equivalent US/asian agencies).
Since then I also found Open Meteo (https://open-meteo.com/en/docs) to be a nice alternative for smaller projects.
On the flip side the by far most impactful feature I've ever added to any software in any point in my career came a couple of years later when working at the same company. It was inspired by an offhand comment by someone in a meeting, and it wasn't anything anyone had ever asked for or even really solving a problem customers claimed to be having. I'd 'coded' the feature on a piece of paper by the end of the meeting and implemented it 2 days later, mostly just to see if it would work. I quietly added it in a minor point release with only a 1 line mention in the update doc.
That feature went on to become an everyday part of most of our customers workflow, and transform how they used and interacted with our app. Nobody, least of all me, had any idea how useful our customers would find that feature.
If was to draw some conclusions, it would probably be that the successful feature made a common task a little bit easier for a lot of people in basically all use cases, while the 'failed' feature attempted to add an entirely new type of analysis/exploration to the application that it turned out people didn't need as much as they thought they might.
Everyone takes for granted how smooth their own workflow is to them, both because they're already used to it, and because they sunk effort into it to make it smooth (via learning or planning), which has probably been forgotten. So, people just take for granted that new features will maintain that acquired smoothness --- unfortunately, they usually don't.
As the author found out, most of the work in building features is often not in the "raw functionality" of the feature, but rather in making something that performs its functions while also not costing the user significant extra mental or physical effort to use.
Back in our 2000's startup, our AOLServer like application server, had something similar to what Rails Active Record brought to the world, just in Tcl.
Basically each RDMS driver had their own lowlevel Tcl bindings, and then the infrastructure code would wrap them up in the upper layers.
So sales got a very important customer, there was a caveat though, they were using Sybase SQL Server, which we didn't had any driver support.
Given that we had to deliver no matter what, a war room project was quick started to add support for Sybase SQL Server, across all layers of the product, drivers, model generation, SQL translation, the whole package.
In the meantime, the customer got talked into using Oracle as we were getting the finish touches for delivery.
When they finally got the new version, with Sybase SQL Server, requested by them as hard requirement, they decided to just keep using Oracle instead.
I guess the only benefit was that on later releases, we could share the infrastructure with Microsoft SQL Server.
For those that don't know, Microsoft SQL Server grew out of a partnership with Sybase, and the early versions were quite alike, just Microsoft version had better GUI tooling.
You have to ask them what they want to achieve. Their suggestions as to how to do it were almost always terrible: partly, they don't have the domain knowledge to know what's going to be simple and practical vs complex and nasty.
Also, they usually have a comparatively clear picture of what they want to achieve, but their notions of how best to break that into "your problem (library)" vs "our problem (app)" are often very naive - you wind up owning way too much of the problem (usually), or occasionally going in the other direction and not really getting enough context information into your library.
One place I worked at had a tool, I forget the name, that could record and report on which features and parts of the site where got used and how much. At one point we were discussing a particular bug we found and how much effort it would take to fix it. I asked my co-worker who happened to have the usage reports at her fingertips, because that was her thing, how much the feature was used. Just wanted to prioritize it. Zero. Users had never touched the screen the entire time since it was rolled out. I expressed my sympathy for the developers who worked on it because they were told it must be done, but it was an easy call to throw the bug into the WONTFIX pile.
In every org I’ve been in, we’ve had interns do these kinds of things: build big intrusive things that suck and no one uses. The problem obviously isn’t the interns. It’s the projects we give them, which are meant to be basically “throw-awayable”, and the complete lack of actual guidance and oversight.
Why are tech companies so bad at actually mentoring interns? They _should_ have had someone teaching them about user experience 101, and they completely let them flounder. How are we supposed to continue to grow and evolve as an industry if we make make every neue klasse start from scratch?
Well Monday morning, the customer assembles the first prototype and it lights on fire. Turns out there were lots of other problems and all my work was for nothing.
I learned a lot from the experience!
No way. Not for nothing! The customer did not have the added problem of late circuit boards. Even if they could not build their prototype, you did good.
There is no magic bullet, if someone has the power to make decisions, you are always at the risk of having them change course at any point in time. The only think you can do is deeply convince them it's in their interest you succeed.
I kind of feel your view is a variation on "if you built it they will come", which is true in some cases, and will wield spectacular failures in ton of other cases.
Apple did extensive research when designing their products, just not the naive/lazy kind that would be offered if they went to an established marketing firm.
This bias was also what bit them when they designed the trashcan MacPro, or the following coming to term with needing a Mac Pro at all.
AWS which ignores what people ask for until it happens to align with something AWS wants.
Microsoft which only implements what their double platinum partners program people asks for and forces everyone else to use that.
Oracle which gives people what they want and sues everyone who gets it from someplace else.
Google gives you what their algorithms determine you want. Like community support of all their products. You wanted that. They can prove that mathematically.
The worse one is this app where employees are religiously entering data into it (if the server is down even 30s, I receive logs from them not being able to input data) but nobody uses the data (I check regularly).
Before I cleaned it up, my project folder contained about 250 Visual Studio solutions. Only 20 apps are regularly used. I have come to "sense" which projects I should put serious effort and which one I can just do the minimum.
I recently started working in design after being a developer for more than a decade. Back then, planning how things should work for users felt frivolous compared to coding. Beyond that, getting working code in the editor just felt so good that I never wanted to put it off. These are the excuses I'd make to avoid really thinking about the users:
- I can clean up the interface later
- I'll figure out what features I can support when I figure out how it's going to work
- I've got a good intuitive sense of what would be most useful and how people want things to work
Obviously, solo intern projects are an edge case, but this case study perfectly illustrates the necessity of user-focused design is in software projects. All the better if you can find someone who specializes in it.
UX expertise brings:
- deep experience reasoning about the way people use things
- knowledge of many workflows, working styles, and personalities
- understanding of how much deviation users will tolerate
- familiarity with user research techniques and their shortcomings
- ability to distinguish between research signal and noise
- knowing where to dig deeper or seek more data
- understanding what needs to be prototyped vs. mocked up vs. textually described for tests, and ideally the ability to do all three
Theres often more to what a human says than face value. The key is to always be asking questions, always ask why, multiple times. Ask questions until you feel like you're on the edge of pissing someone off.
Often, a good bit of time up front can get to a few outcomes which save you a massive headache.
1) You understand the feature so well, you're ready to go and know it will be used. 2) The REAL ask was something totally different, and now you know what you need to do (nor not in some cases, sometimes its training, using the product properly/as intended etc).
You're also going to be giving the requester the space to fully explain themselves, and sometimes they can talk themselves round as well. At the end of the day everyones a winner when we ask more questions and listen.
https://simpsons.fandom.com/wiki/The_Homer
Not that all users are equal to Homer, but what they think they want and what they actually need are very different.
It's better to get more detail on the problem, then present a series of possible solutions to evaluate and iterate on.
If you give them something they never needed or asked for, but it's so obvious and simple to use, they will use the hell out if it.
> > It is a parody/exaggeration of the Edsel, a similarly disastrous automobile designed by Ford Motor Company.
Points to https://en.m.wikipedia.org/wiki/Edsel:
It has a "Design controversies" section that's very relevant to today:
> Complaints also surfaced about the taillights on 1958-model Edsel station wagons. The lenses were boomerang-shaped and placed in a reverse fashion. At a distance, they appeared as arrows pointed in the opposite direction of the turn being made. When the left turn signal flashed, its arrow shape pointed right, and vice versa
https://en.m.wikipedia.org/wiki/Edsel#/media/File%3A1958_Eds...
Why is it relevant? Related thread from 3 days ago about blinkers with the exact same design flaws , but in 2021: https://news.ycombinator.com/item?id=28661282
At least they are users asking for a feature. I've lost count the number of times where a sales guy swears up and down that he'll close the deal if we put features X, Y, and Z. The C-Suite gets hot and bothered about closing and I get overruled. Stories for X, Y, and Z get written, backlogs reprioritized, features developed. Ta da! Then what happens?
"Customer" goes dark and we never hear from them again. ::laughcry::
I realized this a while back due to the fact we had a feature on customer request, which was in release for some time. It had a bug in it, and nobody ever told us about it - which told us nobody ever used it.
And the only reason I know nobody used it is that we collect no metrics. And yea I'm working on that with the company...
This recruitment requirement skips much of the understanding of user needs, priorities, workflows, etc that came from previous rounds of exploration and testing.
The real value comes when you gather a small but roughly representative sample of users and collaborate closely with them on the development of feature(s).
For example, I recently built a ‘User Advisory Board’ to guide the development of internal tools at a large organization (using software I developed for that purpose).
This subset of users was engaged throughout the development process - collaborating with designers and engineers throughout - resulting in a finished product that was closely aligned with user needs.
I don’t have data to back this up, but I got the sense users were more satisfied with the end result because they felt they had a hand in ‘co-creating’ it (aka ‘the IKEA effect’).
OP claims they did this early on, but my comment is pointing to a larger issue I’ve witnessed that may help those reading this to avoid the issue of users not adopting features they asked for…
I even had the chutzpah to suggest the feature again some time later. Never had a problem.
Overall the study is performed a very limited time frame, with a last portion of the data analysis performed through emailing back and forth. The research scope is limited to 300+ organization, which in fact has 30000+ engineer in total. And the tool was developed without much of normal industry standard understanding, aka, introduce a code analysis tool requiring users explicitly invoking it (I think anyone who is at a typical senior level in large Corp knows that without management pushing, such change is never going to work). The mentors of the author might be full time researcher?
I am not really nitpicking or condescending. I am dismayed by the waste of time and effort on both sides.
I'll read the paper later. But I suspect it would be basically some well known facts in the dunstry...
I wish more people would heed this lesson, especially in HN comments.
Asking users what features they want is pretty much not fair - because most people don't have the skills to think through and answer that question, nor is it their job to do it. It's like asking a novel reader what they'd like to see in the next chapter. It's a cop-out with guaranteed suboptimal outcome.
Obviously product management is half art half science but in a nutshell, much better than asking an individual what features they want would be asking them - especially on a senior level - what problems they have and what keeps them up at night. Getting an understanding of that and then thinking about how those problems/risks can be addressed by your system is a much better starting point.
The reason I say that it's important to partner with your users on the senior level is the difference in perspective on the class of problems they want to tackle.
For example I used to work on a trading platform. If I went to my heaviest users and asked them what their problems were, they would probably say "I do 1000 trades a day, and I have to tweak each one manually - can you make that process faster" and maybe even have an idea of what that could look like. So let's say I did that and shaved a second off each trade handling so my user is happy cuz I saved them 16 minutes a day. Sounds like a job well done.
But if instead (or in addition) I talked to their boss, I might hear a very different story. Eg: "we do 1000 trades here every day, but 900 of them are straight forward. I wish I could automate those so trader can focus on the 100 complicated ones. But instead, he's so busy doing the 1000 trades that a lot of them get fucked up especially the complex ones."
That's a major change of perspective, from optimizing an existing workflow to optimizing the entire operation. The implementation is quite different - one is a UI optimization and the other is establishing some sort of automation capability that can be extended to all my clients over time. One may be doable with the team you have, one may require standing up a new group, etc.
At the end, the end user is happy (they get to do 10% of their previous load but this is the high value 10% they really want to focus on.) The key point is that neither the user nor their boss could tell me exactly what to build, but the high level perspective allowed me to understand their problem in a deep way and figure out a scalable solution for them and other clients.
Anyway that's just an example but yeah, your users can't tell you what to build and yeah you need a good product manager - or someone who can play that role well.
Automating a workflow is the best optimization from the users point of view.
I love this analogy.
100%, Usually early in the "project discussion" I try to boil it down to just ONE CORE PROBLEM they have.
For example: If you had a magic wand that could generate ANY SOFTWARE to SOLVE ANY problem in your business (but restricted to ONE problem). What would that problem/solution be ?
From there it's usually easier to generate a feature-list(requirements) as long as you solve the damn core problem :P
Writing this story makes all of the problems and solutions sound so obvious. Hindsight...
Let's review a few of the lessons I learned:
Keep your users in the loop, always. Do not go build in isolation.
Don't underestimate engineering challenges that you only have an external view of.
Voice your concerns to your team regularly and often. They might be to solve them far more quickly than you or they might be able to identify what will turn into a major roadblock.
Be ready to pivot.
Users say things for a reason, but there may be more to it than face value.
If you make assumptions about your users, they will find a way to surprise you.
Features will go unused if they aren't easy to use, no matter how great they are.
A user's workflow is everything. (I keep relearning this lesson...)
Users are far more clever than you think.
It definitely fueled the pursuit of multiple good (and bad) ideas during my time in Redmond.
Also, features don't have to be used (much) in order to be useful. I don't do Google Take-out on a daily basis, but still that feature existing is a signal I appreciate.
Also for the code review tool - it's a sort of "consultant issue". I work on the floor and probably overworked (and maybe stressed). Then a random person shows up with an "improvement" pretending to be of some use to me. Thanks, but you should ask me first what needs to be improved in my day-to-day job. That only causes negativity. Not sure if this was the case, but close enough.
When you don't talk to users this is what you end up with.
I can't imagine writing an academic paper for any of the projects of similar complexity and general interest that I've worked on.
You don't need peer review for everything.
I think these automated CI systems is a losing battle. It makes the build chain to complex. There is too much corner cases that gives false positives unless you keep it dead simple, like eg. enabling all warnings are errors or something in gcc.
The automatic code analysis tools. Sure they existed, but they need to fit into a workflow and get approval for use (which takes about ten years in enterprise these days).