2019 Bookmark

The more practical use of this book comes from Kalbach's inclusion of when, why, and how to use the maps he describes. Example maps are provided in varying fidelities along with case studies; I found these useful in thinking of ways I could apply them to my own projects at work. All in all, this is a great read for anyone who needs an introduction to mapping, people who are curious as to why experience (and holistic IoT) is the big new thing for value, or for the consultant on the road needs a nice reference book when diving into a new project.

It is incredibly easy for anyone who is familiar with the process to pick up the book and quickly find a method to solve their need at hand. However, due to the brevity of explanations (usually limited to a page or two)- many of the methods come off as something I couldn't pick up and use easily. I would have personally preferred a smaller set list in exchange for more quality instructions and guidance or resources for follow up learning.

Upon completion I've become much more aware of the interactions I have with my own google home device and the many intricacies that make it tick. There are so many new things to consider as UX designers as the world's digital devices become more and more human, so I can't recommend this book enough. Please read this. This is a part of our collective future.

She breaks this down by explaining that empathy is a noun- a thing. You can't apply it until you've developed it first by listening to someone. Too often, people confuse this "use of empathy" with empathy itself- and that's a huge problem. Assumptions are dangerous, and Indi rightfully explains the havoc it can cause to organizations both internally and externally.

Indi also does a great job of explaining how to listen. It's about simply absorbing and understanding what's being said without holding any underlying agendas. Some of my favorite tips included: resist the urge to demonstrate how smart you are, use the fewest number of words to nudge a neutral response, avoid offering advice, and let the speaker choose the direction.

As much as I love this book, I wasn't very engaged in the final few chapters. There is a full chapter dedicated to listening session analysis, but the persona piece is basically a reskinned version of Cooper's goal-directed design and the affinity grouping part is a summarized version of Dr. Hartson's more thorough WAAD explanation in the UX Book.

All in all, I highly recommend this book. Knowing how to develop and apply empathy is such a critical skill for both work and day to day life. Buy this book, bring it to your office, and evangelize!

First, many of the interviews put the hustle and sweat needed to create a success story front and center. It’s a humbling lesson in the utmost need for hard work and risk taking that differentiates great from good. Second, it’s comforting to know that many of these superheroes have experienced the same kind of human failures, discomforts and anxieties that I catch glimpses of in my budding career. I appreciate the authors for consistently asking questions regarding failure; many of the best and most insightful responses came from the reflections that followed.

My biggest takeaway from this can be summarized as: hustle harder, surround yourself with good talent and just do it.

Although I didn’t learn too much more about the underlying methodology of interviewing, there were still many useful case studies, insights, references and rabbit holes that kept me engaged throughout. Portigal also provides many helpful artifacts as references to create your own interviewing guides, documents and more. My favorite chapter was easily “How to Ask Questions” (chapter 6) which provided a list of useful contextual questions to ask; I’ve made good use of this already in my client work.

In reflection, I regret not reading this book earlier in my design career. Knowing the ins and outs of interviewing is a critical skill to have doing UX research, and Portigal masterfully covers the most important bits in an easily digestible way. If you are a beginner UX’er, this is mandatory reading!

The purpose of CM is to get the product’s concepts and their relationships right to enable a desired task-flow. While I don’t disagree with the many arguments made by the authors, I wasn’t convincingly sold on why it’s worth the effort of training a team to realign to CM from other existing processes used in mastering concepts and relationships.

To start, I was a little let down that there weren’t any case studies to reference. Although Johnson does reference some of his own work in examples listed in the book, there were no mentions of other companies/startups/etc successfully replicating it. Granted, this is a caveat of the style of the volume “About Synthesis” which I’m relatively new to- the volume’s word-for-word purpose is to provide concise, original presentations of important research and development topics, published quickly.

That in mind, I don’t think Johnson and Henderson were correct in making such a bold statement at the beginning that CM should be at the core of the design of every artifact that people use. The idea still feels very raw and untested in industry; it’s also sold in a similar way with the typical “it will save you money in the long run” statement. I don’t disagree that this may not be the future, but I also have built up industry sentiment that design is about process and creation. If we are able to still create products effectively without CM now, why would I want to add 2-3 additional weeks to the product’s lifecycle? Would it not be better to get an MVP out faster and test?

If I could improve this book I would first change the initial statement to something less definite in favor of something more inspiring and challenging. E.g, “CM could be the future of mastering experience design, here’s why…”- yea fuck it, I’m not qualified enough to rephrase that thoughtfully enough. Second, I would provide more case studies and examples conducted by others showing that the process is easily replicable. Third, I would make the example documents downloadable; making the process more easy to pick up would encourage more replication and usage right? Finally, this is definitely not worth $30 bucks for the length and format of this book; I can honestly see the information in this book being packaged into a powerpoint without that much difficult.

