Customer Collaboration Win!

Dear Kalle and Matte

I think we already have a post along these lines, but I thought I would make one anyway.

Yesterday my team went to trafikverket to watch our system that we build be used live by the customer service department. I know! Watch the people who use the system actually use it…. Crazy right?

Anyway, this was a super positive experience for all that were involved and I just wanted to share a bit about it.

1) You can never know how the user actually uses the system:
Within 10 seconds of having sat down, I (and other team members working with other people) observed an issue with the system that I had never observed before. This revolved around a search function that we never really use on this end. Simply because of the way our test system is configured, it is not really needed for functional testing. (I should note, we are completely unable to test in the production environment at the moment for reasons I won’t get in to). So, this function always seems unneeded to me when trying the system. But a quick observation of live use revealed they use is on every single call they take, and it is SUPER slow. The fix for this will be a very small amount of work (don’t know how much at the moment) and will save the service rep a few seconds per call, over several hundred calls a day, across 20-30 reps. You do the math!
This is only one example of a few 20+ actions we took away from the day. Most of which are easy changes that will make the system much smoother to work in.

2) Showing our faces:
I think the biggest benefits from this is showing our faces to the customers, letting them understand that we care about their feedback and how things work for them. I think this alone has a big impact of the customers perceptions of the system and their willingness to work with us to make it better. I would however note, I think there is an inherent risk with this. It now becomes absolutely essential that we implement some of the things they requested, or that they see some impact from these sessions, otherwise, the attitude of “we complained but nothing happened” will develop.

3) Getting the team charged up:
I think my team deserves major props for taking the initiative to do this kind of thing. As simple as it is, so few teams actually do it. So, they go and get the gratification of seeing that the system is actually being used by people, they get to feel good about themselves for making the effort to do so, and finally they get to feel charged up about making changes to make the system even better going forward!

So, in closing, what I am trying to say is that everyone wins in this scenario! This is just an overview I think I could write on this subject for hours, but I won’t 😉


Attempted poetry on user feedback


To Kalle and Jeff,

I just read a most excellent post from a poster whose posts are excellent most.

It spoke of why user testing comes hard, and why good user feedback is hard to come by.

If you get no feedback on bugs in your system, assume your system for feedback has bugs.

If you get feedback on a certain feature, certainly look at the feature but not to the feedback.

If you get feedback on smaller deal issues, you might have to with larger issues deal.

If you wish for user feedback on a wish application, apply yourself to get the feedback you wish to use.



Sherlock uses usability to find the right password

Dear Kalle,

Since you are the biggest Sherlock buff (was going to write “I know” but I think “Period.” might also be possible) you’ve probably seen the episode “The Hounds of Baskerville” from season 2 a million times so I don’t have to put spoiler tags on anything I write from here on.

As you might recall, in one scene, Sherlock is trying to access a military officer’s computer by figuring out the password. I could quote you what happens, but instead here is a link to refresh your memory:

Anyways, while watching the scene it struck me that what Sherlock is doing – sitting down at a USER’s desk, looking for clues to the password in the immidiate enviroment, trying to form a persona of the officer to figure out how he thinks – are perfect examples of a usability methology called field studies – actually visiting end users on site to find out how they use the product. Of course, this is obviously easier when the user is present, but Sherlock is obviously beyond that and does an observation of the user WITHOUT THE USER PRESENT!

Holy level 6 frigging usability maturity, Batman!

Conclusion: Sherlock is a great usability expert, and we should both remember to do field studies more often, even though we seem to end up working with applications and services distributed over the web, so it will take active effort on our part to make it happen. But hey, the higher the fruit – the sweeter the juice!



PS. Fantastic show by the way! Only seen two random episodes of season 2 but I have to go back and watch the rest.