I’ve been working in software for my entire professional career. Except for the past year, I’ve been a backend software engineer for backend code in data platforms, web apps, and operations. Throughout my years as an engineer, I’ve neglected studying design. It’s always been the elusive facet of product development that Ive appreciated, but never come to understand.
I’ve dabbled in different design tools to create sample mockups for products I wished to build, but I always copied what looks good instead of putting design pieces together. This year, I wanted to change my perception of design and learn how a designer thinks when working on a project. To start my journey as an amateur designer, I thought best to begin with the fundamental books about web design. That’s is how I was led to Steve Krug’s book, Don’t Make Me Think.
I started reading it with high hopes. It began with a friendly welcoming attitude to the world of design – a world I had only experienced from the outside. With Krug’s definition of usability, I learned some basic principles that I had only heard vaguely mentioned by colleagues in the past. However, after these abstract principles, I felt the rest of the book wasn’t as helpful as I was expecting.
Written in 2000, but updated in 2013, there were a lot of concepts that have been outdated in today’s web world. The majority of the chapters were written with concrete examples, and while some layout tips might be applicable to today’s modern apps, the rest were artifacts of an older browsing history.
Obviously, rapid changes are extremely difficult to account for when writing a book about the design of the web. Because of this difficulty, it would have been better to have discussed the top usability concepts, rather than specific examples. A great example of this issue is the entire chapter dedicated to the Home page.
Another nit picky problem I had while reading was the unnecessary amount of book recommendations. It’s one thing to source where a concept has come from, but it’s another to introduce the importance of a specific usability application (e.g. font styles and sizes), then spend a few sentences introducing it and instead of summarizing it, recommend an entire book on the subject. I came for a distillation of usability principles and applications, not to build a library of books that I’m never going to get to.
The worst offender was the accessibility chapter. Two of the four recommendations to fix the problem of accessibility was to read an article and another book! That’s not the type of advice I’m looking for when I’m reading a book about usability.
Nonetheless, I did learn a few interesting helpful tips about usability. The chapter on usability testing and DIY testing solidified some high level understandings I had about user testing. There were also multiple instances where I said “ohhh” out loud after learning the “why” behind UX concepts (e.g. goodwill reservoir) that I heard colleagues mention but never clarified.
Unfortunately, these instances were short and far between. Instead, I had to wade streams of light-jokes and quirky writing that got annoying after awhile. Even the random off topic footnotes the author injected got tiresome by the end. I get that he was trying to give the text some mensch, but it wasn’t landing for me.
Overall, this wasn’t the book I was hoping for. I wasn’t trying to get buy in from my manager to perform usability tests. I wasn’t trying to compare UX to usability. Instead, I wanted to learn about some core principles of UX and design that I could use in my daily workflow. I guess I’ll have to keep looking.