I’ve been avidly following a discussion on the anthro-design list about guerrilla research and thought that perhaps my reply as both a traditional researcher and a guerrilla researcher may be useful to those who follow my blog. So, here it is!
Little about me:
Academically, I am finishing my masters degree in applied anthropology in 3 weeks where I focused on cyber anthropology – or studying culture online and using virtual research methods (as long as everything goes according to plan). Additionally, I am starting my PhD in 4 weeks in Human Computer Interaction.
As far as work experience I have 13 years in the computer industry and over 10 years in the fields of software development (JCPenney internal marketing applications that serviced over 5000 internal employees and over 1000 stores), graphic design (various jobs over the years from traditional print to web design), and user experience including positions as interaction designer (school information systems), information architect (at an interactive ad agency), and user interface engineer (designing HR software) / designer (designing mobile, desktop and web tools).
My Experience:
In all of my experience I have rarely ever been able to properly conduct user research. Even the one time I was given the go ahead to do so the recruitment methods which were performed by the product management team were so awful we only had a total of 6 people participate!
This means I’ve had to utilize any opportunities available to me to conduct ‘guerrilla research’.
Methods I’ve used include:
‘Participant Observation’ – I sat in on and participated in training classes where support people were being trained on current versions of software and were able to voice their concerns for themselves and their customers. I was able to take this information plus a heuristic review of the software’s current state and use that as my basis for what challenges needed to be tackled in the new interface and process design.
Subject Matter Expert (SME) interviews. Here is where I went deeper than the stakeholders or even those that called themselves SMEs and ferreted out those people who had to be SMEs not because it was their job title, but because their positions within the company required them to be. I found a great source to be the Sales department (and sales engineers) of all people. Why? These people are the ones on the front lines trying to sell the software. They are the ones that do the most competitive research and are asked the most questions by both potential customers who are shopping around (so I saw in this demo by this other company they did it this way – why do you do it different?) AND existing customers looking to upgrade (so why should I upgrade to the new version when the version I have does everything I need it to – or the current version is no longer meeting my needs and I’m not sure the new version will either – why should I stay with your company when I need this, this, this and this that you have yet to offer). Additionally, these people are GREAT to reconnect with after you’ve done your job and they are selling the software you’ve designed as they can give you both potential and current user feedback on it that they receive during demos!
Developers, developers, developers… They get such a bad rep because they are seen as the ones that just do the behind the scenes plumbing and aren’t as concerned as how it should operate on the front end. This, for one, isn’t necessarily true and in most cases is a simply out dated notion. Though many aren’t sure what to do on the front end, once you give them prototypes or wireframes and actually talk to them about your ideas they can help you expound on them 10 fold because they know how the system works, why it works the way it does, the current pitfalls, and ways to not only improve the front end based on all of this information but also ways to improve the backend which also has implications for user experience especially in terms of things like errors and page loads etc etc.
Online forums! Getting out there and seeing what people are actually saying about previous/current state is a huge help. Though it can be damaging to the ego once they start talking about YOUR contributions to the project, it is definitely a place to gather at least unabashed criticism and sometimes helpful suggestions to the product.
Stakeholders – really, I go to these people last. Especially in terms of product managers. They have too many people to answer to, to be in the right mindset of user experience most of the time. Though I’m not their adversary, I look at myself as the user advocate and the person that has the user’s voice when things come up where they might want to sacrifice usability and accessibility needs for niceities/unnecessary features/timelines.
More traditional methods done in a guerrilla way:
Site visits – can’t stress this enough. Though we only got a chance to visit two offices, just being able to see the tools they work with (monitor size, the size of their browser windows, how busy their office is etc etc) were very insightful.
Phone interviews – these were most helpful when the user already answered a set of predetermined questions up front and the phone call was used to expound on them.
Journals – having users take screen shots of problem areas and talk about them prior to our visits or phone calls was very helpful in that it got them thinking about where their problem areas were and it saved us time in that we could jump right into issues they were experiencing in the WAY they were experiencing them even if we couldn’t be there to see how they got to the issue, why they got there, or how they had to satisfice their way around it at the time (and all previous times).
Card Sorting – we had several different types of people across two offices take a stack of cards with navigation points on it and asked them to sort them in what they would most navigate to in terms of top level navigation and where they’d classify the rest of the cards beneath that top level. This was very insightful and helped our client see that yes 13 top level super cats was a bit ridiculous.
Shadowing internal users – when you have the opportunity to develop for in-house clients shadowing them is one of the least obstructive and most informative research methods I’ve been able to perform.
Examples of work:
If you’re at all interested you can find out more about my work via my resume, and my portfolio, which doesn’t include anything from my current job – but you can see an example of the work I’ve done for them here.
Let me know if this was useful!
