Stop Listening and Start Watching If You Want To Understand User Needs

rsmiller510 writes "It would seem on its face that simply asking your users what they need in an app would be the easiest way to build one, but it turns out it's not quite that simple. People often don't know what they want or need or they can't articulate it in a way that's useful to you. They may say I want Google or Dropbox for the enterprise, but they don't get that developers can be so much more creative than that. And the best way to understand those users' needs is to watch what they do, then use your own skills to build apps to make their working lives better or easier."

Comments

No shit?

[grasshoppa]

Sorry, but to anyone who's worked with users in any serious capacity for any length of time, this is kind of obvious. And when I say "Kind Of", I mean "blindingly".

The best way to make the tools that help your users is to understand their job. Get in there and do it yourself. Only then will you have the knowledge you need to create the tools that will really save them time.

Re:No shit?

[Fwipp]

Something something Henry Ford, something something faster horse

Re:No shit?

[bob_super]

And the worst way is to ask their boss how he thinks they're doing their job. And present the material only to him because "this is not something for the engineers to be deciding".

Did I mention I want to punch my head of marketing?

Re:No shit?

[Anonymous Coward]

The best way to make the tools that help your users is to understand their job. Get in there and do it yourself. Only then will you have the knowledge you need to create the tools that will really save them time.

Indeed.

As some of you may know there is the whole field of "usability" which deals exactly with the problem of creating usable software.

One of the key concepts is to understand the users' job by observing their job. Job observation and task analysis forms the groundwork and directs the first design you do. And by "design" I mean sketches on paper, not an implementation.

Another is iterative testing of your design. Get some representative users, ask them to perform the same scenario with your design, one-on-one. Observe and listen. Change the design. And again, by "design" I mean paper sketches or possibly low-fidelity mockups in some mildly interactive form, like a slideshow or hypertext application.

One you've done this, 80% of the design job is done. You got your functionality set nailed down. You got your design, plus the navigation order of the screens, the placement of information (and what information) for each screen. Now you got to put some colour and consistency to it, and implement it.

Sounds simple enough, doesn't it? Believe it or not, if you learn how to do this you can make good money, as a lot of software companies still struggle with this basic concept. You iterate an algorithm until it works, right? Why is it a bad idea to do the same with your feature set and UI?

Re:No shit?

[pr0fessor]

I agree... Even if it's just purchasing a solution, you really don't know what the user's needs are until you take some time to figure out what they really do. {I mean beyond the broad over view you get when you ask them}

Re:No shit?

[Areyoukiddingme]

Or to put it another way:

Domain knowledge is everything.

Which is why hiring in house and working hard at retention is tremendously valuable. Too bad no MBA-driven organization is capable of understanding that. Software a cost center? Ha. Software is the lifeblood of a modern organization. It is the thing on which ALL business processes run, from hiring to benefits to production (if any) to sales and customer service and everything in between. There's a lost generation in management who do not understand this and will never understand this. Some day the madness of outsourcing your mission critical systems to a third party who doesn't care if you live or die will be understood for the rank insanity that it is.

I keep telling myself that... I may not live long enough to see the day.

Re:No shit?

[Anonymous Coward]

I agree... Even if it's just purchasing a solution, you really don't know what the user's needs are until you take some time to figure out what they really do. {I mean beyond the broad over view you get when you ask them}

If I followed your advice I would be designing programs that alternates between showing fox news and browsing for porn with a spreadsheet simulator on a hot-key for when the boss shows up.

Re:No shit?

[ImdatS]

I don't really get it: Software is just another tool and it seems that every OTHER tool-maker in this world works exactly as described above (observe what the user does and how he does and create a tool for him/her to do it even better) and only in software we seem to ignore this insight.

Tool-development is as old as humanity; only because software-dev is such a young industry doesn't mean we should be ignoring tens-of-thousands of years of tool-development techniques.

I know out of 25+-years of experience that (a) the user doesn't know exactly what he/she needs; (b) he/she cannot really articulate his needs; (c) even if they can, they don't actually know what is possible in software so they come up with a crappy request.

Best approach so far for me was this:
1) Ask the user what they need
2) Observe them while they work
3) Come up with a proposal to do the work even better
4) Get input on the proposal: now, this is crucial: during this step, the requirements will change significantly because if I did my job right, I not only showed him how to solve his problems but also what is possible at all. He/she will then start piling on and together we usually come up with a great requirement.

During the development phase, I usually work very, very closely with the users and get a lot of feedback for each and every feature - from functionality to usability - everything. And most of the time, my users were quite happy in the end...

Re:No shit?

[bluefoxlucid]

It really depends. Talking to people is often better. In large user bases that are isolated, this is hard; but when you're doing i.e. department-to-department, you're far better off asking. If you're writing software systems for Accounting and Finance, for example, there's 200 people working there. You want to interface with the Accounting Manager and Finance Manager--who will be doing, in part, exactly what's proscribed here--while also communicating with some of the actual people in these departments. This will get you a much better understanding of requirements than just "Well I don't know a fucking thing about finance, but I watch the finance people bang their heads on this shit a lot so we should do it this way instead! It would be better!"

Re:No shit?

[bluefoxlucid]

Every good management text explains the value of retention. Even hardly-relevant stuff in Kepner-Tregoe's problem solving techniques covers this: solving human resource problems is a good thing because replacing human resources means you made a mistake when hiring someone--a fucking expensive mistake. Now you have to eat the costs of months of settling in, plus general bad productivity, plus the cost of the hiring process (expended human time), plus salary and benefits paid to a worthless employee. Sometimes the mistake is less bad: you can modify their job function and gain something valuable while retaining their organizational experience (which is pretty significant); and sometimes the mistake is elsewhere: something besides "this employee sucks" is affecting their productivity, and correcting that is far less expensive and more valuable than throwing them out and replacing them with someone else who is more tolerant of the problem.

As for promotion from within, that's a tough one. Peter's Principle says people get promoted on merit and achievement, and cease being promoted once they've reached a level where merit and achievement no longer occur--because they can't function in their newest job. Now you have engineers who think they're smarter than their managers who become managers and still behave like engineers who think they're smarter than their managers... and their engineers. Then they micro-manage like hell and piss off all the engineers, who then work to get promoted up to management because they think they're so much smarter than their managers.

Re:No shit?

[Runaway1956]

It's even worse than that. No "management" personnel worry about the future of personnel. Or, more accurately, they don't worry about future personnel. Where are the apprenticeship programs of ages gone by? Today, no matter what department, you hire some guy off the street, plug him into some narrowly defined job description, and expect him to perform. If he fails to perform, you get rid of him, and find some other guy off the street. There is no training, seniority means nothing, and no one is advanced from the labor pool. Geez, Louise - in ten years, or fifteen or twenty years, when us older folk have died off, what is the new generation going to do? Where are managers going to find people to do the necessary jobs? There are literally MILLIONS of kids sitting on their asses today, WISHING they could get a decent job, or an apprenticeship.

Domain knowledge? The kids who are being held back today might be qualified to design a new deep fat fryer for McDonalds.

Re:No shit?

[girlintraining]

Sorry, but to anyone who's worked with users in any serious capacity for any length of time, this is kind of obvious

Tell that to anyone who's had to apply for government assistance. Obvious doesn't mean it's gonna happen. It's one of mankind's oldest delusions: Believing that an enhanced understanding of a problem will lead to a solution. Think of people as having a very high static friction; Individually you can push them with a solid jolt -- like showing up a methodone clinic because your habit nearly got you killed. For the fifth time. Collectively though, they don't budge until the're an ridiculous amount of pressure behind them, in which case they finally uncork and all that potential energy that's been behind them building up blasts through them like a dam giving way. Which is very unfortunate if you live in the town at the bottom of it.

