February book: Rocket Surgery Made Easy
I had originally planned to read a book about form usability this month, but one of my goals for the year was to try out usability testing. Last month's book, Steve Krug's Don't Make Me Think, convinced me to try, and we needed to go live this month with some Very Important, Highly Visible features on our internal portal that everyone in the entire department needs to use. Don't Make Me Think's promises of immediate, valuable feedback on usability problems from doing usability testing convinced me that NOW was the time, hence the switch to Steve Krug's other book, Rocket Surgery Made Easy, which focuses on doing informal, cheap, and easy usability testing, and suggests what to try first when trying to fix the issues that are inevitably discovered during testing.
It was an easy, fast read, so I was able to finish the book in time to use its advice to guide our very first usability tests AND fix most of the issues we discovered during testing before going live. The testing was a smashing success. The value was immediately apparent right from the very first test we did. My boss is completely convinced (he had been skeptical that there'd be enough return for our effort, considering how small our dev team is), as are the other devs and project owners, and we're now trying to figure out if there's any way we can implement usability testing on our smaller projects. I am, in a word, thrilled.
One of my ongoing challenges has been trying to learn how to improve UX and UI of our internal apps in a world focused on commercial development. We don't have to worry about losing customers to these issues, but that doesn't mean UX and UI don't matter. Making our apps easier to use means our coworkers are less frustrated and more productive, which still impacts the bottom line and saves the taxpayers money, but it's more indirect, harder to see, and rarely acknowledged. Unfortunately almost everything I've read about UX and UI is written with large-scale commercial development in mind, and not all of the concepts are transferable to our situation, nor are many of the suggested methodologies things we can even do (particularly with respect to formal UX testing).
So I was beyond excited to see mentions of the mere existence of internal business apps, even if they were brief. The book discusses usability testing for intranets (close enough!) , makes recommendations on how to select testers for an intranet, and even mentions the fact that improving an intranet can translate to cost-savings. It felt like a minor miracle to see that in print, for once. And those tips guided me in finding a way to implement usability testing on a budget of $0.
I highly recommend this book to anybody who isn't already doing usability testing. It's quick and easy to do, and the return on investment is incredible. You can read more at Steve Krug's website, including a sample chapter, and see a demo of the basic process.
For those who won't click through, the basic process is to come up with tasks and have one person sit with a user while they complete the tasks, thinking aloud the whole time. The book covers the entire process, including scheduling tests, coming up with tasks, finding users, what tools to use to record and share the testing, tips to keep the user talking without interfering with the testing, how to go about fixing the issues you find, etc. etc. and is well worth the twenty-something bucks from Amazon to steer you through all the necessary steps. It's so simple, yet uncovers a truly surprising array of issues that are invisible to the dev team and other involved stakeholders who are just too close to see them, plus issues that testers won't think to report because they were able to recover, even though they do negatively impact the user experience.
And just for the record, yes, I'm aware that the official correct answer to usability and user interface design issues is "hire a UX expert and a designer" (a point that is also included in the sample chapter linked above), but in the real world many, many dev teams don't include either of those positions and have no hope of convincing the people in charge to add them. I'm sure the value added by such experts is immense, but there's no way our tiny team will ever be able to hire them, so here we are, doing the best we can. ¯\_(ツ)_/¯ Rocket Surgery Made Easy is meant for teams like ours, to advise us to do what we can to make things better, and it succeeds admirably.
Anyhow, two thumbs up! Next month I WILL get around to the forms book, Designing UX: Forms by Jessica Enders.
It was an easy, fast read, so I was able to finish the book in time to use its advice to guide our very first usability tests AND fix most of the issues we discovered during testing before going live. The testing was a smashing success. The value was immediately apparent right from the very first test we did. My boss is completely convinced (he had been skeptical that there'd be enough return for our effort, considering how small our dev team is), as are the other devs and project owners, and we're now trying to figure out if there's any way we can implement usability testing on our smaller projects. I am, in a word, thrilled.
One of my ongoing challenges has been trying to learn how to improve UX and UI of our internal apps in a world focused on commercial development. We don't have to worry about losing customers to these issues, but that doesn't mean UX and UI don't matter. Making our apps easier to use means our coworkers are less frustrated and more productive, which still impacts the bottom line and saves the taxpayers money, but it's more indirect, harder to see, and rarely acknowledged. Unfortunately almost everything I've read about UX and UI is written with large-scale commercial development in mind, and not all of the concepts are transferable to our situation, nor are many of the suggested methodologies things we can even do (particularly with respect to formal UX testing).
So I was beyond excited to see mentions of the mere existence of internal business apps, even if they were brief. The book discusses usability testing for intranets (close enough!) , makes recommendations on how to select testers for an intranet, and even mentions the fact that improving an intranet can translate to cost-savings. It felt like a minor miracle to see that in print, for once. And those tips guided me in finding a way to implement usability testing on a budget of $0.
I highly recommend this book to anybody who isn't already doing usability testing. It's quick and easy to do, and the return on investment is incredible. You can read more at Steve Krug's website, including a sample chapter, and see a demo of the basic process.
For those who won't click through, the basic process is to come up with tasks and have one person sit with a user while they complete the tasks, thinking aloud the whole time. The book covers the entire process, including scheduling tests, coming up with tasks, finding users, what tools to use to record and share the testing, tips to keep the user talking without interfering with the testing, how to go about fixing the issues you find, etc. etc. and is well worth the twenty-something bucks from Amazon to steer you through all the necessary steps. It's so simple, yet uncovers a truly surprising array of issues that are invisible to the dev team and other involved stakeholders who are just too close to see them, plus issues that testers won't think to report because they were able to recover, even though they do negatively impact the user experience.
And just for the record, yes, I'm aware that the official correct answer to usability and user interface design issues is "hire a UX expert and a designer" (a point that is also included in the sample chapter linked above), but in the real world many, many dev teams don't include either of those positions and have no hope of convincing the people in charge to add them. I'm sure the value added by such experts is immense, but there's no way our tiny team will ever be able to hire them, so here we are, doing the best we can. ¯\_(ツ)_/¯ Rocket Surgery Made Easy is meant for teams like ours, to advise us to do what we can to make things better, and it succeeds admirably.
Anyhow, two thumbs up! Next month I WILL get around to the forms book, Designing UX: Forms by Jessica Enders.
Comments
Post a Comment