Except users lie all the time. They don't know what they need or want. People are horrible at being logical about what will actually help them.
Watch them work. Watch a bunch of people work. Test and prototype changes and watch more people work. And watch them work at their desk or where ever they work.
This x1000! I took on a freelance project for a heavy machinery hauling company. They were a year into transitioning away from some customized off the shelf Enterprise scheduling and dispatch system into some custom built software by an “Enterprise” consulting company.
They were originally bringing me in to audit what the team that was building it but that pretty much changed on the day I submitted my proposal...
In the proposal I wrote to my then prospective client I allocated a couple of days of onsite interviews with “lower than management” people that would be using the system or it’s outputs, and a week of shadowing people in all roles that would be directly using the system. The project sponsor (to his credit) didn’t ask me why I would need to do that, he started laughing and exclaimed that I was the only person to ever even recommend this approach.
We ended up re-writing the proposal into multiple phases where I just interviewed and assessed, documented their current processes, provided business process workflows and suggested ways their current workflow could be optimized, irrespective of any one technological solution. A crappy process, then automated, is still crappy.
I wound up spending 6 weeks before even proposing anything that had to do with technology.
My implementation proposal was set in phases that would bring related functions to light in a way that their teams could begin using them right away and we could collect feedback and iterate while producing the next set of features as well. It was their first ‘agile’ project or contract and the fear was quelled when after the first month I had put more useful software in their dispatchers hands than the “Enterprise” team had in a year.
From day one interviews to “finished” project we spent about 6 months and that system still lives 9 years later- though it has been modernized and upgraded every so often in the intervening time, it is still one of my proudest projects even though it was one of the least “sexy” I’ve ever done.
I think one of the most valuable thing software engineers can do for themselves in some circumstances is attempt to shift perspective towards assessing projects by how many people they help and how. The most rewarding projects I can think of are the ones where a day or two after rolling them out, I'm contacted by a few employees that they affected the most and told they love it and it saves them 30-90 minutes every day, consistently.
I think it's a feeling most developers can empathize with, since we often automate boring drudge work in our own jobs and lives. Making multiple people's lives and jobs a little less monotonous and dreary, or a little more effective at their job in a way they feel and appreciate is a good feeling.
Because of the complexity and the importance of getting it right, it took her around 10-15 minutes every time she needed to use it. She, and her colleagues, are pretty much luddites so a basic calculator was their only tool.
I spent 10 minutes writing the formula in javascript, dropping it an html file, and running a few test.
She absolutely loved it, and shared it with the rest of the staff. Apparently some counsellors at another clinic heard about it and requested it as well. Someone thanked me at her Christmas staff party.
In terms of effort to build vs. hours saved and end user appreciation, I don't think I'll ever top it.
About the last point you made, how it would be great if hardware/mechanical devices could be made more like software - a few years ago I heard about "micro factories" (forgot the exact term): 3D printers for small(er) scale manufacturing. It seemed promising that soon we could be writing software to manufacture devices/products at home, in a garage, local maker "lab". If you thought of an easier mechanism to mince garlic, you could whip up a prototype in a code editor and "print out" a working prototype (or production-level device)..
I had a fantastic client. I don’t know if it’s because the rigging industry is full of “holy sh, we gotta think on our feet” situations or what, but for a seemingly “low tech” client they grasped on to an iterative and flexible approach so much better than most clients I’ve ever had from the tech industry.
Penny wise pound foolish.
To be fair, they may not _trust_ that you'll actually do a _good job_. There are so many terrible consultants out there, and clients are not very good at evaluating who's going to be good.
One has to be careful with this; often a process has "invisible benefits" such that outright removing it creates unintended consequences. For example, one industrial analyst found a way to speed up the assembly process. However, it was so efficient that the glue didn't have time to dry before the subsequent steps, damaging the product. Work-arounds were found, but it took time to iron out all the changes.
So let’s say you really want to do this bit, but you also know management is too cheap; you create a super-cheap option where you don’t do the activity, but something else also happens that management is unwilling to accept, something pretty horrible. Then you have two other packages that are actually desirable, both containing the activity; one of them should be the bells&whistles option that will look expensive. Management will discard the costly choice and the obviously-subpar one, and pick the middle tier. The skill is in not making it too obvious that is what you wanted all along - i.e. you should sound really disappointed that they didn’t pick the super-expensive version.
Do you have any tips/ideas on how can I pursue this as a career?
I also added my email to my HN profile.
That's the starting point for all the garbage enterprise apps I've ever used. Someone that has no clue what the users are doing makes a decision about how best to design an app that they don't even know how to test.
Don't ask them how to design the app. Ask them what they do with the app, then find the best way to get them where they need to go. Then let them test the first and second and third versions, and listen to their feedback without an assumption that "they just don't understand my genius".
It's important to distinguish between casual social media app users and power users spending hours of their day using an app to get their work done.
You're talking at cross-purposes.
To get a sense of how people are interacting with the software you have to watch them interact with the software. The moment you ask them a question about UX you'll begin to get low quality input that you can't trust:
* user is expressing an exaggerated desire for some esoteric feature that nobody else would use or discover
* user is repeating what they think should be decent design
* user is agreeing with a criticism they don't understand because they want to appear knowledgeable
All of those and many other problems go away when you just watch somebody use an interface.
Asking users, in addition to watching them struggle, can inform you on what they're actually trying to achieve, and what's their mental model.
"What's the most annoying part of your job with this software" (with followup questions to understand why and what they were trying to do and _why_ they were trying to do it) is better than "What feature do you want that would most make this software less annoying"?
If you watch them you see that what they mean is (dramatised!) "I open my browser, which defaults at Google, then on the Google home page I type 'bing', click on the first search result, then go back because it wasn't Bing search but something else, then read the results and find bing search engine, follow that, login to Bing, then access the app button to choose "Outlook" online, ...".
You might not be able to train them not to search for a URL, but IME users will click an "outlook email" icon on desktop or favorites/links bar; of course you need to watch them to see if they do.
Aside: browsers could fix this but the browser makers are either the SE owners or in their pockets and don't choose to.
Not necessarily dramatized... I've seen almost identical behavior in some places I've worked.
Basically: you can't take anything users say for granted. You need to actually see them work.
a plumber doesnt ask his customer how to plumb. just which pipes need fixin! doesn't go fix the toilet if the shower is broken :S
In that case the plumber could and should ask where the sink is going, even if he was only told to move the toilet.
Why? Because maybe the sewage line is over there and about to be covered over with concrete and they’ll have to tear up all of that to move it in two weeks, but the sink hadn’t arrived yet so no one told him that would move either.
The point is not that the plumber is asking his customer how he should do his job, but that he can be more valuable if told the whole scope and impact of his job.
Similarly you can’t just ask a user “how could this screen work better”, you need to watch them work so that you see that that screen isn’t even the problem - they’re clicking off of it 15 times every call - but you didn’t even know to ask about the other page.
Why would you ask that anyway? You've already assumed the problem and solution at that point.
You ask how it's going, very generally and let the conversation lead you to their pain points.
You don't ask about the UI, which they are not an authority on. You ask about their subjective experience, which they are.
A few months ago I heard a talk by the chief product manager at a photo album printing company where he talked about an in-depth series of customer interviews they'd recently conducted.
His advice was to keep asking why until you get to the root of why someone did something. However, if the answer you reach 'Because I don't want to die alone', then you've gone too far...
Also, 5 is just the "suggested" number. More or less may be needed. If you reach 'Because I don't want to die alone' in 3 whys, probably no need to try for 5...
But yes, watching them work is invaluable. First time I visited one of our clients, I noticed two issues that I had no idea of:
1. All users had dual-monitors, and maximized our application across both. Our application is MDI still. This was a very bad fit for dialogs that were (for historical reasons) had the default position set to center-of-application, rather than center-of-screen. Try reading a dialog split right across two monitors. So when I got back I immediately did a pass to make them all center-of-screen.
2. When doing the main data entry, they didn't look a the window they were entering data into, but rather the source material. Thus any additional controls or dialog would mess up their workflow big-time. That's when it really hit me why the user interface for that window was rather clunky...
Recently, I actually forgot to make a whole series of changes on a dashboard that were requested. They hated the old version .... but I didn't change it before the next meeting ... and then they loved it at the recent meeting. It was the same one they hated on.
Sometimes you also just have to let them get used to it too ;)
It's an iterative process no doubt, but as a dev... I'm no better at knowing what I'll do too. Iv'e worked something up and weeks later changed it completely after I've used it.
But in all seriousness, this is a good point. In addition, you have to think about the user you are listening to. Are they smart? What terminology do they know that other users don't? Maybe they figured out a workaround to some problematic UI already, and you can just make that workaround global.
That's a bit harsh. IMHO people don't know what's even possible, so they can't tell you what the solution is. Sometimes they can tell you what bothers them about what they've got even if they don't know what would be better. The rest of your comment it good though. Watch them. Look for things that look hard or redundant. Ask if they ever get tired of X, what gets in the way, etc... But don't necessarily expect them to tell you how to make it better.
I like to say users don't have requirements. They have problems.
Best to watch a few at all levels of seniority, if at all possible, to fully understand how to deliver what they might need. Then dig into the issues, shortcuts and timesavers or bottlenecks they currently have.
Yes, you can't just "ask". But there are certainly ways to learn. Doing a major UX redesign without doing any UX research seems like asking for trouble -- and I don't trust the conclusions drawn from the outcome, still without being based on UX research, either.
Ask things to your users, and then listen to them! Watch them when they show you things, watch them when they work, watch their emotions to see what they like and don't.
Asking them to describe the problems they have and doing exactly what they say will fix those problems are two very different things. The difficult, but critical, step here is to decipher what root problem should be fixed given the feedback users have given you. Sometimes the right thing to change is something the user never would have thought of to ask for, but can be figured out from what they did ask for.
Remember, your users (usually) aren't UX designers, they just know where they get frustrated.
Of course they don't always know. That's why you have to do proper user research. You should not just build what they are asking: you should try to figure out why they are asking for a particular solution, try to find patterns among all the users, find the actual source of the problem and then propose a solution that could work for them. This is, of course, an over-simplification. Like I said in another reply, work with a PM that's really good at user research (like scientifically-good).
That is fundamentally a human problem and I'm not sure what technology can really do to significantly improve the solution which is to slog through it and listen to feedback.
If they're so deluded about what they want what makes you think you can see through that and find a solution more clearly than they can?
Good design is a cross-disciplinary activity, mixing the domain knowledge in users' heads with the design knowledge in the heads of developers/designers. This is hard to do well, with few hard-and-fast rules, but it often benefits from collaboration.
There are often big a-ha! wins when you're watching a user and ask a question like "why did you do that that way?" or "what if I redesigned it like this?" Users often can't ask those questions because they're focused on doing their job rather than the meta-job of improving it. They often don't realize what's possible.
That's no excuse for ignoring their suggestions, and unfortunately many users have been specifically discouraged from thinking how to improve their own experiences by developers who were lazy, incompetent, or merely bureaucracy-laden. But fostering a collaborative environment, where developers learn something about the domain and users learn something about how their tools are created, can lead to much better user experiences than either could do alone.
It also happens that people only take their own needs into account and not those of the other users they're indirectly interacting with via the app. They'll tell you that certain app objects should have certain constraints, that certain things should be impossible, and that such assumptions can be used as foundations for other features. Then you go visit another user and they'll tell you very plausible conditions under which those things should be possible and even required. Talking to users is good, but you also need to observe them as a group and sometimes weigh their needs against each other.
When asked what they want, they present the ideas they believe will reduce pains or increase the pleasure of using the software.
It's up to you to 1. Determine if the idea reduces pain, increases pleasure or both. 2. Test whether the hypotheses are correct.
Rephrased: Users come up with untested ideas
The asking should be user interviews and contextual inquiry to understand their problems. What are they trying to solve? We shouldn't be asking them to design our products for us, because users often don't know what they want or what they even do. This should typically come very early in the process as foundational work.
Observing people both working and in a usability testing setting will help us learn what is and isn't working. As we get into the prototyping stage, it should be a lot more observing and testing.
I think what you are responding to is this idea that all we need to do is just talk to our users, and you are correct, that is very wrong. Just asking users what they want is a good way to give them something they won't use.
When we do ask people questions, they need to be done in a methodical and probing way.
> Except users lie all the time...
Users who have "skin the game", who actually have to use the application usually have valuable observations and suggestions. Does it mean that you should uncritically implement what they ask for verbatim? No, but sometimes the insight is right in front of you if you're receptive to it.
So ASK, but do not ask direct questions (e.g., what do you want?).
Instead, ask what are their problems, their pain points, and what items they rely on most.
And OBSERVE -- watch what they actually do. What items they most rely upon (i.e., do NOT change that stuff if you can avoid it).
These answers & observations can then form the basis of your solution, which should relentlessly focus on their needs (and not your own design conceits).
Story from a friend who wrote & sold software into IT shops: When he asked "Do you like these features and would you buy this software?", he got all kinds of "Yes" answers, would write the package, and find few buyers.
When he switched to asking (basically) "What are your pain points, what is aggravating, time consuming, etc?", then writing software to address those issues, he got plenty of sales and happy customers.
It's the indirect question that matters.
But resist the urge to do a general facelift or reorganization just for cosmetics. Users can fly through the ugliest interfaces, even text-mode terminal interfaces, once they get used to them. Change that at all, and they will be stumbling around and complaining. That can be worth in the end if their usual workflows are now shorter and faster, but tread carefully. Users of enterprise apps really don't care too much about how they look.
Exactly. It's your job to see that, for example, people spend lots of time manually doing X in Excel, and design a tool to do it for them.
You need to ask/provide a way for users to tell you what they want (fixing or features).
And you also need to observe users using the product.
- the boss of the boss of the representative of the customer company
- the boss of the representative of the customer company
- the representative of the customer company
- my line manager's boss
- my project manager's boss
- my line manager
- my project manager
- me and my team
- the user
Any of these people might of might not have been ever in contact with the elusive "user".
Yes, we know, THE DESIGN IS BROKEN.
And then, nothing. New features come out though, most of which aren't needed or deprecate features that we actually like. So I'm sure some Project Manager is being paid handsomely.
When I say 'works as designed', what I'm actually saying is that I didn't have control over the design, go talk to the ones who did.
When shit's broken I want to at least be able to go in there and fix it myself, not email some support vendor who's just going to ignore it.
When I was working on a reimplementation of an existing web app I had several team members watch how users were using the application. A mixture of sitting next to them and quietly watching (not interrupting their workflow) and remote watching via shared desktop (which we also recorded to refer to later).
Watching (in person and remotely) was without question more valuable. We could go back and replay what they were doing and why (we had copies of the worksheet they were working from for each use). Without it we wouldn't have delivered about 30% of what they were looking for and would have had to redo a load of work compared to if we had just gone by how they said they were using the system.
The new system rolled out and we had a total of two post-launch changes to make. Both of which were very simple changes. So don't just ask but watch how the users who use the system actually use it.
I think the proper thing here is for the purse string holders to defer to the views/feedback of the every day users.
The article has an example of customer records where the name fields are merged, same with the address fields. I know that would be hell for my friends in customer service wanting to find a customer by postcode or just their first or last name. Sometimes people are insistent they have complained before and you have ignored them, or you get scam artists. In these scenarios the team have to do detective work and they rely on having a decent sortable grid of customer records so they can find what they want if given incomplete information. Incomplete information comes from telephone messages made by cover staff, poor quality handwriting and a multitude of other sources. Since the staff stare at the same screen all day they know their way around it and simplifying the layout helps nobody.
Even in terms of the "recommendations" in the article, I can see all sorts of red flags. Group addresses? What if I needed to see what state it is at a glance? Now the state alignment is off. Or if I needed to sort by state?
All of this could have been avoided by sitting down with users of the existing system, watch how they interact, and then put together a revised version, and watch how they interact/where they have trouble/etc before doing a wide release.
The fact that user testing wasn't done, especially on an internal application where the users are right there available for it, is the real story here.
The problem is, the arrogance of the designer. Who would ever redo something without talking to the user?
Even though it was pretty high end stuff.... everyone hates technical support and I found that generally companies eventually devalue it as time goes on. I got tired of that system.
I got paid really well but just got tired of seeing the atmosphere at company after company get more negative. Poor management trotted in, just coasting, incapable of making changes and such. Despite bringing in massive $$$ in support contracts... that money was never directed to support and things just degrade over time.
Then companies would outsource to some garbage company and the support there would be terrible so I and others would take the brunt of angry customers. Then someone would roll out metrics that show those folks overseas who just close cases are doing great because ... they just close cases without solving the issue.
The bad stuff just snowballs and there is no going back no matter how valuable you are in support.
When I was in support I worked closely with the engineering teams who wrote the code and who really liked how I worked (they'd ask that difficult cases be transferred to me because they know I'd document things, actually troubleshot, be honest if I don't know). They actually picked me at one point to be able to fast track issues that I saw straight to engineering and they'd pick up the phone immediately, because if I told them "you're gonna see this soon (either from a VP or something) because it is bad, you want to get a head start on it" they knew it was real. So I was already curious about coding in some form.
I wanted to do something new, got laid off after an acquisition, got a severance, and went the bootcamp route. I like making things now and web development is fun for me, I find that "troubleshooting" and "debugging" and such are all the same thing and that has served me well as well as the ability to work independently and learn independently.
We've all got bad metrics stories, but wanted to share this one.
Friend at megacorp was doing JS work, and working with the offshore team in India (few people in the US, and 3-4x as many in India IIRC). India team was "killing it" because of all the issues closed, and the US team was getting crap because they "took forever".
One of the mandates was "when you commit code, you need to have a test for it". Friend checked out the offshored code, ran the tests, and ... they failed. Almost all - a few worked by accident, but they were failing tests. Actually, when he first ran the test suite, his whole system locked up and crashed - the test suite runner couldn't deal with that many failures (that was my impression based on the symptoms and repeatability).
The 'defense', such as it was, was that no one had instructed anyone that the tests should actually be run or pass, just that test files needed to be committed with regular code. So they'd write empty tests, or copy/paste code from other tests. The line count and 'closed issues' were both great - so much better than the US counterparts. It's just that... literally... nothing was actually being tested. Budgets were cut and he and a bunch of other folks didn't have their contract renewed - they put more money in to the offshore team. :/
Which is really the only way to develop if you want anything to get done.
Everything is a "problem", and the executives at the company, often feel that way about support itself.
Everyone values support when they talk about it... don't want to actually pay for it.
>Are there things my users really don’t need to see right now? If you don’t know, ask!
ASK! ASK! ASK!
For the love of god please ask your users. I worked for a company with a big clunky enterprise app. It got redesigned numerous times and rolled out with big fanfare.
Nobody who used for any significant amount of time was involved in any of the redesigns. It was horrible every time with numerous changes just to get it not to be a huge pain point.... and then a new overhaul would come again.
I changed jobs to web development recently and really the first questions are to define the problems we're solving, and find out from folks using it day to day what their pain points are and how they work. I'll make some mvp type stuff for say a given function and then show them and get more feedback, the important thing is to get it from the end user, not their boss, not their VP, but the end user (boss and VP have to be involved too of course, just in other ways, distract them with fun control panels and such....).
I ended up working for a very small company, handful of people, me and one senior programmer, the product doesn't dominate the market but time and again customers just love that we call, ask, and do stuff and don't dictate how they work (within reason).
You can still make things clean, but when removing things you have to ask, communicate, you'd be surprised how much you can change if it is part of a conversation, and how little you can change if you just force it on them.