I've figured out roughly that the ratio is 3:1 -- that is, it takes at least 3 people dedicated to hammering on the poor bastard before you can overcome the average person's resistance to it. So take the number of people in a group, and the number needed to overcome the static resistance is a cube of that. Needless to say... there's a reason large bureauacracies and governments don't change... they eventually simply fail catastrophically from the pressure. You can't build up that much energy for social change and then, when the whole mass unanchors, have any hope of controlling its trajectory. It's best to just get as far a way as possible and wait for the shrapnel to stop flying. :(

Re:No shit?

[jythie]

Yeah.. this seems about as noteworthy as an article talking about how you should use classes and objects in programming or there is this hidden gem called version control. This is pretty 101 stuff.

Re:No shit?

[pigiron]

I thoroughly disagree. I've spent 40 years in software development mostly in eliminating the need for humans *completely* from the task at hand.

Re:No shit?

[icebike]

And your sales would be a lot better too.

Re:No shit?

[Anonymous Coward]

Software lives at the intersection of what the user needs and what's easiest for the developers.

The iArchitect Interface Hall of Shame is full of examples where the developers just said "fuck it," because doing it the right way was too hard.

Re:No shit?

[mcmonkey]

Something something Gemba something something Kaizen something something reason US auto manfucaturing had to play catch-up to the Japanese

Re:No shit?

[Patch86]

Yep. This is Business Analysis 101. Shadow your users, build prototypes, shadow some more. That plus traditional requirement gathering for the non-functionals. And that's not even getting into professional GUI designer territory.

Honestly, if you want a programme designed right, don't let a "developer" design it; get the right professionals in. I put that in scare quotes because there's no reason someone can't be a developer and also experienced in other disciplines (and most of the best Analysts and Designers are also/formerly developers). But you should never let someone who's only skill is coding do the design work for a commercial-grade app; it's asking someone to do somebody else's job.

Re:No shit?

[INT_QRK]

So, the idea is to derive requirements from actually analyzing users' business processes and information needs, and then design applications towards satisfying those? Wow. Who'd ever thunk...

Re:No shit?

[mcmonkey]

It really depends. Talking to people is often better. In large user bases that are isolated, this is hard; but when you're doing i.e. department-to-department, you're far better off asking. If you're writing software systems for Accounting and Finance, for example, there's 200 people working there. You want to interface with the Accounting Manager and Finance Manager--who will be doing, in part, exactly what's proscribed here--while also communicating with some of the actual people in these departments. This will get you a much better understanding of requirements than just "Well I don't know a fucking thing about finance, but I watch the finance people bang their heads on this shit a lot so we should do it this way instead! It would be better!"

What happens often with that scenario is by talking to the people in Finance, the developer ends up thinking he or she has learned something about finance, and can write up requirements which read well and will be accepted by the users, but actually has very little understanding of what the users need and will produce awful software.

There are a few reasons for this. First, every area of expertise has its jargon. Often jargon is an ordinary word with a different, specific meaning in a certain context. So better to follow someone through their work flow and know you're getting lost or not understanding some steps than to have a description you think you understand.

Second, something obvious to anyone who has even a 101 intro level of understanding in a field may be completely unexpected to someone outside of that field. When talking to the folks in Finance, there is some basic assumption so elementary they never mention because everyone in finance covered it in day one, but is completely unknown to the developer with no finance background. Talking will almost never solve this issue. They won't think to mention it; the developer won't know what question to ask.

Third, we relegate tasks to "muscle memory." When describing oft-performed tasks, people invariable miss steps. There are little things that, while vital to successful completion of the process, we forget just because we've done them so many times, they happen without conscious thought. You won't know where these are until you try to replicate results from a procedure someone has described, or if you observe that someone doing the procedure.

So for someone who doesn't know a fucking thing about finance who is developing a system to be used for finance, there's so much more to be gained by watching the finance people bang their heads than just talk to the finance people. As for the Finance Manager, talking to this person should be strictly reserved to some or all of 1) budget of the project, 2) timeline of the project, 3) availability of the finance people for requirements gathering.

Re:No shit?

[StrangeBrew]

I think this is only half of it though. I good analyst not only listens to what the user wants, but also spends a great deal of time listening to raw complaints related to what the users already have. Most low end users have no idea what they want, but they will readily tell you what's wrong with what they've got. A complaint can then be turned around into a want or need fairly easily.

Re:No shit?

[T.E.D.]

In fact, here's the same article written much better back in 2001 by Jakob Nielsen: First Rule of Usability? Don't Listen to Users

Re:No shit?

[Anonymous Coward]

As for the Finance Manager, talking to this person should be strictly reserved to some or all of 1) budget of the project, 2) timeline of the project, 3) availability of the finance people for requirements gathering.

This, especially this!
Upper level management may know what they ultimately want from a software project, but they are not the ones tasked with getting that product. Often they have no clue about how the day to day operation produces what they want (indeed, they seem to believe overpaid, lazy users just press a button and their expensive software magically does everything). The ones that have to use the software every day end up with something that can ultimately produce a pretty report, but getting accurate information into the system to do that is often a nightmare. The interface might not easily allow common tasks to be performed, the software is filled with unnecessary features that do almost, but not quite, entirely useless tasks. Tasks that should be performed in a simple sequense of steps are often spread across several modules. And so on.

Re:No shit?

[Anonymous Coward]

So, the idea is to derive requirements from actually analyzing users' business processes and information needs, and then design applications towards satisfying those? Wow. Who'd ever thunk...

Apparently management rarely "thunks". Generally they want it, they want it now, and they don't want engineers wasting time with the unwashed lower level employees.

Re:No shit?

[s.petry]

There is always at least one screw up that does everything wrong all the time, and often enough management thinks this guy is the smartest person in the world. As long as you don't use him as the model all is well. Sometimes the hard part is finding out who "that guy" is before you start a project.

Re:No shit?

[bluefoxlucid]

What happens often with that scenario is by talking to the people in Finance, the developer ends up thinking he or she has learned something about finance, and can write up requirements which read well and will be accepted by the users, but actually has very little understanding of what the users need and will produce awful software.

From the PMBOK fifth edition released January, 2013:

The Planning processes develop the project management plan [...] The complex nature of project management may require the use of repeated feedback loops for additional analysis. As more project information or characteristics are gathered and understood, additional planning will likely be required.

In other words: You should have a kick-off meeting (Initiation Processes), in which basic requirements are gathered and scope is established. This is what you've described: we talk to those guys, we find out what they need. Then you should do further planning (Planning Process). Then you should take the output of that planning back to the same stakeholders--back to Finance or whoever--and engage in further planning to clarify the scope. We know the breadth of the scope, but not the depth: we know we're writing a new Accounting System, but we haven't exactly identified all the features that belong in one in the greatest detail. Somewhere down the line when implementing the General Ledger, you'll probably have to do this again as you realize nobody has made it exactly clear how to represent Credit and Debit accounts on the same ledger (it's simple, but unless you're an accountant you will probably scratch your head on the first pass).

Stop thinking you can just have a short chat with Finance and understand what they want out of you. It doesn't work that way.

There are a few reasons for this. First, every area of expertise has its jargon. Often jargon is an ordinary word with a different, specific meaning in a certain context.

And this is why project management relies heavily on expert judgment: you need experts who understand this jargon and can interpret it for you, and make decisions on conflicting requirements by involving the stakeholders and understanding their needs and relaying your constraints back to them. Our current Director of Finance did this job for a long time: he knew how to talk to IT, and he knew how to talk to Accounting, and he knew how to talk to Finance, so when IT and Finance and Accounting all had to work together he would act as The Guy who knew wtf everyone meant and made sure everyone was on the same fucking page.

When you start exploring the scope with a Work Breakdown Structure and other tools, you start exposing requirements and the project plan in terms that are visible to everyone. This will quickly alert your stakeholders and sponsors to differences in your understanding of jargon versus their understanding of jargon. Usually. Again, you're going to want to leverage expert judgment and skilled subject matter experts who know how to communicate below their field. Yes, Finance is talking down to you; you don't know shit about finance any more than they know about computers.

Second, something obvious to anyone who has even a 101 intro level of understanding in a field may be completely unexpected to someone outside of that field. When talking to the folks in Finance, there is some basic assumption so elementary they never mention because everyone in finance covered it in day one, but is completely unknown to the developer with no finance background. Talking will almost never solve this issue. They won't think to mention it; the developer won't know what question to ask.

Yeah, I hit these all the time when doing further analysis of requirements and trying to break down work very early in the planning process. We hit holes where the developers and managers try to handwave over something they don't understand, while loo

Re: No shit?

[Anonymous Coward]

It's not that simple. Often, automated systems have a different workflow from manual systems.
I can also think of times when users don't know what they want, or how they should go about doing something.
Rather than the parent poster's "No shit Sherlock", I'd argue that it takes an indepth understanding and an ability of recognise potential where it is not obvious, unless you're talking about the most mundane task.
And yes, never ask the end user.

Re:No shit?

[Anonymous Coward]

In support of your reasoning, here is a real life scenario from a gigantic corporation. Tens or hundreds of the company's data centers located across the globe were consolidated a handful in one US state using the company's data warehousing platform. This solution was being offered commercially to other F500 businesses.

The consolidation saved the company billions and if the solution was purchased from outside it would have cost the company several million dollars annually. None of the savings were considered as revenue of my division, my division was declared running at loss and layoffs started.

Re:No shit?

[lgw]

Another is iterative testing of your design. Get some representative users, ask them to perform the same scenario with your design, one-on-one. Observe and listen. Change the design. And again, by "design" I mean paper sketches or possibly low-fidelity mockups in some mildly interactive form, like a slideshow or hypertext application.

I find that low-fidelity approach just goofy - hire some professionals. The last good UX designer I worked with could produce pixel-perfect mock-ups of changes to screens while sitting in a design meeting, about as fast as I could sketch them on the whiteboard, and as a result would sometimes point out why an idea that seemed right in a sketch would mislead the user in practice.

A previous UI coder I worked with could crank out actual UI changes (not wired to the backend but otherwise a clickable UI) almost that fast.

I've always found paper sketches or some of the "UI mock-up tools" get used when you have the PM trying to own the UI design instead of someone skilled in the technical art of usability.

Re:No shit?

[lgw]

2) Observe them while they work