I know I said a lot of rough stuff, but you should still really read this book! I still love the thought and reasoning put into why CM works from safeguarding against vocabulary mix-ups to managing version updates. All in all? Started at a 3/5, but it’s Johnson, so I’m giving it a 4/5.

By comparing digital “places” (instead of products) to more traditional building architecture, I’ve grown a more holistic understanding of what I create as a designer. My biggest takeaway from this read came early on when Arango discussed the nature of context. The “products” we create are so much more than just products since they introduce new contexts in which our users interpret and act with the world- hence they are digital “places.” It is thus in our duty as the architects, or more appropriately the “gardeners,” of such experiences to be cognizant of both the internal processes and external long-term consequences of what we decide to create.

After reading this book, every designer should come away with a sense of responsibility. In Arango’s words, “we must realize the great power we have over people’s understanding of the world and their behavior in it, and wield that power responsibly.”

For example, the book explains in a very beginner-friendly and illustrative manner how to conduct a think aloud session, how crits work and introductory level usability testing techniques. So, all in all, don’t expect too much depth here if you’re a couple of years into the industry; but if you’re a beginner looking for an easy starter book on UX sketching, this is your pot of gold.

Aside from strictly the architecture of his work, Hara does a great job of explaining what makes “white” so amazing- particularly to designers. The creative individual, Hara argues, looks at the empty bowl as a powerful thing. Rather than having no use, it is great in its potential to be filled with something. White represents this potential power found in emptiness that designers need to understand and appreciate in order to use to its fullest magnitude.

Throughout the book, Hara often makes comparisons to Japanese culture and mythology which adds even deeper layers to the story of white. Coming out the end of it, I can’t see white- or emptiness- in the same way I did before. And for that, this is easily a 12/10.

With that in mind, I can’t recommend this book enough to any practitioner in the UI space. Beyond acting as a guide for designing forms, this book is a fantastic way for beginners to reframe their mindset towards inclusive design when making wireframes. Too often, I see designers simply copying what “looks cool” off behance or dribbble without giving a second thought towards the underlying usability of it all. Even when mimicking UX powerhouses like Amazon and Microsoft, we need to remain vigilant that it’s so easy to forget to design for accessibility and that the designers/developers on those teams aren’t foolproof. To motivate myself to design for inclusion more, I’ve made a new goal to start using a screen reader when accessing new websites in 2019.

Please, please read this book. Don’t assume the knowledge you have on accessibility is good enough without properly understanding how it works from design to code and ultimately on a screen reader.

Furthermore, reading about how to use Sketch on physical paper was so much easier to follow than play/pausing an online tutorial (if you know me, you know how much I hate online video tutorials). You don’t get distracted, you’re more likely to follow through with all of the steps, and the book is an aesthetic experience that’s as enjoyable as it is helpful.

For maybe 80% of this read I was kicking myself for not being more thorough in technically mastering my craft. One of the first things that comes to mind is the population drop-off for most software when it comes to becoming an advanced user; good UI (like Sketch) can afford beginners and intermediates room to use workaround or non-efficient techniques to meet their goals. However, this can be a double-edged sword as many users (like me) don’t even consider or think about further mastery if it is A) not necessary or B) not crystal clear on how to get there. Psst, Bohemian Coding please include more modeless tips and better online help documentation.

One minor complaint I have is actually completely out of Krammer’s control. As with any other software book, the Sketch Handbook hasn’t aged so well in some areas. Krammer wrote this book in version 44, and needless to say a lot has changed since then. There was one infuriating part where I couldn’t get Craft to duplicate and randomize my symbols no matter how closely I followed the directions. After a long squinting session from my co-workers and online google digging, I realized that Craft was bugging up with Sketch’s new version. So yea, I wrote an article on a workaround for that if you’re going to read this book too and reach page 170.

A great example of that is in chapter 6: “Parameters of Your System.” It’s simply genius. Alla visually compares and contrasts different company’s design systems on three scales: Rules (Strict to Loose), Parts (Modular to Integrated), and Organization (Centralized to Distributed). Her crisp explanations partnered with the diagrams gave me an instant eureka moment of understanding.

Anyways, it’s getting a little frustrating seeing how much stuff falls underneath the UX umbrella and how lacking I am in areas where I have had less practice. Nonetheless, every time I finish a book like this, I feel even more inspired to work harder. On a side note, I felt a little relieved seeing the typo on page 135 (centralised)- nothing’s ever perfect even when it’s just about at 99.999% in the case of this masterpiece!

