Payroll jobs and Canucks on an iPhone I am supposed to crank out a set of articles about NTFS and Share permissions, but I'm changing the topic: user experience management. This coincides with a series of IT-related but not IT-led projects at work. The projects allowed me a chance to see how other individuals approached the provisioning of IT services, from which …
Kudos to that CEO. Template testing may be monkey work, but bloody hell if it isn't important to get right. Look at any ticketing system and observe how atrocious the default email templates are. That's not helping anyone like email more, that's just stuffing everyone's inbox with voluminous, verbiagous, heaps of crap that gets deleted instantly and so people will gaze at the web interface instead. Since my workflow is heavily anti-browser and pro-MUA (of _my_ choice, TYVM), I hate all ticketing system "designers". Can't even get In-Reply-To: right. Losers.
That user experience observation is pretty important. Also note how this effect _used_ to be the main drive for uptake of new micros~1 ``products''. Only theirs were invariably shoddy in addition to insulting my intelligence with abandon. Somehow I mind apple's take less. Even if apple is far from a benign company. They're better at interop, their products have an undeniable shine, they work, by and large. I still don't have apple gear, mind.
Design.
having come from a prinint background I can spot bad design a mile of:
Apps on windows pc's that don't follow the MS "standard" you know, hitting F1 will do help, CNTRL + C,V,X etc. 99% of programmes use it, then some bright spark decided that F1 should be for save, or cut and paste is CNTL & L and P or something stupid.
Forms that are in illogical orders, very often happens when US software is used in the UK. ZIP Code not labled postcode. You know that, I know that, but does Fred in accounts no that?
Using Red text to highlight an issue. Great, unless of course it's a dark blue background.
You may click OK on a form and it completes, but the form doesn't close. Is it an error? Did I forget to fill in a field or is everythingcorrect, do I have to click close or something else?
End user experience is EVERYTHING. You can have a brilliant system, but if the end user interface is crap, it's dumped on them with no training, it will be slagged off no end.
Apple, (no I own 0 Apple devices) are very good and getting this bit right and for that they must be saluted, even if at a premium cost.
Interesting article, Mr Pott, thank you :)
I like what you say about documentation and ease of use as these two things go hand in hand. I'd almost go further and say that some of the more basic things shouldn't need documentation as if they have been designed with ease of use in mind, documentation should be unnecessary.
I do feel that the hallmark of a well designed gadget is that most technically savvy people (and I'm thinking of most El Reg readers) should be able to pick up a gadget and figure out how to work 70% or more of the item's features without recourse to the manual. For the remaining ~30% the manual should provide an explanation that makes it possible for the person who got the other ~70% working to get the final bits working.
I think that makes me respect your CEO more as he seems to understand how crucial usability is. Someone should be able to use those templates without having to sift through a manual telling them how to fill them in. Also they should contain all the required information, but only that information, in a logical format.
Perhaps that is why so many people think Apple have invented stuff that has been out there for yonks, like video streaming over 3G; they've made it look pretty and easy to use.
Myself? I have a HTC Hero (yes finally upgraded to Android 2.1!), and I figured out most of the handset myself with no need for the manual. The rest I don't have any use for (e.g. Exchange server synching as I use gmail only).
"I like what you say about documentation and ease of use as these two things go hand in hand. I'd almost go further and say that some of the more basic things shouldn't need documentation as if they have been designed with ease of use in mind, documentation should be unnecessary."
Speaking as someone who has worked in tech docs, I can point out the one flaw with that idea:
The engineer always KNOWS that his design is so intuitively obvious that NONE of it needs documentation! <gr>
<rant>
Not that the engineer is alone in this -- EVERYBODY hates the documentation: The engineer, as noted, believes that documentation is unnecessary because of his brilliant work;, management and finance hate it because it's a cost rather than a revenue enhancer; marketing hates it because a stack of manuals makes the product look more complicated and, thus, harder to sell; the customer isn't going to read it anyway, but will just call the help line who will curse the docs group for making them pick up the slack because "if they'd done their bloody job in the first place...".
No respect... No respect at all...
,/rant>
In any process the end user is the most important. A large US air reservation system sent teams around to study how end users did their work and, after correlating the accumulated data, they re-did their user interface, idiosyncrasies (strange - to IT people - work flow processes) and when it was rolled out it proved to be so very successful it increased use.
The CEO was correct: make IT departments SERVE the end user than vice versa.
Make _the technology_ serve the end user. The department is there to keep the stuff running, not "serve" the end user. You similarly don't want to turn IT departments into "shops" that cater to "customers". That way you get the end user claim he's always right, which causes all sorts of systemic pains later on. You want to have your IT department _work with_ the end user to tailor a solution, which is what your example did. So I'm a pedant, so I work in IT.
But yeah, and it's much more generally true: We MUST take care our technology --all of it, not just the computer-y part-- serves us, and we MUST NOT make people serve our technology, our systems, our bureaucracies. The fine print in ID cards (now scrapped) was a prime example of this. Most of the Dutch infrastructure is starting to work this way. I'm sure you can come up with more.
Absolutely.
IT is there to implement and manage the technology that the business runs on. While customer service is always important to maintain healthy relationships between IT and the business, it is not, and should not, be the end-all be-all. To abuse the phrase, the customer is *not* always right. Sometimes, they are dead wrong, or are trying to weasel around a restriction.
IT is just as much part of the business as everyone else. To get anything done everyone needs to work together. Profit centres inside the company don't exist, everything is a cost centre. What a company is usually looking for is happy customers, sales, repeat sales, revenue, profit, that sort of thing. The only place where you can measure effectiveness of the company is outside the company.
I didn't come up with this; I read it in the late management thinker Peter Drucker's work. Because IT generally provides a contribution that is largely taken for granted or even unseen, it's easy to think it's somehow special. It's not. Without sales, no company. Without IT, well, get your pens and paper pads out, boys and girls. No email, no printing, no porn for the sales department!
Kudos on having a -good- CEO!
And, it's so irritating when a company is selling your company a product, that you're expected to support in-house (for most issues) after rollout.. but you can't get any IT data from them until the product is purchased.
@AC, 1548GMT:
<quote>Make _the technology_ serve the end user. The department is there to keep the stuff running, not "serve" the end user. You similarly don't want to turn IT departments into "shops" that cater to "customers". That way you get the end user claim he's always right, which causes all sorts of systemic pains later on. You want to have your IT department _work with_ the end user to tailor a solution, which is what your example did. So I'm a pedant, so I work in IT.</quote>
Spot on!
Ok,
I am with AC on this. But, I also wanted to mention, I've seen it done (and I'm sure others have too) where the decision makers never think about "what's the IT angle" on any decision that may remotely or directly involve the IT group.
Good to hear that it is not necessarily the case at your firm, and hope that more firms become more enlightened by it.
I guess, my biggy, is that you have some software vendors who try to sell their crap to the decision makers, and don't want or don't care to have IT involvement at the firm that is their "mark."
I'm not alone in noticing that trend, am I?
This happens all the time in my company. The CEO tends to try to mitigate this, but the CTO will cheerfully commit us all to a given product or service because it's shiny and/or “newer” than what we use. (“So this Vista thing comes out in a month. It’s pretty good; don’t believe what you read on the internet about it. I trust the migration is already planned?”)
Even better is that “IT” in our company is fantastically dispersed. Our CEO is allergic to the idea of a hierarchical structure of any kind, and so while “IT Infrastructure” (our three-man IT department) is very roughly hierarchical, customer support, development and production-facing IT are all their own one-man units. Each of these units essentially don’t communicate with each other unless they absolutely have to, and everyone makes piles of assumptions about how anything is, should be or could be set up. The CTO is also essentially disconnected from everyone else, and that brings even more fun.
Everyone of course has a different idea about how the communications problems should be resolved, and that’s when you can get them to admit there are such problems. Some individuals favour a technological approach: this has alternated between trying wikis, forums, public folders in Outlook, you name it. It falls apart because there’s zero incentive for anyone to use it. Others believe that we just need to call a meeting for every little problem, and hash out everything face to face. The kind of time it takes to do so, and the scheduling problems are of course irrelevant.
My personal vote is for something more structured and hierarchical: regularly scheduled meetings to keep the various arms of IT on track, or better yet a piece of wetware at the top of the stack whose job it is to make sure that various jobs are being dealt with properly. Some way must be found to make people want to cooperate, or they simply never will.
This gets to be quite miserable when those aforementioned predatory vendors swoop in, promise you the moon on a stick for $24.99, but neglect to mention that if you want their product/solution/service to work then you are going to have to rip up half your infrastructure and replace it with theirs/their partners. This of course will be committed to, money paid, and an “oh by the way we are doing this in this timeframe” e-mail filters out to everyone three days before the due date.
If/when anything goes wrong with either implementation, cost overruns, miscommunication, or even externally-caused errors such as DDOSes or the fibre being cut it all lands on my head. I can honestly say that the only reason I can keep anything running is because I very regularly overstep my authority to get things done. “It is better to beg forgiveness than to ask permission.” I realise that this only increases the division between the various groups, but if anything is ever going to get accomplished there doesn’t seem to be any other choice.
Good times.
A/C because while my coworkers would know it was me in a heartbeat, there’s no reason to tell our competitors about our internal problems.
The Storm 2 is significantly better than the Storm 1. It is also RIM's only current touchscreen smartphone, which is what the user wanted. Prestige, reputation, "look at me I've got an iPho^h^h^h Storm 2!)
Only two users chose the Storm 2. The rest went with either Bolds or Curves.
Early in my career I found that enforcing certain departmental rights in an innocuous way helped a ton. I was able to sneak in a policy that only IT could purchase any software or any significant technology, and that would only happen after appropriate testing had been done. It has saved me a ton of grief.
Good job on the article Trev, I have been meaning to check out your work. Glad I did.
Holycrap. You're not dead! Jubilation and excitement!
Also: Lucky barstward. "Only IT could purchase any software or any significant technology, and that would only happen after appropriate testing had been done" Pffft. That would make life easy. We get this honour sometimes, but equally as often we get handed a great big steaming pile of "we bought this, now make it work." Usually without any additional budget for new kit or interoperability gear.
Anger and frustration!
Anywho, I R the done in Vancouver. Onwards to Cowgary!
Pint, because we must both indulge upon my return to E-town.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
