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.

Comments

Post a Comment

Popular posts from this blog

Git. The WHAT and WHY Edition.

-
Image
Lately I've seen a lot of new/aspiring developers talk about difficulties learning git . I was confused at first, because there are approximately a zillion git tutorials out there. But then I started really looking at what people were saying AND what all those tutorials contain. The problem is most tutorials start out with "here are a ton of git commands to memorize", and this is not where people are having problems. People are having problems with "what is git, why should I learn it, and what does it look like to use it in a real-life project?", and those questions are largely not answered in all those millions of tutorials. So at the risk of redundancy, I'm going to attempt to address these questions in Yet Another Article About Git. First, I want to make it clear that if you want to be a programmer, any kind of programmer, you need to know git. You just DO. This is the short version of the answer to "why should I learn it?".  The medium length a
Read more

"Does it get easier?" Yes, but Also No...

-
Image
Image by Arek Socha from Pixabay It's complicated... "Does it get easier?" I see some form of this question asked a lot in beginner programming groups. I always struggle with how to answer this honestly and clearly, because the truth is not that simple. In some ways it does get easier, but in other ways it is almost always going to be difficult if you are advancing in your career . If you are a programmer and your job is easy for years on end, the most likely explanation is that you're in the kind of dead-end position that people try to avoid, not the kind of position people dream about when they think of becoming a developer. Most likely you are not getting better at being a dev, not working with new tech or solving new kinds of problems, not being given more responsibility, etc. etc. etc. I've seen some pushback from other newbie programmers on the idea that it could remain difficult past the initial learning stage. Notably I have never once seen somebody who
Read more

How to Land Your First Dev Job: Develop Yourself, Market Yourself

-
Image
Image by magnetme from Pixabay In the coding and tech groups I'm in, I see the same question asked over and over by folks who are just learning to code, finishing up a bootcamp, degree, or other training program, or who have been looking for that first job for awhile and not having any luck: "what do I need to do to get my first dev job?" There's a whole ton of info out there on this topic, but it's scattered all over, so I thought I would gather together the best resources I've come across and share them, along with a bit of context, to try and help everybody struggling with or just plain wondering about this. There are a lot  of things you can do to improve your chances of finding a job and hopefully shorten your job search. They are broadly divided into 2 categories: developing yourself and your skills, and marketing yourself and your skills. Note that you don't need to do everything on this list, nor do you need to do it all at once. This is an "
Read more