Without a doubt on mind this is a must-read for anyone who ever has to visualize anything within their field of work. I am fully aware that Stephen draws a line between a dashboard and an analytical visualization, but many of the recommendations and tips he provides are still incredibly relevant to UX designers who specialize in making the former for clients.

My favorite part of this read was being introduced to trellis visualizations. They are amazing and will undoubtedly empower my future work. If you want to learn more about them, do read the book!

The problem is, Hugh MacLeod has a very particular and narrow approach to creativity that is ironically more of a nebulous key to his own demons than actionable help to anyone else. Honestly, most of the “39 keys” in fact are hardly any more than “no shit” statements. Even when there were at times thoughtful ideas, they didn’t have impact as consequence to the character Hugh illustrates himself as. Whereas a David Goggins may have legitimate say in thought-provoking statements on toughening up, Hugh MacLeod comes off as a childish, spoiled, egotistic sex maniac who never really did “suffer” beyond living at a YMCA (which is hardly suffering at all for anyone who has actually been through shit).

Ultimately even if Hugh’s advice results in creative success, the lack of human joy remains as the haunting elephant in the room: both in the book, and in Hugh’s unnecessarily cynical perspective.

Few also explains the how and why behind good dashboard design instead of simply writing out what to do. It was very reminiscent of Johnson’s Designing with the Mind in Mind as Few focuses on the cognitive psychology behind his design choices.

The best part though? Easily the last chapter where Few goes into dashboard design god mode by analyzing various student performance dashboards and one-upping them all with his own masterclass piece of work that is ingeniously put together down to the pixel. I’m super inspired to use bullet graphs a lot more in my work!

Mark starts by calling experiences “emergent.” That means it might be shaped by us designers, but it can never fully be explained and predicted by objective conditions and transformational rules. “Experiencing” is a continuous stream, emerging from perceiving, acting, thinking and feeling. In other words, since so much goes into what makes an experience, it’s almost impossible to break apart. It’s temporal, it’s dynamic, and it’s complex.

So what’s the difference between Experience Design and HCI? Unlike Usability Engineering and traditional HCI fields, Experience Design isn’t just about addressing the pragmatic qualities of a product. It’s not about addressing just the “what” and the “how”- but gives light to the hedonic quality a product can deliver. It’s about the “why” in achieving “be-goals.” To give an example, if we were to design a video game through a rigid usability engineering route/HCI route, there would just be a button called “win the game.” It’s efficient, yes, but it doesn’t deliver the hedonic qualities that make video games so enjoyable to the natural curiosities of human beings.

Mark is giving us a challenge here. Let’s not focus strictly on fixing problems, frustrations, and stress- let’s up our level and design for joy as well.

He organizes them by six minds: vision/attention, wayfinding, language, memory, decision making and emotion. I’m a little mixed on this. On one side, it’s a time-saving and unique approach to contextual analysis, but on the other, I struggled during an example he provided to accurately group the WANs into their appropriate categories. Whalen notes that the designer should be able to point out which “mind” is the best fit for each WAN, but I’ve heard other lines of thought that such items should be duplicated instead. For example, a WAN could fall under both memory and wayfinding, but by selecting only one of the two as the primary “mind”, we may risk hiding important data for future reference.

All in all, I still very much enjoyed this read. There was a delightful bit on AI at the end, and Whalen masterfully simplifies very complicated thought into a book that can be easily read by just about everyone.

Marty categorizes product culture into two dimensions: consistent innovation and execution. Basically, that means that companies must always come up with valuable solutions for customers while ensuring a successful and shippable delivery.

I absolutely agree with this, and I loved Marty’s focus on the value of qualitative research and the flaws of product roadmaps. Rather than trying to set in stone how we approach the problem, Marty values falling in love with the problem itself and being flexible with the approach. There are so many bits in this book that are goldmines for designers trying to argue for the value of user research in business terms. For that alone this is a must-read, but there’s also so much more to learn from with a holistic product perspective to step out of a siloed design mindset.

Bill and Dave begin the book with “You Are Here” boldly written on the cover. They make an important point that regardless of where you are, you are not too late and not too early. Design thinking, in this context, is meant to help people move forwards through a personalized problem finding and solving process. Many of the information that followed was a review for me from other Stanford-esque design thinking inspired reads (if you are a young designer, Creative Confidence would be a better starting point; otherwise, this is a great intro for everyone else).

