Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations derfloh on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
Getting User Input
- Thread starter Glenn9999
- Start date
Please define user input.
In my case, when we (me & my team) are asked to develop/improve something, we usually have some specifications that are built using ideeas from sales managers, product managers & group leaders. And, as we figured out, they aren't (and weren't) in any way close to customer's requirements.
Probably because the company I'm working for is more attracted to the ideea of iterative development than to waterfall development...
So, we're not getting much of a user input, but only some very distorted details (read: (background) noise) from the management![[evil]](/data/assets/smilies/evil.gif "[evil] [evil]")
...
In my case, when we (me & my team) are asked to develop/improve something, we usually have some specifications that are built using ideeas from sales managers, product managers & group leaders. And, as we figured out, they aren't (and weren't) in any way close to customer's requirements.
Probably because the company I'm working for is more attracted to the ideea of iterative development than to waterfall development...
So, we're not getting much of a user input, but only some very distorted details (read: (background) noise) from the management
...In my last role I developed software for internal use, for a company of approximately 2000 staff. User input was typically difficult or impossible to get before / during the project lifecycle, and one set of users (in particular) tended to give specific requirements and then claim that they had given different requirements when the project was completed. This led to problems getting acceptance sign-off before go-live as they had backing from a luddite board member (one of those who breaks his PDAs by forcing the wrong cables into it).
The way I found to combat this depended on the type of users I was dealing with:
1. Constructive users (not the aforementioned problem set)
I tried to cultivate 'super users' in each department or area. I defined these as those with extensive experience in their particular role who were IT-competent (ie they knew how to operate their workstations for normal day-to-day applications such as office etc).
I would make sure I spent as much time as feasible working through requirements and prototypes with this type of user, and relied on them to envangelise the new software to their co-workers.
2. Negative users (the aforementioned 'I didn't say that' set)
These users were eventually barred by my line management from directly contacting me by telephone to add on-the-fly requirements. I stored all email sent to / from them and documented everytime they failed to attend requirement meetings / return calls /etc. I also documented certain assumptions as part of the project initiation that put the onus on them to provide necessary information.
This approach paid off during my 3rd project for them where I was able to present a line-by-line rebuttal of their reasons for not signing the acceptance certificate, complete with 40 odd pages of email correspondence showing repeated failure to clarify / provide information / respond to queries. This was done at a senior management meeting in front of several board members![[bigsmile]](/data/assets/smilies/bigsmile.gif "[bigsmile] [bigsmile]")
after they'd spent several weeks bad-mouthing the development team to anyone who would listen.
To sum all this up -
1. Support the good users, encourage them to feel involved and take ownership of the new system through prototyping and 'quality time' spent with them.
2. Document the bad / problem users and their impact on the project, try to play nice with them but be prepared to stand your ground if they like to play the blame game.
HTH
TazUk
![[pc]](/data/assets/smilies/pc.gif "[pc] [pc]")
Blue-screening PCs since 1998
The way I found to combat this depended on the type of users I was dealing with:
1. Constructive users (not the aforementioned problem set)
I tried to cultivate 'super users' in each department or area. I defined these as those with extensive experience in their particular role who were IT-competent (ie they knew how to operate their workstations for normal day-to-day applications such as office etc).
I would make sure I spent as much time as feasible working through requirements and prototypes with this type of user, and relied on them to envangelise the new software to their co-workers.
2. Negative users (the aforementioned 'I didn't say that' set)
These users were eventually barred by my line management from directly contacting me by telephone to add on-the-fly requirements. I stored all email sent to / from them and documented everytime they failed to attend requirement meetings / return calls /etc. I also documented certain assumptions as part of the project initiation that put the onus on them to provide necessary information.
This approach paid off during my 3rd project for them where I was able to present a line-by-line rebuttal of their reasons for not signing the acceptance certificate, complete with 40 odd pages of email correspondence showing repeated failure to clarify / provide information / respond to queries. This was done at a senior management meeting in front of several board members
after they'd spent several weeks bad-mouthing the development team to anyone who would listen. To sum all this up -
1. Support the good users, encourage them to feel involved and take ownership of the new system through prototyping and 'quality time' spent with them.
2. Document the bad / problem users and their impact on the project, try to play nice with them but be prepared to stand your ground if they like to play the blame game.
HTH
TazUk
Blue-screening PCs since 1998I usually find it helps to throw something together in VB (just the UI) and show it to them. It's almost certainly not what they want, and they have no hesitation about telling me what I did wrong!
Chip H.
____________________________________________________________________
Donate to Katrina relief:
If you want to get the best response to a question, please read FAQ222-2244 first
Chip H.
____________________________________________________________________
Donate to Katrina relief:
If you want to get the best response to a question, please read FAQ222-2244 first
- Thread starter
- #5
User input = determining what they want or what is required to complete the job.
At least in my perspective it's always been the challenge for one of two things:
1) Access to the user. Usually the requirements are vague and get dumped on me by management. "Produce X report" they say, then I have twenty questions right away that neither the user or the manager (shows a little competency from THEM, huh?) thought of. Then of course, I have zero access to the user (i.e. the one who knows the answer). So I usually would end up sitting and twiddling my thumbs waiting on the management and user to sift through 20 of their other priorities before answers come (and hope they do come). Though I'll admit things got a bit better on this towards the end.
2) Random additional / "I really didn't want it that way" kinds of requests. That was the issue with my 2nd to prior job. The user(s) was very good at sticking around, asking questions, answering questions, basically taking ownership of their role in the system. I got to thinking about it, though, and considered this a real dream - we didn't have a very crushing workload at the time, yet we still had things to do. Then we got the chance to really improve upon all the software (actually a lot of things that have been *-worthy in other forums) and learn some good techniques.
It was annoying to deal with, but still I'm not going to complain with what this one was.
And probably my current problem with my hobbyist programs:
3) Finding user input. I tried posting to a software related internet site to ask some questions about something I had in mind to do, but I got no answers. Still though, I'm quite puzzled as to where would be a good spot to go for such input. Any ideas on this one?
At least in my perspective it's always been the challenge for one of two things:
1) Access to the user. Usually the requirements are vague and get dumped on me by management. "Produce X report" they say, then I have twenty questions right away that neither the user or the manager (shows a little competency from THEM, huh?) thought of. Then of course, I have zero access to the user (i.e. the one who knows the answer). So I usually would end up sitting and twiddling my thumbs waiting on the management and user to sift through 20 of their other priorities before answers come (and hope they do come). Though I'll admit things got a bit better on this towards the end.
2) Random additional / "I really didn't want it that way" kinds of requests. That was the issue with my 2nd to prior job. The user(s) was very good at sticking around, asking questions, answering questions, basically taking ownership of their role in the system. I got to thinking about it, though, and considered this a real dream - we didn't have a very crushing workload at the time, yet we still had things to do. Then we got the chance to really improve upon all the software (actually a lot of things that have been *-worthy in other forums) and learn some good techniques.
It was annoying to deal with, but still I'm not going to complain with what this one was.
And probably my current problem with my hobbyist programs:
3) Finding user input. I tried posting to a software related internet site to ask some questions about something I had in mind to do, but I got no answers. Still though, I'm quite puzzled as to where would be a good spot to go for such input. Any ideas on this one?
My experience has typically been, "We're not really sure what we want. Can you just throw something together and then we'll tell you how we want it to look from there?" Needless to say, they are very iterative projects... *sigh*
------------------------------------------------------------------------------------------------------------------------
"I am not young enough to know everything."
Oscar Wilde (1854-1900)
------------------------------------------------------------------------------------------------------------------------
"I am not young enough to know everything."
Oscar Wilde (1854-1900)
If you can't get the right input from users, maybe the right questions weren't asked.
Usually when a developer presents something to users for comment, the dev knows what kind of information they are looking for. Asking the right questions, presenting a form that they should fill out instead of asking for e-mailed comments (you'll have it in writing and won't have to depend on them actually getting back to you), and getting specifics is the developer's responsibility.
When a web app was developed here, different departments were looking for different functionality. The developer was able to take that information, figure out what else he needed to know, got the additional info, and was able to produce an immaculate piece of code. It probably helps that he's quite pushy.
Once again, bless our users here
Usually when a developer presents something to users for comment, the dev knows what kind of information they are looking for. Asking the right questions, presenting a form that they should fill out instead of asking for e-mailed comments (you'll have it in writing and won't have to depend on them actually getting back to you), and getting specifics is the developer's responsibility.
When a web app was developed here, different departments were looking for different functionality. The developer was able to take that information, figure out what else he needed to know, got the additional info, and was able to produce an immaculate piece of code. It probably helps that he's quite pushy.
Once again, bless our users here
- Status
Similar threads
- Locked
- Question
- Locked
- Question
- Locked
- Question