If you can do this with a special build of your software, so much the better. Quantitative measures such as total time to complete a task or total distance of mouse movement to complete a task can be quite interesting, as long as you don't get carried away.

Heck, just tracking how often each feature gets used in the field (why a lot of software now has some "customer experience" program to opt-into) can be shocking. Discovering the truth behind the 20% of features that get used 80% of the time can really be an eye-opener.

Re:No shit?

[dbIII]

Spot on. The user asks for larger email message size limits, (which they already have but the intended external recipient does not), but what they really need is to be told how to save files as a PDF. Printing out a couple of hundred pages in monochrome, feeding it into a scanner a few pages at a time, scanning at 600dpi in colour, then emailing the enormous result of this to somebody comes a poor second to just exporting to PDF in the original program.

Re:No shit?

[Anonymous Coward]

Yeah.. this seems about as noteworthy as an article talking about how you should use classes and objects in programming or there is this hidden gem called version control. This is pretty 101 stuff.

Yep. And like OOP, UX is also often done badly anyway... when the developers know better... when management knows better.

Re:No shit?

[pr0fessor]

This is what I'm talking about, you still haven't met the user's needs.... it would alternate between facebook, ebay, and addicting games with a hot-key that does their job for them.

Re:No shit?

[Anonymous Coward]

100% agree. Most of the time I end up providing insights about their job that they were not aware of. Often they are wasting their time on tasks that don't need to be done, and had no idea with the actual information flow was and what their real function was in regards to that information.

Re:No shit?

[Anonymous Coward]

In an ideal, rational world companies would follow the steps you describe throughout your fine post. Unfortunately, many of us are stuck in some sort of bizarre Dilbert world. I'll just point out a flaw in one part of your post to elaborate.

...but the impact on Finance's daily workflow is such that if we pick product X they have to staff 500 people and if we pick product Y they have to staff 50. Then you find out product Y costs 5 times as much, and IT doesn't want to spend their budget on that--this is where Portfolio Managers take a look at the business' portfolio and recognize that staffing 450 extra temps to juggle shit around in Finance is going to cost a hell of a lot more, and the business decides that IT really needs a budget that big for really good reasons....

What really happens is that they pick product X, IT gets zero or at best a minimal budget increase (maybe the IT staff can all get wireless mouses (mice?) now!) and management decides Finance can have a tiny percentage of the staff increase they need (if that) and just dump the increased workload on the current staff. The staff in IT and Finance start to leave and those remaining become crazed lunatics attacking anyone who approaches in a desperate attempt to gain some information that will allow them to complete some part of their job that day.

As far as the rest of the post, each step is plagued by managers realizing they can push for something that will look good on their resumes while adding nothing that adds to productivity or helps the project succeed.

Not really new...

[Longjmp]

Don't program what they say, but what they mean.

Re:Not really new...

[Toad-san]

Yeah .. and then they say "Well, I don't know what I want .. but I don't want that!" Godz, how often have I heard that?

Re:Not really new...

[houghi]

Ironic that they use Google as an example with their Google+/Youtube stupidity.

Re:Not really new...

[BetaDays]

I got this once: "How I am I to know what I want until I can see what you can do?"

Re:Not really new...

[StripedCow]

Don't program what they say, but what they mean.

That's just a trick played by users, with the intention that they can always break the contract due to noncompliance.

What [good] Business Analysts already do?

[Anonymous Coward]

I'm a developer and I've been doing this for years.

Captain Obvious?

[CronoCloud]

IANAD (I Am Not A Developer) but isn't this Standard Operating Procedure in most software development these days?

Re:Captain Obvious?

[NMBob]

I direct you to healthcare.gov. :) In my experience there's a lot of it NOT going on. I watch my users like a hawk and learn a lot. On top of just making the program do what the user wants watching them use your software generates a lot of 'I never thought they'd do that!' and 'Why didn't they tell me that was not working!' moments. It's infinetly helpful.

Re:Captain Obvious?

[plopez]

No. SOP is to hire sales droids who sell something to the customer, vaguely define what the customer says, hand off to requirements gathers who work off of emails and conference calls, architects who have no experience in the industry the user is in who then hand off to the designers who decide the legacy system is an old musty systems and that they need to shiney new tools sets which have just reached the beta release. Then managers hire the best low bid contrators money can buy who a looking to be no more than "butts to bill". And finally QA is bolted on at the end, just as an after thought.

Hope this helps. Have a nice day.

Re:Captain Obvious?

[Ravaldy]

It's not just standard for software dev, it's standard procedure for everything that involves understanding ones job.

Unfortunately we don't always have time to see what they do or be in person for that matter. The heavy users of my applications are local but I have dealt with users in remote areas where it's just not possible to justify travelling there to see what they do. Instead you spend more time working with them over the phone and then draft up something. If the draft appears to be good you proceed with a slim down version and let them make further requests.

Re:Captain Obvious?

[Anonymous Coward]

IANAD (I Am Not A Developer) but isn't this Standard Operating Procedure in most software development these days?

Far from it. Since computers have become commonplace, it seems that everyone thinks they can design a system. I'm a programmer with over 25 years experience, and lately it seems that people think it's okay to forgo any real analysis any simply hand me pages of what they think the site/program should look like. Of course all of the buttons and all of the boxes are self-explanatory. After all, everybody uses the same formula for calculating commissions or discounts so it's not that difficult to implement, right?

It's frustrating and often the best medicine for this is to provide the user exactly what they asked for.

A real project requires real analysis, not just happy path notes. It requires real design.

Re:Captain Obvious?

[cellocgw]

I direct you to healthcare.gov. :) In my experience there's a lot of it NOT going on.

Not really a good example. healthcare.gov collapsed because of poor database and I/O management, leading to huge memory and CPU requirements for each request. The GUI itself may well be very user-friendly, but we won't know until the engines behind it are functional.

Re:Captain Obvious?

[Runaway1956]

IANAD either - but from all appearances, the answer is no. The developers develop their things in isolation, mostly. Some bright boy comes up with an idea, he sells it to marketing, marketing sells it to management, then management tells the developers what to develop. Once the finished product is ready, marketing goes out to sell it. Management buys the software with little if any input from anyone at all. The end user has zero input until he calls in to support to complain that the damned software doesn't work.

Re:Captain Obvious?

[Anonymous Coward]

Here is another explanation in comic form : Construction Project

Re:Captain Obvious?

[paulpach]

IANAD (I Am Not A Developer) but isn't this Standard Operating Procedure in most software development these days?

IAAD, Yes, this is a standard called "Usability testing". If you have the budget, you get some people to use your software and you record their face and screen, and even track their eyes if you have the equipment. Then you ask them to perform certain tasks in your application. Afterwards, you review the recordings and identify what things the user had trouble with, you change them and then ideally you test again.

While this is very standard and well known technique, it is very costly (in both time and money) reason for which not everyone does it.

I have no clue why anyone would think this article is news.

Re:Captain Obvious?

[Crudely_Indecent]

You should expand on QA - or...I will.

QA is tasked to the very butts-in-seats who were tasked with writing the application. Being lazy bastards, they don't write QA tests that test functionality in all scenarios - they write QA tests that always pass in unrealistic perfect data scenarios.

You also missed the hand-off and ongoing support contracts.

The application is then handed to the customer. Naturally, the customer accepts delivery when all of the QA tests pass with flying colors. They begin training their users on the new system - which is made more difficult because as the users gain new knowledge - they lose old knowledge. Many die after forgetting how to breathe. Those who survive begin to input data that causes errors that the QA process was meant to catch. A support ticket is opened and the process starts over again. This generates another contract to fix the bug, which makes the managers happy because they get to have more "butts to bill".

Re:Captain Obvious?

[ddtstudio]

In theory, you're right, but in practice that's so, so not the case, especially here in the SF Bay Area, which seems to be neck-deep in the "build-first" mentality of freshly minted MBAs.

Over the last year I've talked with so many startups, mostly "founders" and "entrepreneurs" with Bschool degrees, who seem to be taught that all they need is an "idea/vision". They just need to get someone to build it, because, you know, they've run the numbers and they "know the market" (actual, real-life quote from an actual situation). When I ask, "What problem does this solve, for whom, and how do you know this?", they scoff and tell me that they don't need to do any user research and besides, that'd slow things down.

Now, there may be actual pressures on startups to start building without ever observing a single potential user. Certainly if you're going to present at Y Combinator, they want to see code, a product, and tons of "confidence" (again, actual quote from actual situation). Showing them serious research on populations, data on engagement, prototypes... that'll get you laughed out.

But, side note: 75 to 90% of all startups fail. Go figure.

As a UX professional, this really grinds my bacon, six ways to Sunday. It's like seeing a kid whinge that the test was hard when you know they didn't do any of the homework. Perhaps they think that user research means months, and 100s of pages of specs (and, to be fair, it could), but I think a lot of this comes not just from stakeholder pressure but a misreading or Ries's "Lean Startup". Sure, it helps to get something in users' hands quickly, but this is based on research first. Know who your users are, what problems they face, how they think. At least an idea of it. You can rapidly prototype, GOOB, test, iterate, all within cycles of days or weeks. But you HAVE TO KNOW THE USER (who is NOT YOU) first.