However, I found the chapter on networking incredibly resourceful. I HATE networking. I was never the biggest people person, and I grew up being anxious about bothering others. The book managed to break my misconception that networking is “just hustling people.” As Bill and Dave put it, “Getting referrals to people whose stories would be useful to hear is just the professional equivalent of asking directions. So go ahead-ask for directions. It’s. No. Big. Deal.” The point of a network isn’t to “do” it- the goal is to participate in it. By doing so, you can focus on pursuing offers instead of looking for jobs.

Just for that one chapter, I’m going to give this a favorite. I can’t recommend this book more to my fellow introverts.

In many ways Melinda Gates takes on the role as user researcher in her travels to better understand the needs of women across the world. I see her extraordinary effort as a motivating inspiration to designers on the importance of going out into the world of our users to design the right solutions. Her thoughts and challenges are both humbling and insightful.

Don’t sleep on this book. This is a must read.

Basically, in the emergence of disruptive technology, companies that focus on their current users’ needs will be unable to keep up when said technologies take control over the market. Unfortunately, large companies then end up trying to force those new technologies onto their existing market which creates a mismatch in needs.

This makes complete sense, and immediately made me think of Ries’ Lean Startup and Marty’s Inspired. No matter how much we research and try to make an awesome product- it doesn’t matter if we apply it to the wrong group of people. In other words, preparing for disruptive technology is more of a marketing question.

I also think it is inherently a design question too. A good designer does not see a product as something that exists in a user-only vacuum, we need to be able to examine its feasibility from all perspectives including cost and time. That means we need to be smarter on how, when and where we do research. More lean methodologies a la Eric Ries should be a part of every designer’s mental toolkit so they can be ready to handle situations akin to disruptive technology where the answer isn’t just more research and lab testing.

Paul is right. Emotional empathy has no place in decision making when it comes to most things that require professionalism. It also has a time and a place in personal relationships too. Paul himself says it is similar to other emotions- too much of it is bad and none of it is also bad. I 100% agree with this, and this book has made me careful in the way I use “empathy” when describing my work.

On the flip side, I thought his approach was unprofessional. The title “against empathy” and his revolutionary language feels overly dramatic. It contradicts many of his points of using logic. I say this because if Paul really wanted to change the minds of people, he should have approached this in a less polarizing manner and found different value propositions to encourage a switch (particularly towards people strongly attached to the idea of empathy). That, ironically, requires cognitive empathy. Using logic to convince people to believe in logic is illogical, and this is Paul’s biggest flaw. He assumes from a very much privileged opinion that logic is an accessible commodity- but it isn’t. I say this as a designer who has worked on state SNAP and medicaid programs. We are not supposed to design things assuming users are logical. We design things from a “nudge” perspective a la Richard Thaler or a “switch” perspective a la Chip and Dan Heath.

Anyways, from a designer’s perspective, empathy is incredibly important. By empathy, I mean cognitive empathy. Cognitive empathy, unlike emotional empathy, is about active listening and understanding users rather than reflecting their emotions viscerally. For example, when we conduct an interview, we need to be as neutral as possible to avoid biasing responses- but our goal still is to understand the subject deeply from their perspective.

Although emotional empathy is bad in this context, it is still incredibly valuable in getting clients to make a switch. In other words, if we want to convince the client to care about a particular user group (ideally the primary persona because that has a net coverage of secondary personas), we can use emotional empathy as a gut punch to get them to support design decisions- especially if they are stubborn to change.

From a design perspective, this really cuts deep in the realm of research. Too often, in the interest of money and time, we ignore being more deliberate with how we sample users and analyze data. For example, a typical research process in consulting might begin with snowball sampling where a key stakeholder gives initial leads of end users to talk to. Those end users uncover more hidden populations, and research comes to a halt when the analyst feels there is a regression in novel anecdotes…

But what if we deliberately thought about that process from the perspective of gender? Perez documents how women are commonly excluded from “boys clubs.” If we were to consider that in research, the analyst should be more conscious of filling in any potential gender gaps from potentially male dominant snowball samples by ensuring the collection of gender metadata and perhaps the inclusion of gender quotas in the research protocol itself.

An even bigger red flag exists in the fact that the tech/product world is full of men. I am, by my own gender, unconsciously apathetic to the design needs of women. That being said, I find even more significance in Michael Patton’s call for reflexivity (self-questioning and self-understanding) in research: “to excel in qualitative inquiry requires keen and astute self-awareness.” I, as a male designer, need to be held to the responsibility of being aware of my gender and how that influences how I facilitate and interpret my work.

Women are not men. Men are not women. Women make up half of the population, so let’s be more conscious about who we talk to when we conduct research and not make the assumption that the default male can replicate female behavior.