**

As I have to remind seemingly continuously my requesters… Business Requirements can be translated into Implementation Specifications, which can then be utilized to Build the System.

 

It sounds like you are, as I also say all the time, pushing the cart on the road with leaving the horse in the barn.

 

It is nice to “Window Shop”, and believe me, we do this on a yearly basis. We get selected tool vendors in and ask them to show us “their system” while we take notes and ideas.

 

I have seen some really “Pretty” UI designs that simply were not functional.

 

Conversely, I have seen very functional UI, that is not User Friendly.

 

Some simple things in UI Design drive me batty at times, and here is an example which I had to believe it or not, fight with the customer (HPD Manager) to understand.

 

Customer Requester Console for Incident does not have any “Urgency” field (the ITSM fields are Priority (internal) & Urgency(Customer))

This field has been disabled in all work-flow related decisions, reporting, etc.

The Incident Edit window still had the field present!

AARRUUGGHH!!!!

 

So start with the Customers Business Processes / Requirements (Processes, KPI Reporting, Notifications, SLA, …) and then start looking around doing the “Window Shopping” The majority of the time, the customer is quite happy with a nice functional car rather than a Ferrari which is high maintenance and breaks down a lot. (no I am not knocking Ferrari!!!) They need 30 fields for Incident Management, give them 30 fields, not 29 or 31. As much sense as it might make to you, it might not make sense to them. But that is what the Implementation Specifications can be reviewed for J

 

And Yes, when it comes to actual system design, I agree with Joe’s comments below.

Thanks-n-advance;

HDT Platform Incident / Problem Manager & Architect
Robert Molenda
IT OS PA
Tel: +1 408 501 6310
Fax: +1 408 501 2410
Mobile: +1 408 472 8097
[EMAIL PROTECTED]

Quality begins with your actions.

 


From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Joe DeSouza
Sent: Wednesday, November 08, 2006 2:49 PM
To: [email protected]
Subject: Re: Help Desk Designs

 

Performance should be on top of all priorities when you are rolling out your application to an external customer/user. Internal users might have to live with average performance as they are literally 'forced' to use your application but not the external user.. External users would not spend more than a few seconds if they have to, to log on to a system for example to identify themselves, see their home page and click around till they are able to submit or browse for existing tickets..

 

So I would pay most amount of attention to that, and secondly as you pointed out if things dont 'look' pleasing enough, they are hardly willing to use it especially inside of business hours - they might just call instead of using the web..

 

Pay a lot of attention to queries in your workflow to make sure they are optimized, index fields that require them even though the out of the box application might not have indexes on certain searches if you feel that creating that index will help the queries both defined in the workflow as well as possible queries your user might run..

 

Hope this helps..
 

Joe D'Souza

Remedy Developer / Consultant,

Shyle Networks,

New Jersey.

 

----- Original Message ----
From: Kathy Morris <[EMAIL PROTECTED]>
To: [email protected]
Sent: Wednesday, November 8, 2006 4:10:08 PM
Subject: Help Desk Designs

**

Hi,

 

I am redesigning our help desk application.  Are there any utilities or design ideas posted on the web to which give us a fresh look at redesigning say the Help Desk application? Any def files with auditing ideas?

 

It would be great if there were because the better the interface looks the more clients like the application... . just my opinion (of course functionality is first priority).

 

 

__20060125_______________________This posting was submitted with HTML in it___

 

 


Access over 1 million songs - Yahoo! Music Unlimited.

__20060125_______________________This posting was submitted with HTML in it___ __20060125_______________________This posting was submitted with HTML in it___

Reply via email to