The Essence

I just finished reading Rocket Surgery Made Easy, from Steve Krug. This book is a practical book on how to start thinking about user testing and introducing it into a design process that doesn’t current perform testing (or as much as it should). I got this book to help me reflect on my current position at work and also some of the lessons learned from graduate school. It’s a book I recommend to start thinking again on getting user feedback and the pressures of designing in the “real world”.

Take-aways

There are a number of good design points to take away from this book, which I’ll quickly describe (if you get the book, you can get to the essence of these points too):
- Nothing is free from problems
- Testing and getting feedback is the only way to improve a design
- “A morning a sprint”: try to get as much feedback as possible in agile
- “Anybody is better than nobody” mentality
- Knowing who and what to test
- Always prepare your scenarios and every aspect of your test
- Get the team involved, and get action items the same day of testing
- Fix the big stuff first
- Try not to be so subtle: sometimes the best design is “in the face”
- The power of remote testing: handy when you can’t be in the same room

Critique Points…

There are a number of worthy items to take away from this book, but there’s also some points I want to mention to help draw out the nuances of this book:
- How do I test if the team has the “get it out the door” mentality?
If your organization or team has this type of mentality, they already are going to be resistant to putting their work in front of users, as it pretty much isn’t their concern any more. Trying to convince them to stay and try to improve the design means incurring more work, and possibly less profit.

- How do I get thick skin to fight against the above mentality?
There’s really not that much here in this book on this issue. There’s a couple mentions of that “your team and your stakeholders will find it interesting to watch and get involved in the process”. From what I’ve seen at my job so far, this is as far from the truth as possible. This is a cost that is seen as not justifiable, and as long as that is the mentality, there’ll have to be other “battles” to fight.

- What is the real purpose of user testing?
From my grad school experience, this is a fundamental question that we learn for the whole first year: why and what you test in your design. Do you want to test the experience, a part of the design, how people think of your design, etc. Knowing this is the essence of testing, and getting at the most fundamental question in the design process in regards to testing: what do you want to learn? I feel that only by doing design and the whole process can you end up learning how to answer this question, which makes a basis for your testing.

- What really is the role of the moderator?
From Krug’s perspective, he gives two different perspectives: a tour guide and a therapist. While these are meant to be metaphors for helping to keep people focused on their tasks and always talking, these terms imply there is a single destination to go. I think it’s a good thing during the testing if you get lead down a path that the user brings up, especially if it helps to spur new ideas for you and your team. But, like a therapist, this takes a judgment call on when to allow this.

- What really is at the foundation of user testing?
This book starts to tease out where the foundations of user testing really lie – from the deep desire to iterate on a desire and know what you want to learn. But there’s still another element that isn’t reflected on in this book, and it’s the power of human judgment (an essential double-edged sword of the design process). The ability to judge what to do, and how to do it, is a judgment call that is only refined through practice and years of experience.

- How do I advocate for testing and user feedback if I’m not “running” the show?
There’s really not that much here in this book if you’re in this situation (similar to my current position). This book is aimed more towards a person who wants to learn and has traction in their organization to advocate for testing and user feedback. The only recommendation I have is to keep trying to convince your organization that the only way to deliver better products is to stop designing for oneself and ask the people you are designing for their feedback as often as possible to avoid big fixes down the road.

Ultimately…

I’d recommend this book to you if you would like to start to get to know the essence of getting feedback from users if you have never done so before. It’s also really good at helping you see the need for testing, as it is a prime means of iterating on the design a team is working on. This book will also get your mind going, helping you to say “Why aren’t we doing this? It’s actually pretty easy and important”.

This book also gives a very good starting set and mentality for doing appropriate user testing. There are a few things, though, that it doesn’t help you with: helping your organization against the inertia of non-testing, helping to garner buy-in from the team of why you should be doing this to begin with, how to secure the means (financial, and people-related) to physically conduct the user testing, and helping to defend your results from scientific inquiry (or from skeptical members of the team). Since this is a layman’s book, it is great at getting you going – to help you get full merits of “scientific” testing, I’d recommend the book “Measuring the User Experience” by Kuniavsky. It’s bigger, but gives you more in-depth into the thinking of a designer that you’ll need to get the feedback and data you need to make your design better.

Overall, though, still a very good book, and a fun read. Because that’s important, too.