BuzzwordBollocks?
Works for me ...
Users are those strange creatures who break the computer you put on their desks, and for whom software that has worked perfectly in the test lab suddenly decides to crash. I used to share an office with the most amazing user of all, who could slay the most stable code with just a flourish of the mouse: I'd never seen a …
So.. how long you start to overpromote overhyped overexpensive "conferences" about UserDev?
Featuring Dave Bollocks, a 64-year old retired truck driver that is able to break whatever user interface you can build. Hear from Dave in this week's UserDevCon, only 2 million tickets left!
with building your own tools. Heck, surgeons do it all the time. It's how tools get built! But then, I work in a medical research environment, so we are always building our own tools because there either aren't any yet, or the ones that come close don't come close enough.
There's a joke around my place that if you give 3 researchers an analytical task, you'll get a huge Excel VBA macro, a dozen bash scripts, and something bizarre in Perl. None of it will be comprehensible to anyone other than the creator, let alone the IT department who knows nothing about biology, and somehow bits of it will be deployed in production anyway.
In my toolbox at home, I have a spanner made by my grandfather because he didn't have one of the size he needed. It's made out of an old file.
In the words of modern advertising/marketing/media people the file has been re-purposed, or has it been re-imagined. Am I the only one who finds these expressions annoying?
"Not security, training and likely not following policy"
Both possibly true, but in my experience shortcuts, like modifying the PDF, show up failings in the original systems and conflicting priorities foisted on the users (aka poor bloody infantry) by their line managers.
In any ordinary business system failure to take the users actual experience into account is invariably fatal. To paraphrase the article "If I had a tenner for every time the users gave me a completely different story from the managers description of their current system, I'd have several tenners"
Thank you kmac499, yes. some invoice adjustments were done using a PDF editor on the invoice itself rather than by changing the finance system and generating a new bill... isn't the sign of a "security problem" though it may be that as well. It's more like a sign that the people who need to use the bloody system are finding the correct usage some combination of unwieldy, complicated and slow.
So trying to enforce it, and any kind of training that implies persevering with a duff system is just plain perverse.
Remember "Keep It Simple Stupid"
You haven't addressed the issue of fear, fear of change and especially of responsibility. Some people, some times entire departments or entire companies think if they don’t make a suggestion or don’t engage they are not responsible for anything that happens and I have seen that fear cripple projects and stymie good plans by IT departments that don’t have the clout to force fearful users to engage.
At one job, I had an amazing resource called Pete. If there were such a thing as a British Standard Fool, Pete would have rated as about 1 Megafool - he'd do the most mindbogglingly stupid things, and when you got over spluttering and asked him why he'd just say something like "Dunno. Seemed like it might help". I got into the habit of getting him to test my code first, and he'd invariably break it, but by the time I'd got it Pete-proof I had no worries whatsoever about letting the rest of my users loose on it.
Yeah we had one of them, his name might even have been Pete too. The highlight (if you can call it that) of Pete's career with us was when he copied the registry from his home PC onto a disk, brought it into work and overwrote the registry on his work machine.
He never adequately explained what he hoped to gain from that.
In my old Windows days, I would sometime export a branch of the registry after doing a configuration switch. Say, after enabling tab completion in DOS windows. You could then reload that adjusted branch export on a new machine and, presto, tab completion again. If it was a small branch, with few, understood, options, it would probably do just fine on another machine.
However, if you mistakenly exported the whole registry... things might not look so rosy on reload. At the glacial pace of exporting 30+ MB registry dumps though it was usually easily enough to tell the difference.
Impressed that an end user would do this. Not so much that he didn't realize its risks.
(disclaimer: lazy dev, not a sysadmin, here. wouldn't recommend this on someone else's gear)
"I just wish someone would tell my boss we need at least half a dozen extra people to support a 2 person development team :)"
I believe AT&T did some research that suggested that required support varies roughly as the cube of genuinely creative people. One such person can work on their own; two require 23 or 8 (which gives your 2 to 6 ratio); 3 requires 24 for a total of 27 and so on.
I wonder how much usability is ruined by the devs' PHBs talking to the users' PHBs and neither of them understanding what the devs are trying to make or how the users do their work. Especially if the computer is ancillary to the main task, e.g. for recording results or data that the users have generated elsewhere.
I'm certainly aware of incidences where users have been asked to change their assessment procedures to meet the needs of the software, for example where the original paper recording system allowed annotated or ranged results, ( such as "scores at 80th percentile, but with significant variations +/- 10 points from day to day" ) but the shiny new software demanded a specific percentile score. (Cynically I assumed that was because the bean counters wanted to use the results for cost effectiveness rather than therapeutic reasons).
Before I started my computing degree I worked closely with a company creating our bespoke CRM. At this point I hadn't ever coded before but had a good computer knowledge and, more importantly, a full understanding of the business I worked for. I think it helped being able to tell the devs exactly how a certain feature should work (right down to whether something should be a search box or combo box) rather than something being created from some abstract user story.
Talk to the customer. Show them what you are working on regularly (Agile) and pick their brains for how the system should work better and what they actually need to do in real life.
But also bear in mind that many "users" just want a faster version of what they already have.
Really you need a Steve Jobs to show people what they have not imagined possible yet.
The real UserDev will come when you can just speak to the AI and say "Design me a system to do X" and a few seconds later something appears. But really we don't need any more stupid words to describe things we've already been doing for years.
Quote
Techies, on the other hand, are often quite good at coming up with fun new things because they know what their tools can do; the downside is that these fun new things tend to be neither saleable nor useful to the common person.
Sounds a lot like all versions of MS Office since 2010 (or possibly earlier)
I once spent many months sitting with the manager of a professional group that had developed a data and record keeping system that was to be shared amongst a whole range of professionals and teams, trying to make it usable.
A system that was coded by a company paid lots of money, so that it relied on an already obsolete version of Internet Explorer and failed if IE was updated to a new, secure version, despite containing confidential information.. And the text was written by a team leader of one of the groups, that had its own way of using words, words that meant something totally different to the rest of the world. Words that were used all through the system. And because it was tied to their way of working there were compulsory fields that other teams couldn't use, but couldn't get past. There were "security" time outs that made sense to them, but were too short in some sections that other users needed and meant that if those users stopped to think, or take a sip of coffee the whole shebang would cancel and the task needed to be started again.
Even worse was a Risk Management system that was bought in by the big bosses. This was full of meaningless fields on numerous levels, with endless report and confirm stages. It has cute little icons that gave no clue to their purpose ( or worse were misleading), it had the same words used in different places to indicate different types of data. It had a spaghetti of links to complete the various sections, it had compulsory sections for lower level staff that asked information they couldn't provide at that level. And... well was so f****ing unusable they had to send a team of specialists around to fill it in for us.
Back when I was at Uni - many, many years ago - we were taught that you should site with actual users to see how they used the current system BEFORE you start designing systems. This was to see how the system was used rather than what it was supposed to do.
In the decades since, I've yet to see a software development team do that at any of the places I've worked.