Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

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

samzenpus posted about 10 months ago | from the as-I-do-not-as-I-say dept.

Businesses 161

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."

cancel ×

161 comments

Sorry! There are no comments related to the filter you selected.

No shit? (5, Insightful)

grasshoppa (657393) | about 10 months ago | (#45392165)

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? (4, Insightful)

Fwipp (1473271) | about 10 months ago | (#45392201)

Something something Henry Ford, something something faster horse

Asinine Quote (4, Interesting)

efitton (144228) | about 10 months ago | (#45393173)

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 (1)

bondsbw (888959) | about 10 months ago | (#45393971)

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:No shit? (1)

mcmonkey (96054) | about 10 months ago | (#45393287)

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

Re:No shit? (5, Insightful)

bob_super (3391281) | about 10 months ago | (#45392251)

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?

Medical (2, Interesting)

Anonymous Coward | about 10 months ago | (#45392279)

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 (3, Interesting)

fast turtle (1118037) | about 10 months ago | (#45392513)

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 (1)

icebike (68054) | about 10 months ago | (#45392787)

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 (1)

malkavian (9512) | about 10 months ago | (#45393203)

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 (2)

blakelarson (1486631) | about 10 months ago | (#45393315)

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 (1)

icebike (68054) | about 10 months ago | (#45393925)

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 (5, Insightful)

Nadaka (224565) | about 10 months ago | (#45392571)

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 (2)

icebike (68054) | about 10 months ago | (#45392861)

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 (3, Interesting)

Nadaka (224565) | about 10 months ago | (#45392889)

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 (3, Insightful)

ColdWetDog (752185) | about 10 months ago | (#45393079)

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 (3, Insightful)

malkavian (9512) | about 10 months ago | (#45393249)

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.

Difficult != Safe (2)

sjbe (173966) | about 10 months ago | (#45393391)

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 (2)

mcmonkey (96054) | about 10 months ago | (#45393687)

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:Medical (4, Insightful)

carlcmc (322350) | about 10 months ago | (#45393411)

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 (1)

Anonymous Coward | about 10 months ago | (#45393917)

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:No shit? (1)

Anonymous Coward | about 10 months ago | (#45392295)

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? (2)

pr0fessor (1940368) | about 10 months ago | (#45392297)

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? (1, Funny)

Anonymous Coward | about 10 months ago | (#45392473)

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? (3, Funny)

icebike (68054) | about 10 months ago | (#45392871)

And your sales would be a lot better too.

Heck, that was the first thing I was taught (1)

sandytaru (1158959) | about 10 months ago | (#45392435)

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 (0)

Anonymous Coward | about 10 months ago | (#45392607)

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 (2)

icebike (68054) | about 10 months ago | (#45392965)

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.

Re:No shit? (3, Insightful)

Areyoukiddingme (1289470) | about 10 months ago | (#45392455)

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? (5, Insightful)

bluefoxlucid (723572) | about 10 months ago | (#45392593)

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? (3, Insightful)

Runaway1956 (1322357) | about 10 months ago | (#45392601)

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? (2)

ImdatS (958642) | about 10 months ago | (#45392529)

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? (0)

Anonymous Coward | about 10 months ago | (#45392923)

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

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

People are bad at explaining what they want (1)

sjbe (173966) | about 10 months ago | (#45393561)

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.

Re:No shit? (2)

bluefoxlucid (723572) | about 10 months ago | (#45392531)

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? (4, Insightful)

mcmonkey (96054) | about 10 months ago | (#45393475)

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? (1)

Anonymous Coward | about 10 months ago | (#45393951)

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? (2)

girlintraining (1395911) | about 10 months ago | (#45392687)

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? (1)

jythie (914043) | about 10 months ago | (#45392721)

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? (2)

pigiron (104729) | about 10 months ago | (#45392835)

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

Yes, but I've never seen ANYONE do it (1)

raymorris (2726007) | about 10 months ago | (#45393263)

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.

Re:No shit? (1)

Patch86 (1465427) | about 10 months ago | (#45393317)

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? (1)

INT_QRK (1043164) | about 10 months ago | (#45393329)

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? (2)

StrangeBrew (769203) | about 10 months ago | (#45393491)

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.

Not really new... (4, Insightful)

Longjmp (632577) | about 10 months ago | (#45392167)

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

Re:Not really new... (1)

Toad-san (64810) | about 10 months ago | (#45392469)

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... (1)

BetaDays (2355424) | about 10 months ago | (#45393407)

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... (1)

houghi (78078) | about 10 months ago | (#45393279)

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

What [good] Business Analysts already do? (0)

Anonymous Coward | about 10 months ago | (#45392175)

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

Captain Obvious? (2)

CronoCloud (590650) | about 10 months ago | (#45392185)

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

Re:Captain Obvious? (2)

NMBob (772954) | about 10 months ago | (#45392227)

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? (1)

cellocgw (617879) | about 10 months ago | (#45392637)

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? (5, Informative)

plopez (54068) | about 10 months ago | (#45392323)

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? (1)

Anonymous Coward | about 10 months ago | (#45392709)

Here is another explanation in comic form : Construction Project [projectcartoon.com]

Re:Captain Obvious? (2)

Crudely_Indecent (739699) | about 10 months ago | (#45392749)

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? (2)

Ravaldy (2621787) | about 10 months ago | (#45392365)

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? (0)

Anonymous Coward | about 10 months ago | (#45392417)

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? (1)

Runaway1956 (1322357) | about 10 months ago | (#45392683)

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? (2)

paulpach (798828) | about 10 months ago | (#45392711)

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.

Repeats are still useful (1)

mcrbids (148650) | about 10 months ago | (#45392797)

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.

So true (0)

Anonymous Coward | about 10 months ago | (#45392205)

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. (5, Interesting)

udachny (2454394) | about 10 months ago | (#45392223)

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. (1)

fermion (181285) | about 10 months ago | (#45393085)

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.

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

udachny (2454394) | about 10 months ago | (#45393987)

By approaching the design and implementation of the system from POV of a designer/developer, I was able to offer a number of solutions to the retail chain in question, which they could not even imagine. So right now this chain has software that does things in a way that is not normally done by other retail management solutions because it wasn't a manager of the chain that proposed the technical solutions to his problems, it was a designer / developer that offered a different, more efficient approach to handling business and the retail agreed and is benefiting from it, it's a competitive advantage they have against others.

Example this weekend (2)

jhumkey (711391) | about 10 months ago | (#45392235)

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 (1)

DahGhostfacedFiddlah (470393) | about 10 months ago | (#45393011)

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

Diy (0)

Anonymous Coward | about 10 months ago | (#45392239)

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

Also true of Sysadmins (1)

Anonymous Coward | about 10 months ago | (#45392241)

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 (1)

sandytaru (1158959) | about 10 months ago | (#45392477)

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 (1)

constpointertoconst (1979236) | about 10 months ago | (#45392633)

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.

Not sure stop listening is right (3, Insightful)

TheCarp (96830) | about 10 months ago | (#45392257)

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 (2)

mcmonkey (96054) | about 10 months ago | (#45393221)

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 (2)

defcon-11 (2181232) | about 10 months ago | (#45393809)

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".

MS did the first cloud service before dropboxq (3, Interesting)

alen (225700) | about 10 months ago | (#45392289)

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

But.. (2, Funny)

Anonymous Coward | about 10 months ago | (#45392293)

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

I couldn't possible agree more (0)

Anonymous Coward | about 10 months ago | (#45392305)

...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 (0)

Anonymous Coward | about 10 months ago | (#45392355)

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

..and the penny drops (4, Interesting)

netean (549800) | about 10 months ago | (#45392321)

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 (2)

plopez (54068) | about 10 months ago | (#45392343)

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 (2)

bluefoxlucid (723572) | about 10 months ago | (#45392765)

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 (3, Insightful)

game kid (805301) | about 10 months ago | (#45392377)

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 [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 (1)

zifferent (656342) | about 10 months ago | (#45392733)

Wow, that is terrible.

Re:Slashdot beta (0)

Anonymous Coward | about 10 months ago | (#45392847)

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.

False premise - usually devs DONT want to (1, Interesting)

Gothmolly (148874) | about 10 months ago | (#45392407)

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 (2)

Chemisor (97276) | about 10 months ago | (#45392495)

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 (1)

uslurper (459546) | about 10 months ago | (#45392695)

+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 (2)

toupsz (882584) | about 10 months ago | (#45392433)

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 (0)

Anonymous Coward | about 10 months ago | (#45393449)

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

WHY IS THIS NEWS (1)

harvestsun (2948641) | about 10 months ago | (#45392463)

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 (1)

Rob the Bold (788862) | about 10 months ago | (#45393787)

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"? [google.com] We can't even reliably design doors that can be operated without a user manual [wikiquote.org] *. 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.

BA's? (1)

scuzzlebutt (517123) | about 10 months ago | (#45392501)

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

Technology Push (1)

delta98 (619010) | about 10 months ago | (#45392625)

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 (5, Informative)

wjcofkc (964165) | about 10 months ago | (#45392743)

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 (3, Insightful)

mcmonkey (96054) | about 10 months ago | (#45393255)

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 (1)

T.E.D. (34228) | about 10 months ago | (#45393681)

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 [codinghorror.com] a few years back

And a pony. (1)

sugar and acid (88555) | about 10 months ago | (#45392803)

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.

In other words (0)

Anonymous Coward | about 10 months ago | (#45393039)

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

oh, ok... (0)

Anonymous Coward | about 10 months ago | (#45393265)

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.

Mobile app observation. (4, Interesting)

CODiNE (27417) | about 10 months ago | (#45393599)

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.

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>