views:

70

answers:

5

I've been working on a long-term project for over a year now and love every minute of it. However, I find myself getting increasingly out-of-touch with my users as my perspective of the same project is drastically different.

In my case, I know how to get from A-B very quickly in 5 different ways. But, if a typical user and I were placed in the same situation, I fear that I would not empathize enough to understand struggles with the user-experience or functionality.

How can I retain this empathetic view of my users whilst still knowing the inner-workings of the monster inside and out?

I'm looking for any tips/tricks that developers can use rather than hard-core UX testing with 3rd parties.

+4  A: 

We follow the scrum development process, which includes a "demo" session after each development cycle (typically 3-4 weeks). We invite everyone across the company, as well as a few select customers, to see what we are up to. This enables us to get quick feedback into new features, as well as keeps an ongoing relationship between the devs at the end users.

jheddings
+5  A: 

In our case, I'm actually "shadowing" the users to see what they actually do.

Not what they claim they'd like to do. Or what the think the requirements should say.

But what they actually do. It's better than endless rounds of requirements meetings.

S.Lott
That's very valuable... We find that our customers often come to us with a "solution" they cook up on their own. Sometimes they are on the right track, but often times there is some other underlying problem they are facing. Shadowing them helps to identify those root issues.
jheddings
In some cases, it's something really, really silly. Someone in the user organization can't copy and and paste (for whatever reason). This blows out of proportion into a huge project. To fix a tiny problem with copy and paste. It's important to know the real context for the "requirements".
S.Lott
+2  A: 

Lightweight UX testing, even if it's with the person down the hall trying to do just one thing, is a great way to get out of your own head and see the interface with new eyes. (Just curious, why not do this?)

I know you're looking for non-UX testing answers though, so one suggestion I'd make is to simulate that outcome by imagining yourself as a particular type of end-user (for example, pick an appropriate career, first time or nth time using your software, trying to accomplish some appropriate - or inappropriate but plausible - goal). If you can imagine it in enough detail (esp if you have some 3rd party user in mind), you can start seeing the interface the way they might. Astonishingly, it actually works.

Andrea
+3  A: 

I would suggest:-

  1. Sit with your users for a day as they use your application. You will see them doing all sorts of things, and immediately have a long list of ideas for improvement.
  2. Talk to them about their problems, not their proposed solutions for your application. You should be better at software design than them; they should be better at understanding their problems.
  3. Consider what you can do for your customer's customer to make their life easier.
WW
+1  A: 

This is a difficult issue for me as well. I find that setting aside blocks of time for each 'responsibility' helps. For example, while testing a series of screens I'll grab a pen and paper and do my best to put myself in a typical user's perspective. If I find something confusing or off I write it down and continue rather then fixing it right then and there. Even if it's a small 5 second fix I find that opening the code breaks my mojo and I end up right where I started. Getting into the groove and staying there seems crucial in these situations.