There's a great example of how this can be done for $40, to save $10Million: http://vimeo.com/24749599

Re:Captain Obvious?

[Hognoxious]

In theory, you're right, but in practice that's so, so not the case, especially here in the SF Bay Area, which seems to be neck-deep in the "build-first" mentality of freshly minted MBAs.

It's harsh to blame the MBAs, to be honest. I think the "agile" movement is equally responsible.

Re:Captain Obvious?

[Anonymous Coward]

QA doesn't have much to do with testing at all. It's about making sure processes were followed, and that whatever tests were written have been run and the results logged (preferably, but optionally, by someone who isn't QA). QA will also check that the author of the tests says they're adequate, but not that they actually are.

If your QA person doesn't have a 20 point checklist that gets input by hand into a buggy Excel spreadsheet, then they're not doing their job properly.

So true

[Anonymous Coward]

Another big factor is that very often they'll be afraid to say what they really want because they don't want to be perceived as lazy. And guess what - every time and effort saving enhancement to someone's job makes them look lazy until their boss piles on more work.

No question about it, you must watch and learn.

[udachny]

When designing systems for my clients I first listen to what they are trying to convey but then I always take a trip to their locations, departments, stores, whatever it is and I just ask to be allowed to be there, to see what they are doing. Some operations are quite intricate, so I have to sit in with a user and have him/her guide me through the processes, sometimes it's enough just to observe what the operations are like to understand problems.

For example when I started building my retail chain management systems, my background in telecom / banking / insurance / manufacturing / utilities did NOT prepare me for what I observed in retail, in fact it was counter-intuitive and seemed wrong on its face. When an execute order comes to a bank, everything is done in the proper sequence, the transactionality is ensured, etc. In retail that's not the case at all. An order arrives to a store, the boxes can be checked for the products quickly and then pushed to the floor, where the items are placed on the shelves immediately and then they can be sold right away.... but the order may not be in the system yet, so this means the products are NOT in the electronic system and they can already be sold.

This means you have to be able to handle negative amounts of products, as an example, all the way from the cash registers to the accounting systems and your systems have to be able to deal with all of these weird situations, weird from POV of somebody who is used to strict transactionality in terms of processes.

Yes, you have to observe people working IRL or you'll have a bunch of preconceived notions that may be totally wrong and your systems won't handle them at all.

Re:No question about it, you must watch and learn.

[fermion]

On the flip side of this, when one talks to a user, they tend to have an idea of the ways have been done, or the way they want to do things, so you get a solution oriented meant to solve discussion instead of problem oriented discussion trying to solve a problem. However, if you watch people work then the front facing problems become evident, and one can use knowledge and skills that most users do not have to fix them.

For instance one program I am using now does a very literal translation of the physical workflow into software, much like the retail chain cited above. However my typical workflow does not, in fact, mimic the physical structure. Anyone observing what actually happens would know this, but because the software was designed from surveys and corporate structure the software is incredibly inefficient with very little flexibility.

Example this weekend

[jhumkey]

This isn't a problem of "eating your own dogfood" . . . Its not enough to use your own product. (I think) the point of the article, is that you should observe UNexperienced users and how THEY utilize (or have difficulty utilizing) the product.

I encountered the same thing this weekend using a popular "drawing" type product . . . watching the videos on the Company site, or on Youtube, made it seem easy. When I tried it for myself . . . I couldn't draw lines in an color but BLACK for TWO HOURS. The "experienced" users . . . unwittingly skipped over many basics a newbie user . . . just doesn't know.

It should almost be a "interrogation room" "through the glass" observation. So the developer can't "train" and can only see the suffering the new user experiences while trying to "find" the features they need.

For the tool I was using . . . its ultra powerful (once you know it) but . . . even the simplest features are maddeningly difficult to initially find. Easy and Powerful once found, but tortuously difficult to find.
That's the kind of "observation" I believe the article spoke of.

Re:Example this weekend

[DahGhostfacedFiddlah]

This is as good a place as any to recommend Rocket Surgery Made Easy. As someone with absolutely no knowledge of usability testing, this was a great introduction to the art.

Diy

[Anonymous Coward]

Listen to them and watch them. If you want really good app, work with them.

Also true of Sysadmins

[Anonymous Coward]

My first rule is to always ignore what the user said and go watch what action they were performing when the error happened.

Users are bad at articulating issues, because they often convey their opinion of what is wrong rather than describing the empirical event.

To be fair to users, I also suck at talking to people, which is why I fix computers for a living.

Re:Also true of Sysadmins

[sandytaru]

My favorite one in recent memory was a user complaining of the computer making a constant beep. It turned out he had a book resting on the keyboard.

Re:Also true of Sysadmins

[constpointertoconst]

I had one of these where the keyboard involved was wireless. The keyboard was haphazardly stored in a stack of junk near the computer (after the user installed a new keyboard, apparently), with the receiver still plugged in, and then books were placed on top of it.

Seeing the situation after responding to the complaint about the beeping, I immediately knew what the problem was, but it took me some time to actually find the keyboard.

Re:Also true of Sysadmins

[Anonymous Coward]

Had a user who was complaining that whenever he got up, sat down, or rubbed his hands together when standing, the cursor would jump around randomly on the screen. Turns out he had two mice, one of which was wireless and that he forgot was in his pocket, and those motions would shift it in his pocket and caused it to jump.

Re:Also true of Sysadmins

[Hognoxious]

I used to get regularly locked out for having entered too many wrong passwords. Ham fisted typist that I am, I knew I hadn't - when it doesn't work the first time I check the caps lock is on, etc.

I had two keyboards; a French one for logging in[1], and an English one for using after it had loaded my personal settings.

The problem was solved when I forgot something one evening and went back to get it and found one stacked on the other while the cleaner wiped the desk.

[1] Yes, I know you can in theory just avoid passwords with certain letters in them. But my dog is called Qwaxzo and my primary school teacher was called < £@>.

Not sure stop listening is right

[TheCarp]

I think its more about understanding needs. Don't stop at listening may be better. Listen to what they say "I want drop box" and think what does that mean?. Does it mean "I want some third party to make everything work"..... no it means they want a way to make working with files so seamless that it seems like they have a single global filesystem...without having to think about it.

I want drop box everywhere too. I don't want drop box at all because I don't want some unknown third party who does who knows what and I don't want to run somebodies proprietary code and service for anything that I rely on working...but the underlying "I don't care about the details" functionality.... absolutely, I want it too.

Re:Not sure stop listening is right

[mcmonkey]

I think its more about understanding needs. Don't stop at listening may be better. Listen to what they say "I want drop box" and think what does that mean?. Does it mean "I want some third party to make everything work"..... no it means they want a way to make working with files so seamless that it seems like they have a single global filesystem...without having to think about it.

Which is why the developer needs to stop listen and start looking. "I want a drop box" is useless as a business requirement. Even "they want a way to make working with files so seamless that it seems like they have a single global filesystem" is useless. Does the developer have the same understanding as the end user of a term like 'filesystem'?

You are right that it is about understanding needs. However for the daily tasks users perform most often, the repetitive tasks that cause the most pain, the user does not know and cannot articulate what he or she needs. This is not a slight against users.

Here's an exercise: write a procedure, as if you were verbally instructing someone, as how to tie a shoe. Don't look at your shoes! Without visual aids or string for demonstration, with just words, tell someone how to tie a shoe. Unless you've spent a lot of effort dedicated to writing detailed instructions, you are probably not going to come up with a good guide to tying shoes. Does this mean you don't know how to tie your shoes?

No, it means two things. One, some things are easier to communicate through demonstration. And two, when we repeat the same task enough times, it becomes part of "muscle memory." We go on auto-pilot and do things we don't realize we are doing.

I agree with folks saying this is not news, but I also agree with the folks saying this is not done nearly enough.

Re:Not sure stop listening is right

[defcon-11]

I think the primary goal should be too identify what problems the customer is having, not what solution they want. Observer the client and figure out their problems. It's the development companies job to figure out the best solution. When I say 'problems' I don't mean things like "I don't like that I have to use 2 screens to do y". I mean thing like "our shipping process takes too long and losses too many packages".

Medical

[Anonymous Coward]

My wife is a nurse practitioner. Anyway, she is constantly complaining about how the software's UI doesn't make any medical sense - like things she needs the most are a few screens deep and the things that she rarely needs are right on top.

Or when entering vital statistics the individual's height has to be entered every time - at least have it default to the last entry because even if you're doing pediatrics, the height may not have changed since the last visit.

Re:Medical

[fast turtle]

there's a reason for the height entry being new each and every time as a change in height either direction can indicate certain problems - a good example is a sudden gainning of 2 inches (5cm) in a very short time frame could indicate a glandular problem. Same with sudden loss of height could be an indication of spinal issues. Simply put, the fields are derived from what is a common Vital Stats Sheet (hard copy) and are god damn standardized by the Medical Profession.

On the UI screen issue, yes that should be addressed - This is where devs really do need to watch how a user works because what "You" think makes sense does not from their work flow perspective and it can make/break the use of your app.

Re:Medical

[Nadaka]

Medical software is a medical device and subject to regulation as such. I am in the business of writing that software, and while I as a developer can and would be happy to make things easy and awesome, risk management often determines that "easy" can also be "dangerous". Make the default route too easy and you risk a user accidentally skipping the correct route.

Re:Medical

[icebike]

there's a reason for the height entry being new each and every time as a change in height either direction can indicate certain problems - a good example is a sudden gainning of 2 inches (5cm) in a very short time frame could indicate a glandular problem.

Or simply a typically teenage growth spurt.

Depending on your definition of Short Time Frame, anything out of the ordinary would be noticed, and asking for a measurement to be entered on every visit is ridiculous, unless those visits are years apart.

Re:Medical

[icebike]

You could of course determine in advance what would be dangerous, but that would require you to know a little something about the subject matter you develop for, rather than being an automaton cranking out mindbogglingly monotonous and un-intuitive code.

When the people who use the system start being perceived as working FOR the system, instead of the system working for them, the first thing that happens is they start looking for shortcuts, and ways to circumvent your elaborately constructed labyrinth.

Re:Medical

[Nadaka]

The person using my software is not my customer. My customer is the patient and the FDA. If making it easier for the nurse compromises the safety of the patient, its BAD software.

Re:Medical

[ColdWetDog]

The person using my software is not my customer. My customer is the patient and the FDA. If making it easier for the nurse compromises the safety of the patient, its BAD software.

While you may think that's the right way to look at things, that attitude is what makes EHR (Electronic Healthcare Record) software just blatantly awful.

You're really quite wrong: Your customers are FDA, the vendor, the insurance companies, CMMS (Center for Medicare and Medcaid Services) and the medical provider using the software. Yep, having all of those 'customers' (stupid concept, BTW) is hard. That's why this stuff costs what it does.

But the attitude that the people using the software aren;t important (your implication) is what makes doctors and nurses really negative about EHRs).

