Customer Observations

I have been programming professionally for a long time now, and I have rarely had an opportunity to meet with customers who are buying and using the products that I make.

My first real customer experience

About 5-6 years ago I was working at a company and one of our user experience people was able to get a real user to come into our office to use the software that I had helped develop.  It was the first time I had really seen an external customer use anything I had created.

The software was designed to help cancer researchers visualize how gene expression and drugs play a role in cancer.  My role was to simply observe while my colleague gave the user some tasks to complete with the software.  I thought the tasks would be fairly straight-forward.  Heck, I could even accomplish most of the tasks fairly easily, and I knew next to nothing about cancer research.

As I watched, I was amazed to see some of the ways the user was trying to interact with the software.  Some tasks that I thought were very straightforward were baffling her, and she didn’t really know if she accomplished the task she had set out to do.

What was going on?

After taking copious notes and reflecting on what I had seen, I realized that the act of building the software had made me an expert in the software, even though I was not an expert in the cancer biology and research field.  I knew how to get the answers, because I was intimately involved in creating the tool.

We had a filter-tree in the application that had sub-filters.  You could click on a parent and add that general filter, or you could click on the plus icon next to the word to expand it and select a more specific filter.  I thought this was straightforward, but our user was double clicking on the terms.  I was baffled at first, but then I realized that she was using her experience in the old Windows Explorer where you would see folders with a plus icon next to it, and you could double-click to open it up.

Take aways

We had not run any of the user interface by real customers, only internal stakeholders.  If we had, we likely would have discovered some of the difficulties the users would have with our design.

I would suggest that if you are developing software for other people to use, you should try to get some real users in front of it, give them some simple tasks, and watch what they do, even if you have already gone live.

– talking to the customer uncovers assumptions made by everyone
– talking to the actual user uncovers flaws in the solution
– easily identify small changes that can really improve customer perception and user experience

Advertisements

Quick Tip (Free stuff)- May, 7, 2015

As promised, I am continuing to supply quick tips.

At my previous job, we utilized AWS heavily, and I had the opportunity to play with some of the features it offered.  It was great to have the ability to spin up an instance of just about any operating system whenever I needed it.

I am not longer at that company, and I needed the same ability.  It turns out that Amazon offers 1 year of free access to many of their AMI’s (machine images) and other services.  The free access is limited to tiny instances, but I have found it really useful to be able to spin up something for a small task and then just trash it when I am done.

I am currently using this resource to help me do some coursework (on Coursera.com, learning about programming for Android).

Searching for the why

I have recently started a new job.  The company is still very small, and has been operating in a very start-up mode.  When they brought me on board, they wanted to start implementing new processes.  Since I am very passionate about this, I was very excited.

I have a very agile mindset, and believe that the team should be very involved in defining the processes that they use, and have the ability to modify those processes when they are not working as well as they would like, or even working against them.

Developer Summit

One of our developers works remotely, so in order to facilitate discussion of what processes we wanted to put in place, the company flew him to the office and we had a 2 1/2 day developer summit.  We didn’t do any (or much) development during this time, but simply used the time to talk about how we wanted to work.

During our discussions, we, thankfully, agreed quite often on what we felt was the right process for us.  But, our discussions were more than just a checklist of “we should do a, b and c”.  We often talked about what we wanted to do, why we wanted to do it, and what that process or practice would allow us to accomplish.

At the end of the summit, one of the more junior developers mentioned that she really enjoyed the summit, and was happy to hear us explain why we wanted to have the processes we talked about.

Why the why?

Years ago, I realized how important explaining why was to our line of work, and I got myself into the habit of always explaining “why” when discussing something the team had not previously discussed.  I also, try to restate the why periodically just so everyone remembers why we do what we do.  It is very easy to get into the habit of doing something, and forget why you started it in the first place.

So, why is “the why” important?  Why can’t we just state that our process is x and execute on it?

I can think of 3 reasons why knowing the why is important (I am sure there are more).

1) Knowing why a process was put in place makes it easier to remember what the process is and explain it.

When a new employee starts, it easier to explain a process when you understand why the process is in place.  Also, for me, knowing why can often make it easier for me to remember the actual process, especially when it is something that is not used very often.

2) Knowing why a process was put in place makes it easier to know when to not follow the process.

I live by the rule that we control the process, and the process does not control us.  A process is there to make our lives easier and allow us to do our jobs more effectively.  Sometimes the process will get in the way and make it harder for us to do our jobs.  In those cases, we should be able to weigh the benefits and costs of not following the process for this one instance.  If we do not know why the process is in place, we will have a much more difficult time weighing the effect of skipping the process.

3) Knowing why a process was put in place makes it easier to know when that process no longer makes sense.

As I said earlier, we are in charge of the process.  Sometimes processes are put in place that make sense when they are initiated, but over time, the benefit of the process goes away, but we continue to practice it.  Knowing why a process is in place, and what benefit it brings allows us to revisit these processes, and decide if it is time to retire it.  This is why it is important to restate the why every so often.

Not just for processes

Understand the why is not just useful for processes, but also for coding standards, code techniques, design patterns, etc.  Understanding what these things are is important, but it is just as important to understand why we would want to do some of these things.  This helps keep us from applying techniques inappropriately, and helps trigger our memories to apply the technique when it makes sense.

Summary

I encourage all of us to look at what things we do and understand why we do them.  If we are doing things that no longer give us any benefit, then really think about whether we should continue doing them.

I also encourage everyone to make it a habit to state the why when talking about a new process, and restate the why occasionally, especially when new people are around, but even when it is the same people as always.