We just deployed a large software that affects the way the user work-day looks like in many aspects. It changes a lot of things in the way they interact between eachothers.  The developers of the team are taking rounds and spending one day at the customer's site to understand better what is a typical day for our user, and the learning process they go through.In this context, what How would you approach that day, what kind of questions do you ask, how do you observe the user. Are there defined practices that exist?Also what wouldn't you do? Did you have some bad experience out of this?
What are your advice, methods, or practices to take out the most from a day on-site at a customer?
customer relations;feedback
What not to do:Forget to tell those you are observing who you are and why you arethere. They will assume you are there for some bad reason likedetermining if they should get fired if you don't explain.Tell jokes. You don't know their corporate culture and what isappropriate in the IT world is often vastly different thtn the restof the world. At best they won't think you are funny, at worst youcould have a sexual harrassment suit on your hands.Be careful with scheduling, don't pick a day when they won't havetime to talk to you (such as when payroll is done if you areobserving the financial department.)Don't get defensive if they criticize your application! There is a good chance it will be very humbling to hear how much they hate your product. Remember what is important to them often bears little resemblance to what is important to you. What to do:Take notes.Ask if you can observe before observing someone. Not everyone feelscomfortable being observed. Ask the management to point you to arelatively experienced person and a relatively new person and peopleat different levels of the organzation or who have differnt functionsto observe. You want to see a broad group of users actually using the product. Never under any circumstances talk only to managers unless only managers use your system. Managers do NOT know how users use the system but they think they do.Ask them what parts of the application that they find awkward ordifficult to useAsk them what they like Ask them where they typically experience performance problemsIf they enter data from paper forms, get blank copies if at allpossible - it helps if the user interface is designed to follow the flow of the form.Ask them if there is something they still have to do manually (by this I mean using something other than your application) becausethe application doesn't do it. Also look for them doing such thingswhile you observe. Particularly note if you see them doing somethingmanually that the applciation actually should do. That may mean apain point - a place where it is easier to use an Excel spreadsheetthan use your application. Observe for awhile before you start asking them questions. Notequestions as you observe, you will probably find other things youwant to ask.If there appear to be performance problems you were unaware of, findout the stats on their systems (then you can build a test system thatis a similarly slow machine using the same operating system) and timesome of the tasks that seem to be taking so long. In fact do this even if you don't have performance problems right now. It helps to see exactly what operating sytems, internet browser they use as well as how fast in general their machines are. Be unobtrusive while observing - they should know you are there andwhy, but then stay out of their way. You will get better data aboutwhat they do after they forget you are there.Ask for more detail after they tell you something. Often the firstanswer is far from the real answer. People forget to mention detailsthat are critical to you. Don't forget to ask about edge cases. Ifthey tell you they then send this to be approved, find out whatshould happen when it isn't not just when it is. When they describe a problem, ask if they can show you. Often theywill miss parts of the process or will not understand how somethingis done. This can help with the user documentation and training.If you get time, show them what you need from them when they report abug. This can improve your bug reports greatly.(Can you tell I spent almost 15 years collecting this kind of data on processes?)