Re:Medical

[malkavian]

Then a really useful way of doing this would be to set a default of the last height, and ask the user on entry (on a clinically agreed, configurable in database, timespan if they are sure they'd like to continue entry without re-taking height as it may be clinically useful) as a simple 'OK or Add Entry' dialog box.
Bingo, you've found a way to enhance the clinical operation of the app. Or think of something better than my purely off the top of my head idea.

Re:Medical

[malkavian]

When your bad user UI gets in the way of effective clinical care, you'll soon kinda realise that your customers are the ones who pay the bills.
If you get to streamline (correctly and safely) the job of the clinicians, you save hospitals money, and save lives both at the same time.
The patient is the client of the clinicians, not you. Your job is to enhance the clinicians' effectiveness, helping save lives that would otherwise be lost.

Re:Medical

[blakelarson]

Default to last entry? Are you serious? Just allow it to be left blank or say "not measured". No need to falsify patient data to save time.

Re:Medical

[carlcmc]

No, I disagree. As someone who has some background in computers/it/programming (programming in C and fortran for fun in college as elective classes) as well as being Physician Assistant taking care of patients, I think you are totally off track.

Your customer is your customer - the users and purchases of your software. That would be like saying that you develop POS software and the customers in the hardware store are your customers ... . You thinking you know better than the medical professional as to how the program should work for me is the same as me telling you what development language or database backend you should use.

Listen to your customers ... highly educated physicians, physician assistants, nurse practioners who are highly analytic when they tell you there are good reasons to do things certain ways.

You act like easy to use and safe for patients are contradictions ...

I contend that I have used applications that were safe for patients that were easy to use and not easy to use and vice versa.

Re:Medical

[Anonymous Coward]

I'm a different person working in this field and while your ideas are good they don't cover the entire picture. Usually the actual customer (the person making the purchasing decision) is a hospital administrator and very rarely a practicing physician. There have been times when I can clearly see a usability problem with our product but our customers refuse to change it (administration wants to track things that clinicians really don't care about). I like to think our product is as user friendly as it can be, we take it into possible sites and let the physicians themselves get their hands on it before release. We take feedback from clinicians before anything from administration and there has been a lot of work done to make sure the product can be modified on each site or even for each user. No matter what we do though our hands are often tied by both regulation and the actual purchasers.

Re:Medical

[icebike]

Not updating a field is not the same thing as falsifying data.

Do you force them to key in a new name and address and gender with each patient visit, or do you trust Joe K Sixpack is still male each time he walks in the door? And if you DON'T check his pants again, and just LEAVE the M in his file, is that Falsifying Data?

Every measurement would be dated anyway, and you simply don't update the date or the data. Its not falsification.

Re:Medical

[theshowmecanuck]

This comes down to the very well made point made earlier, watch what your end users do, determine their needs by observation and interview, and avoid or ignore most of what the administrators and managers say. That the use of the software generates data, is obvious. What the administrators want to track comes from that data. Just make sure that when the users use the system, the data the admins and managers want is also captured. It isn't that hard to make a usable system that also tracks statistics.

Re:Medical

[mattack2]

My wife is a nurse practitioner. Anyway, she is constantly complaining about how the software's UI doesn't make any medical sense - like things she needs the most are a few screens deep and the things that she rarely needs are right on top.

So, if your wife EVER has ANY connection with the company that makes that stuff, even via a salesman/marketer, she is giving them feedback about this stuff, right? Instead of just whining at you?

I know, "it shouldn't be her job", but it would make HER job better, and heck, might make the company more sales (I realize that doesn't help her, but making her job better DOES).

Re:Medical

[Hognoxious]

So how do you distinguish between "height measured, and it's the same" and "height not measured, same assumed"?

Re:Medical

[Calydor]

Height: 182 cm., 01/01/2004 on a chart written in 2013 would be a dead giveaway for 'not measured, used old data'.

Re:Medical

[__aaltlg1547]

The correct route should be decided by medical practitioners, not software designers.

Re:Medical

[Nadaka]

And it is. Every aspect of medical software is scrutinized by risk management, including medical professionals.

MS did the first cloud service before dropboxq

[alen]

i was an alpha tester back around 2008

there was no cloud storage, but you could sync files between your computers running the client. i left my home PC on and sent files while on vacation 1600 miles away. Everyone testing it said how awesome it was on MS Connect. Of course MS didn't do anything with it and dropbox was born

Re:MS did the first cloud service before dropboxq

[Anonymous Coward]

> i was an alpha tester back around 2008

And I was in early 1995. Remember Briefcase for Windows 95? It worked great and supported using a network drive or floppy as the medium. Too bad Microsoft dropped the network as a supported device before releasing 95. I had several hundred people using it by late 1996, and other than deleting nearly all of your data when the floppy ran out of space, it worked very well. My wife still uses it in Windows 7 with great success. In my opinion it's actually better than Dropbox w/ conflict management. It's too bad that Microsoft crippled what could have been Dropbox more than eighteen years ago.

Re:MS did the first cloud service before dropboxq

[Hognoxious]

Remember Briefcase for Windows 95?

It fucked up some of my college stuff by overwriting new files with old versions. Luckily I hadn't been using it for long and so, colour me pessimist, I still had manual backups.

Crock of shit.

But..

[Anonymous Coward]

Apple tells me what I need, thats the perfect scenario right?

I couldn't possible agree more

[Anonymous Coward]

...but our idiot society has no clue what Industrial Engineering is.

I am a very good program designer who has an excellent grasp of what users actually need, but I had to give up trying to work in the field as every company expects me to just write code to some absurd specification.

When is the last time you saw a carpenter design a fine building...never.

FUKEMALL

Re:I couldn't possible agree more

[Anonymous Coward]

Might help If I could spell and proofread. Oh well.

..and the penny drops

[netean]

When I did my Degree in HCI 20 years ago, this was the touted as the way to get the best results when building usable, user-centric systems. Sadly in the two decades since, I don't think I've ever come across a system - hardware, software, app, or anything else for that matter, that actually develops this way. Which is a shame because if they had, my elderly mother could have probably been able to use a PC by now, intead of "What you mean I have to move that little arrow thing All the way over there and press what?"

Side-by-side

[plopez]

There is no substitute for side-by-side. Which is really hard to do if your user is in Denmark, your designers in California, and the development team is in India. Which is why Agile works not for distributed development.

Re:Side-by-side

[bluefoxlucid]

Agile is, in a nutshell, a risk-lowering strategy for project management that incurs greater but more stable costs by repeatedly re-evaluating requirements along project phases in parallel.

Essentially, with basic Waterfall, you execute a series of project phases. At each phase, you re-evaluate your requirements, the progress of the project, and the needs of the organization to determine if what you're building still fits with what the user needs. With Agile, the next Project Phase will begin as soon as possible--if you can complete part of it after outputting a specific milestone deliverable in the previous phase, then you begin working on the next phase immediately. This includes repeated re-evaluation of requirements, which includes meetings with your clients (other department, coworkers, end users, managers, sponsors, whatnot) to examine what's been done, how the project is coming along, and how it addresses requirements.

This takes more time and expends more resources; however it also forces a re-evaluation of requirements, giving many more chances for your clients and sponsors to tell you that the project either is moving in a direction that doesn't satisfy requirements or is implementing requirements that have become obsolete. Obsoleting requirements reduces project work, but also invalidates some prior work--the fact that requirements are obsolete is not controllable, so the risk of discovering that the requirements are obsolete is the actual risk. Re-examining project requirements more frequently reduces the amount of work that will be done with obsolete requirements, decreasing risk.

Agile works fine. I dislike it, but I'm starting to understand and like it more. Project Management relies on communications; it includes Project Stakeholder Management and Communications Management, where stakeholders and their communications needs are classified and the frequency and mode of communications required are documented. Distributed development brings up a lot of communications needs and requires a good communications plan, because you're going to be communicating across differing cultures (yes even Norcal versus Socal presents issues in cross-cultural communications) with a lot of "virtual communications" (video conferencing, teleconferencing, etc. instead of face-to-face meetings). You can't just walk into the other department and talk to all these people during the course of their work; all communication will be highly structured, which is useful but is greatly aided by the inclusion of casual meetings. That means universal communications difficulties.

Solve your communications issue first. Then decide if you need Agile or Waterfall or what, because the best management strategy will depend on the project or even the project phase. You can't just slap Agile onto every project or run screaming away from it all the time and expect that to improve things. People love buzzwords because they think they can attach "DO THIS" "DON'T DO THAT" to things like Cloud or Agile or Virtualization, but they can't.

Slashdot beta

[game kid]

I wonder if the Slashdot admins will be doing either when they pull a YouTube and inevitably (it's always inevitably, for some reason) turn the main site into beta.slashdot.org.

Here's an easy one: "Archieved[sic] Stories" at the bottom. Listen to us, watch us, whatever, but please don't fuck it up, and fix what isn't right.

Re:Slashdot beta

[zifferent]

Wow, that is terrible.

Re:Slashdot beta

[Anonymous Coward]

Slashdot listen to its users? You have got to be kidding! If they were still in the habit of listening to its users then we would never have had to put up with AJAX/javascript etc much less the even more broken thing currently at beta.slashdot.org. Nor would we have seen the recent stories about things like malware inclusion at Sourceforge or the one about the governments spoofing this URL etc. Nor would it be annoying to us permanent ACs that "the Classic Discussion System" is no longer available to us or casual visitors with the good sense to keep scripting disabled because it would never have been labeled such as it would still be in use in some fashion here.

Re:Slashdot beta

[Anonymous Coward]

They will certainly fuck it up on purpose. A good Slashdot comment is like a conscience. That's the last thing the industry wants.

Re:Slashdot beta

[Anonymous Coward]

Lord, I hope not. I can only think of a few words to describe that layout, and none of them are good: space-inefficient, bland, and forgettable.

Re:Slashdot beta

[Anonymous Coward]

What a load of catfucking shite.

False premise - usually devs DONT want to

[Gothmolly]

Most of the time developers want to ship the product by the due date, and usually decide that they're smarter/cooler than the users anyway. "You'll take Feature X and suck it, luser." is the motto.

Re:False premise - usually devs DONT want to

[Chemisor]

Most of the time the managers want to ship the product by the due date, and usually decide that they're smarter/cooler than the users anyway. "You'll take Feature X and suck it, luser." is the motto.

FTFY

Re:False premise - usually devs DONT want to

[uslurper]

+1

And add to that the mid-managers who promise the execs something will be done in time for christmas, tell the devs to stop everything and work on an emergency audit, then go bat-shit crazy when project A isnt done on time.

really the basis of HCI

[toupsz]

Any decent HCI text will tell you the same thing. This has been known for a few decades now.

Re:really the basis of HCI

[Anonymous Coward]

I read that as HCl... And I thought "Yes, a little hydrogen chloride could solve a lot of user problems..."

Heck, that was the first thing I was taught

[sandytaru]

Back in my Systems Analysis class. You don't just ask the user what he wants. You ask what he does, and then you sit and watch him do it for a few hours. Maybe take notes. Ask questions. Get comfortable with what they're doing. And once you feel comfortable, ask if you can "drive" their existing applications for a bit.

I would never have found out about a critical missing feature in the new application I'm working on if I didn't make a point to have my morning coffee with the local power user of the app. She was dealing with complaint phone calls from customers that day, and it turns out we had no real means of tracking the complaints. That should be requirement #1 for a CMS application!

Re:Heck, that was the first thing I was taught

[Anonymous Coward]

Me too. The first three parts of the SDLC, Survey, Study, Select (collectively, Analysis). Wasn't this codified in the Yellow Books of yore? How the hell is this news?

Re:Heck, that was the first thing I was taught

[icebike]

You also need to pay attention to the stuff you see them doing that seemingly does not involve your system.

You will occasionally hear or see they do something in passing, maybe as simple as entering a name and address not only in your system, but also in some other parallel system such as a "rolodex" or simple spread sheet, and when you ask why, you find out that your system never made a provision for printing mailing labels, or the information they need for some obscure report takes way too long to find using your system.

Often you can accommodate these functions with a few lines of code, greatly improving acceptance of the system. (Someone is sure to jump up and scream "Feature Creep", but extensive or expensive additions aren't what is being mentioned here).

Also, don't forget to look into their Closet of Anxieties, those things they only mention while grumbling about their lot in life.

WHY IS THIS NEWS

[harvestsun]

This may be surprising to you, samzenpus, but there is an entire field of study called "human-computer interaction", and it has been around for about as long as computers have.

And one of the most valuable methods for gathering data has ALWAYS BEEN the observation of users.

Re:WHY IS THIS NEWS

[Rob the Bold]

This may be surprising to you, samzenpus, but there is an entire field of study called "human-computer interaction", and it has been around for about as long as computers have. And one of the most valuable methods for gathering data has ALWAYS BEEN the observation of users.

Now you and I are aware and always do a good job usability of course, but crappy design is still with us far too often, no matter how many times stories like this appear. And there are plenty of designers and programmers and engineers who still blame "stupid users" for not being able to use their systems. And plenty of those chime in every time this sort of article appears here.

At least the software world can take some comfort that everyone else sucks at this too. Ever seen a door with a labels on it that say "Push" and "Pull"? We can't even reliably design doors that can be operated without a user manual*. Door designers (and everybody else) can watch people push on a pull handle and vice-versa, and still insist that their design is too beautiful, elegant, symmetrical, etc. and that users should simply adapt. Unless designers of doors, software and everything else watch users use stuff and then do something with that data -- other than concluding that users suck -- nothing gets better.

*Yes, yes, I know about building codes and doors leading in and out of buildings, thanks Slashdot pedants, know-it-alls, and pedantic know-it-alls.

Re:WHY IS THIS NEWS

[harvestsun]

Everything you said is true, but that's beside the point! Slashdot is for NEWS, and nothing about this article is new!

Re:WHY IS THIS NEWS

[Rob the Bold]

Everything you said is true, but that's beside the point! Slashdot is for NEWS, and nothing about this article is new!

I was gonna reply that Slashdot is "News for nerds. Stuff that matters." and point out that this topic still "matters." But the joke's on me, since now I look around the site and realize that slogan is no more.

BA's?

[scuzzlebutt]

Isn't this what Business Analysts are supposed to do?

Re:BA's?

[Anonymous Coward]

I worked one cube over from a bunch of Business Analysts, and even THEY couldn't figure out what they were supposed to do!

Technology Push

[delta98]

Market Pull. Tell them they need it, They will. Computing is and always will be a tool. The fact that i's now an intrigated part of our lives is just something or other. Im drunk.

I've got an anecdote

[wjcofkc]

A few years I was with a company where several hundred users had to use the same database application. It was fairly large, with lots of features and was the golden company standard. The problem was that it was a buggy, crash prone POS that made everyday a nightmare of restarting software in the middle of something important - worst case a full system reboot. It made everyone's lives miserable. The complaints were universal across all users, we were always complaining to management who themselves knew it was crap software. From management our grievances would go to the mysterious developers that no one ever actually saw. They would review our complaints and roll out useless software updates that would sometimes disable important features, or at best make the situation worse. They simply didn't get it because they were so disconnected and segregated from the end users. This went on for years - people quit their jobs over this. One day, without much warning or any explanation as to what it was about, I was called into a focus group with what appeared to be a random sampling of end users. Holy smokes! The mysterious shadowy developers were right there in the room! We spent a couple hours talking with them one-on-one about the issues and the order of priority for what needed fixed. At the end of the meeting, it was agreed that the developers would spend the next week sitting with us at our desks, watching us use the software. They would spend a couple hours with someone at one desk, making notes, observations, actually seeing our problems and the business impact they were having, asking questions, and then select another random person.

After that week of seeing things first hand, the software was fixed in about a month.

Re:I've got an anecdote

[mcmonkey]

A few years I was ... After that week of seeing things first hand, the software was fixed in about a month.

That post should be mod'ed to +6 and stapled to the forehead of every project manager or system owner who thinks developers should be kept away from end users.

Re:I've got an anecdote

[T.E.D.]

At the end of the meeting, it was agreed that the developers would spend the next week sitting with us at our desks, watching us use the software.

This was the most important part of the note. Frankly, this should have happened before a single line of code was written.

However, failing that, I think it is an entirely fitting punishment for software developers to be forced to use their own software. In fact, there ought to be some diety of software engineers that forces exactly this on you when you die. You are doomed to use your own software into eternity. Whether that's hell or heaven is entirely up to the developer. So think before you code. :-)

There was a nice discussion about this (tipped off by little old me) on CodingHorror a few years back

Re:I've got an anecdote

[kaalon]

Similar experience, our main product was something that had lived a previous life on an IBM AS400. The app was ported to windows and the users complained a lot. Of course the developers were indifferent with comments of they are using it wrong, etc. So sitting the devs down with users at work caused that oh crap moment that the software really is the problem. After that, to stay in touch with the user base, the developers were assigned as the programmer of the day to help the support staff on calls. There is nothing like being in the trenches with users to get that usability in a design.

Re:I've got an anecdote

[Anonymous Coward]

You are doomed to use your own software into eternity.

This could be worse. You could be forced to maintain your own software for eternity.

Re:I've got an anecdote

[Anonymous Coward]

They key is, there's some developers and some end users that need to stay apart. If you have a developer who likes to blab about every possibility of what can be done, and does it to a user with enough knowledge to be dangerous, or enough pull to change the entire project, a simple 2-week development cycle can get turned into a nightmarish brand-new project that wastes time.

If you have a developer with limited social skills, they can set a reputation of being unhelpful for the entire department and doom your efforts to improve dev/user interaction.

But if you get a smart, socially capable developer who knows when to keep their mouth shut working with a power user who has the company and system's best interests at heart, you can get more understood in an hour of collaboration than in a month of formal requirements gathering handled by the BAs.

Re:I've got an anecdote

[Anonymous Coward]

And then you woke up !

Repeats are still useful

[mcrbids]

As somebody who's been in the software industry for well over 10 years, this is both blindingly obvious (to the experienced) and highly useful information. (to new entrants)

It's why articles on screen or pidof on *nixCraft are useful: there are always people who haven't already been doing this for more than a decade, and we, as the more experienced, should rightly welcome informative articles like this as it improves the general pool of competent professionals.

And a pony.

[sugar and acid]

My comment about customer feedback and especially surveys (so asking for customer feedback) is if you just ask them "what do you want" out of a product.You'll get back great useful answers back like: "It should be "better", cost a dollar, have all possible features we could ever possibly use, but we only really use 5% of them, but it has to be so easy to use nobody needs training, and a pony".

Generic and conflicting requirements that are frankly useless.

Re:And a pony.

[gilgongo]

You'll get back great useful answers back like: "It should be "better", cost a dollar, have all possible features we could ever possibly use, but we only really use 5% of them, but it has to be so easy to use nobody needs training, and a pony".

Generic and conflicting requirements that are frankly useless.

As a developer, would you like to deal with this reality? If not, let a designer do it because what you regard as "useless" is part of the raw material of improvement for them - they are paid to make sense of "make it better".

I would wager there are not enough hours in the day to research and interpret user needs AND write code. Designers are there for a reason (and if they're not researching, observing and interpreting, then they are shit). Whenever developers ask me to get them more involved with the people who will use their software, I always warn them to be careful what they wish for. But they usually only turn up to the first couple of research sessions :-(

Re:And a pony.

[Hognoxious]

Look up. See sugar and acid's point?

They want the impossible. A developer can't do that. A designer can't. A UX twat certainly can't, though he could probably tell you what colour it should be.

In other words

[Anonymous Coward]

Ignore the users, they don't know what's best for them.

Asinine Quote

[efitton]

Henry Ford lost over 50% of his market share by refusing to listen to his customers, his employees, and his family. Everyone told him that customers wanted different color cars. Ford said any color you want, as long as it's black. And GM ate his lunch. Be condescending to your users at your own risk. Shoot, GNOME seems to pride itself on doing the opposite of what users want and that is working out so well for them.

Re:Asinine Quote

[bondsbw]

Well, Steve Jobs was pretty much the same way. The biggest difference is that in most cases, he was either 1) right or 2) wise enough not to jump on the bandwagon before fully designing the product.

But I still want some damn widgets.

Re:Asinine Quote

[bondsbw]

And before someone tells me, "Hey, switch to Android and you can have all the widgets you want!"... well, I have... so no need for the fanboys to get in a hissy.

Re:Asinine Quote

[Anonymous Coward]

Henry Ford lost over 50% of his market share by refusing to listen to his customers, his employees, and his family. Everyone told him that customers wanted different color cars. Ford said any color you want, as long as it's black. And GM ate his lunch.

Not entirely accurate. Ford had made cars in different colors, but when he put his focus on the Model T, an automobile inexpensive enough for working people to buy, the paint drying time slowed down the assembly and shipping process. There was only one paint that would dry fast enough to keep the production going, and that was Japan Black. They had to wait for faster-drying paints to arrive before they could mass-produce cheap cars in different colors.

If Ford had produced Model T's in other colors, they would have been more expensive and therefore fewer people would buy them. It was a business necessity, not arrogance on Ford's part.

Re:Asinine Quote

[mattack2]

I'm trying to be nicer than [citation needed], but can you point to a source that proves/realistically theorizes that GM beat Ford (if they indeed did, I know little about the car industry history) solely because of car color choice?

Re:Asinine Quote

[Anonymous Coward]

Ford said any color you want, as long as it's black.

I read an interesting story as to why Ford said that.

At the time, the fastest drying paint available was black. So by using black paint, the assembly line was that much faster...

Re:Asinine Quote

[Anonymous Coward]

Or switch to Windows Phone and discover that widgets aren't really necessary anyway! Oh crap!! Here come the 'shill' accusations!

Re:Asinine Quote

[Anonymous Coward]

He also said "You can have any job you want here, as long as you're not Jewish."

Re:Asinine Quote

[arglebargle_xiv]

He also said "You can have any job you want here, as long as you're not Jewish."

I think you're confusing that quote with one from Madame Arabella (hand-, blow-, rim-, ...), she operated a bordello close to the Ford plant.

Re:Asinine Quote

[RaceProUK]

They did make Model Ts in other colours. In fact, for the first five years of production, you couldn't get a black one, even if you wanted it! Though they were all black from 1914 onwards.

Re:Asinine Quote

[MooseMiester]

It was a little more than that. Ford put all of their eggs in the Model T, and refined the production process to a level that set new standards in performance. At the time, most cars were one off hand built jobs, whereas he made a car for the masses.

GM came along with newer cars, new features, more styling, etc. Ford stuck with the Model-T for a lot longer than it should have, thus giving GM a foot hold. The Model A was a superior car in every respect, it just came out about four years too late.

GM didn't really "beat" Ford. Ford expanded the market to the point that there was room for other makes.

Today, Ford is still the only American car company that has taken no bailout money,and is still family owned. An amazing story, really.

Re:Asinine Quote

[efitton]

"In the 1920s, General Motors and others began offering cars in a variety of colors with added features, extending credit so that consumers could afford them. Ford insisted on keeping costs down by offering limited features and just one color (black). But after losing market to GM, the company shut down for several months to transition to the redesigned Model A. After this Ford came out with the "V-8". The vehicles were both successful, but the company remained outsold by General Motors." -http://entrepreneurs.about.com/od/famousentrepreneurs/p/henryford.htm "But everything changed with the onset of the innovations introduced by General Motors in the 1920s, which took the direct opposite of Henry Ford’s tack of “Any color so long as it is black” and is best summed up by Alfred Sloan’s consumer-research driven “A Car for Every Purse and Purpose,” which aimed to produce cars for distinct market segments aided by: Installment selling Used car trade-ins Closed car models Annual model changes In light of these, Ford persevered stubbornly with his cycle (now no longer disruptive nor virtuous) and as such, Ford’s response to these new innovations can only be described as tepid at best. The Ford Motor Company did introduce a closed-body Model T, and did so without significantly altering its open-body design, which most observers at the time felt amounted to a reluctant afterthought." --http://blogs.hbr.org/2011/08/henry-ford-never-said-the-fast/

Yes, but I've never seen ANYONE do it

[raymorris]

Every time I've asked to observe a user, the request baffles them. They've never had a developer do that before. I've never seen a developer other than myself just observe the user, keeping one's own mouth shut.

Users do the most surprising things, so watching them really is instructive.

oh, ok...

[Anonymous Coward]

so you want to legitimize in-app or in-application analytics and monitoring? no thank you. the privacy and security implications are astronomical when done incorrectly... and history has shown that things like this are, more often than not, done incorrectly.

Difficult != Safe

[sjbe]

My customer is the patient and the FDA.

In all likelihood neither of those is your customer. Your customer is the person tasked with actually using the device, most likely a nurse or doctor, and the organization that pays you for it. The FDA is certainly not your customer. The FDA's job is to ensure you aren't selling snake oil. They do not buy or use your equipment. They are a regulator not a customer. Just because you have to please them doesn't make them your customer.

If making it easier for the nurse compromises the safety of the patient, its BAD software.

Of course but making it needlessly difficult for the nurse also compromises the safety of the patient AND it hurts operational efficiency which is both a treatment risk and an economic cost. Safety first obviously but don't try to excuse bad design as a safety measure when it isn't.

Re:Difficult != Safe

[mcmonkey]

My customer is the patient and the FDA.

In all likelihood neither of those is your customer. Your customer is the person tasked with actually using the device, most likely a nurse or doctor, and the organization that pays you for it. The FDA is certainly not your customer. The FDA's job is to ensure you aren't selling snake oil. They do not buy or use your equipment. They are a regulator not a customer. Just because you have to please them doesn't make them your customer.

IAAQISDFAFRC. (I am a quality IS developer for a FDA-regulated company.)

Rarely is the end user the customer. Not to discount the needs of the user, but the doctor or nurse using the product is not the same as the customer paying the bills and setting the requirements.

The FDA is a regulator, but that does not capture the relationship between the company and the government entity. For example, I'm selling a vial of serum A. The regulator wants to make sure the vials actually contain serum A and if there is an issue, I can track down which vials went where and to whom so I can send out a notification or a recall if necessary.

But the labels and packaging with the vials, the FDA will have more input on those than my "customers." Documentation on validation of my systems is going to be more visible to the FDA than my "customers." Reports on product complaints, process deviations, documentation discrepancies, all go to the FDA, not my "customers."

For the software developer working under the regulations of the FDA and other such agencies, those agencies are very much our customers.

As for the example above, regulation may tell you what data the software needs to collect and how to handle that data, but it will not tell you in specifics how to collect that data. So for that nurse, required fields and commonly-used functions should be quick and easy to access. That certain fields are required, I've never known a developer to favor requiring fields when not necessary, so that almost certainly is due to the customer. That the nurse has to enter a value each time and not have the data default to a value from the last record, that's regulation. If it wasn't necessary for the nurse to take the measurement at each exam, the field wouldn't be required. Having a default value is the path to inaccurate data and false records.

Re: Difficult != Safe

[HeadlessNotAHorseman]

Everybody seems to be confusing the term "customer" with "stakeholder". The fact that a person may not understand what they really need when asking for an info system should be no surprise to anyone in the IT industry by now. It's the whole reason for the existence of business analysts like me. Being a good programmer does not by any means guarantee that you are good at gathering and understanding requirements. Being a good BA certainly doesn't make me any sort of programmer (though I do understand the concepts).

Re: Difficult != Safe

[mcmonkey]

Everybody seems to be confusing the term "customer" with "stakeholder". The fact that a person may not understand what they really need when asking for an info system should be no surprise to anyone in the IT industry by now. It's the whole reason for the existence of business analysts like me. Being a good programmer does not by any means guarantee that you are good at gathering and understanding requirements. Being a good BA certainly doesn't make me any sort of programmer (though I do understand the concepts).

And the customer is not always synonymous with user. The role of the BA is important, but it should be part of facilitating communication between the developer and the user, not a firewall keeping them apart.

Re: Difficult != Safe

[HeadlessNotAHorseman]

Everybody seems to be confusing the term "customer" with "stakeholder". The fact that a person may not understand what they really need when asking for an info system should be no surprise to anyone in the IT industry by now. It's the whole reason for the existence of business analysts like me. Being a good programmer does not by any means guarantee that you are good at gathering and understanding requirements. Being a good BA certainly doesn't make me any sort of programmer (though I do understand the concepts).

And the customer is not always synonymous with user. The role of the BA is important, but it should be part of facilitating communication between the developer and the user, not a firewall keeping them apart.

That depends on both the developer and the user :P Just kidding, I agree. When someone asks me what a BA does, the simplistic answer I give them is that I act as a translator between users/the business and the programmers.

I deal with some users that have almost no clue about computers and technology, so they have a tendency to think that IT development can deliver more than it can in a lot less time than it really takes. Even worse, the organisation I work in is strongly hierarchical so my communication with some users is often via several layers of management (each of whom know very little about computers and technology). Suffice to say, it is quite the challenge to manage users' expectations!

People are bad at explaining what they want

[sjbe]

1) Ask the user what they need

In my experience users are more often than not pretty bad at articulating what they need even when they know. Even more often they simply cannot envision doing things a different way. I'm an industrial engineer by training. If I walk out onto our shop floor and ask even my best people what they need (and I do this all the time), I'll usually get a non answer unless it is something like a supply for something they are already doing. You still have to ask (sometimes they have good input) but almost always it is a waste of time. In fact you would be amazed at how few people can write a simple work instruction for something they do every day. They leave steps and critical details and corner cases out often because it is too second nature to them. They're even worse when it comes to writing specifications for things they haven't tried yet.

However when you do run into that rare person who can actually envision and articulate what they want, it is a joyful thing.

Mobile app observation.

[CODiNE]

As I watched several users go through a few of my apps, an interesting behavior became apparent.

Many people as soon as they see a new screen on a mobile app instinctively flick up or down attempting to scroll. If the page doesn't bounce or in any way give them visual feedback they think that it's frozen and start to tap around looking for a response.

After that, I started making every single screen in my apps scrollable, even if it just bounces content smaller than the screen. That tiny little change makes users feel like the app is faster and more stable.

Re:Mobile app observation.

[gilgongo]

Hi - I'm a designer. What you describe is a property of computer interaction called "feedback." In principle (and design principles are important), you should always try to provide feedback to any input, regardless of whether that input is "useful" to the user or not. It means the machine is paying attention. That you have observed an unexpected input is a nice discovery. If you want, you too can build an entire career on doing this - because that's what I've done, and now I'm generally too busy and wealthy to read /. any more. But this story caught my eye.

Re:Mobile app observation.

[CODiNE]

Hey thanks. How does one make the transition from developer to designer? As it is I have no input and have to implement some horrible designs.

My favorite so far is the media player with 3 button controls at the top. Play, Pause, Stop ... which is *facepalm* enough. Except that in the song list below each track has play controls of it's own, a single play/stop button. 3 states and 2 states had to be kept in sync. IT MADE. NOT. SENSE.

Google Plus and Youtube

[Anonymous Coward]

However in the case of Google + and Youtube, developers can both watch AND listen.
http://www.youtube.com/watch?v=LTq8TrA3hb4

And you don't need a one-way mirror...

[dpbsmith]

At one now-defunct Fortune 500 company I worked for, they were sort of reluctant to apply any informal techniques like watching users try to use software (without instructions or coaching), because they had a nascent Human Factors group that wanted to build a facility with one-way mirrors and video cameras, and they kept telling everyone that you needed to have a facility like that in order to learn anything.

On numerous occasions at numerous companies I've simply corralled someone, anyone, who had not yet used the software, and asked them to try to accomplish basic tasks with it. "Please forgive me for not helping, I just want to see how far you can get without help. I'll help you if you really get stuck." And then I've watched them as they tried to use my software.

I always learned a lot from this, and I learned it very quickly, and a lot of what I learned was really trivially easy to implement. You can so easily miss the blindingly obvious when you are familiar with the software yourself.

The worst advice--well, maybe not the worst, but bad advice--tended to come from people giving advice that they imagined was on someone else's behalf. You really do NOT know what things people are going to find easy or difficult until you actually watch them try.

Yeah, this'll work

[msobkow]

Programmer sits down behind pretty new staff member with a bag of doritos and a coffee and starts munching and slurping.

"Don't mind me, I'm just here to observe your work habits."

*LMAO*

Mauve has more RAM

[Hognoxious]

and lately it seems that people think it's okay to forgo any real analysis any simply hand me pages of what they think the site/program should look like.

Sounds like what I refer to as "What do you mean, usability? It's skinnable!" syndrome.

For a second there....

[Anonymous Coward]

"And the best way to understand those users' needs is to watch what they do, "

I read that and thought this was another NSA story.

Windows 8

[Anonymous Coward]

> People often don't know what they want or need or they can't articulate it in a way that's useful to you.

This is not an acceptable excuse for the existence of Windows 8 and "Modern" UI.

Almost funny

[MooseMiester]

I work in Digital Interactive, building software for agencies & marketing departments, all of which ends up on the Internet. The software is what we call "consumable" in that it has a short life span, and only needs to be just good enough to work, and no better. It's not at all unusual to have the client redesign half of the project a week before launch. You write functional specs, nobody reads them. You create wire frames, nobody understands them. You get a creative brief that's all marketing speak, and layered photoshop files that are the design spec.

Coming from traditional I.T. the first six months were spent in a state of shock, refusing to believe that this process can actually work. Then you realize that 99% of the software on the Internet was written exactly this way... There is a "process" but you won't fit it into any SDLC you can find. It's CMMI level zero ALL THE WAY, everywhere.

This entire thread would have the Digital Interactive crowd going "Huh? What's this go to do with building websites?"