Stop Listening and Start Watching If You Want To Understand User Needs 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."
No shit? (Score:5, Insightful)
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? (Score:5, Insightful)
Something something Henry Ford, something something faster horse
Asinine Quote (Score:4, Interesting)
Re: (Score:2)
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: (Score:2)
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 (Score:5, Informative)
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: (Score:2)
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: (Score:2)
Something something Gemba something something Kaizen something something reason US auto manfucaturing had to play catch-up to the Japanese
Re:No shit? (Score:5, Insightful)
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 (Score:2, Interesting)
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: (Score:3, Interesting)
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
Re: (Score:2)
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: (Score:2)
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: (Score:2)
Re: (Score:2)
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: (Score:3)
So how do you distinguish between "height measured, and it's the same" and "height not measured, same assumed"?
Re: (Score:2)
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 (Score:5, Insightful)
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: (Score:3)
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 (Score:4, Interesting)
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 (Score:4, Insightful)
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 (Score:4, Insightful)
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 (Score:3)
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 compro
Re: (Score:3)
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 i
Re: Difficult != Safe (Score:5, Insightful)
Re: (Score:3)
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 wi
Re:Medical (Score:5, Insightful)
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
Listen to your customers
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: (Score:3)
Re: (Score:2)
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 hec
Re: (Score:3)
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? (Score:4, Funny)
And your sales would be a lot better too.
Heck, that was the first thing I was taught (Score:2)
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 a
Re: (Score:3)
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 us
Re:No shit? (Score:4, Insightful)
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? (Score:5, Insightful)
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? (Score:4, Insightful)
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: (Score:3)
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 t
People are bad at explaining what they want (Score:2)
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
Re: (Score:2)
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 b
Re: (Score:3)
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
Re:No shit? (Score:5, Insightful)
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: (Score:2)
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 th
Re: (Score:3)
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
Re: (Score:2)
Re: (Score:2)
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 (Score:2)
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: (Score:2)
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 Designe
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
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: (Score:2)
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
Not really new... (Score:5, Insightful)
Re: (Score:2)
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: (Score:2)
Re: (Score:2)
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.
Captain Obvious? (Score:3)
IANAD (I Am Not A Developer) but isn't this Standard Operating Procedure in most software development these days?
Re: (Score:2)
Re: (Score:2)
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? (Score:5, Informative)
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: (Score:3)
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 th
Re: (Score:3)
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 w
Re: (Score:2)
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 do
Re: (Score:3)
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
Repeats are still useful (Score:2)
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.
Re: (Score:3)
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 act
Re: (Score:2)
It's harsh to blame the MBAs, to be honest. I think the "agile" movement is equally responsible.
Mauve has more RAM (Score:2)
Sounds like what I refer to as "What do you mean, usability? It's skinnable!" syndrome.
No question about it, you must watch and learn. (Score:5, Interesting)
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: (Score:2)
For instance one program I am using now does a very literal translation of the physical
Example this weekend (Score:2)
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 "exper
Not sure stop listening is right (Score:4, Insightful)
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: (Score:3)
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
Re: (Score:2)
MS did the first cloud service before dropboxq (Score:4, Interesting)
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: (Score:2)
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.. (Score:2, Funny)
Apple tells me what I need, thats the perfect scenario right?
..and the penny drops (Score:4, Interesting)
Side-by-side (Score:3)
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: (Score:3)
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
Slashdot beta (Score:4, Insightful)
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: (Score:2)
False premise - usually devs DONT want to (Score:2, Interesting)
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: (Score:3)
FTFY
really the basis of HCI (Score:2)
Any decent HCI text will tell you the same thing. This has been known for a few decades now.
WHY IS THIS NEWS (Score:2)
And one of the most valuable methods for gathering data has ALWAYS BEEN the observation of users.
Re: (Score:2)
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 s [google.com]
Re: (Score:2)
Re: (Score:2)
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.
I've got an anecdote (Score:5, Informative)
After that week of seeing things first hand, the software was fixed in about a month.
Re:I've got an anecdote (Score:4, Insightful)
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: (Score:2)
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. :-)
The
And a pony. (Score:2)
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: (Score:2)
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 peop
Mobile app observation. (Score:5, Interesting)
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: (Score:2)
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
And you don't need a one-way mirror... (Score:5, Interesting)
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 (Score:2)
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*
Re: (Score:2)
Re: (Score:2)
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 av