Author Archives: Adeline Crites-Moore

Diana Deibel and Rebecca Evanhoe first crossed paths on a Slack channel back in 2018, where they were seeking out colleagues who might know a thing or two about conversation design… Fast forward to 2021, and their new book on conversation design is finished and available for preorder! Conversations with Things teaches you how to design conversations that are useful, ethical, and human-centered—because everyone deserves to be understood, especially you. In this episode, they chat with Lou about writing the book, the ethics of voice design, and more. 

Diana recommends:

• AmberNechole Hart’s Why does Siri sound white?
• We Should Get Together by Kat Vellos 

Becca recommends

• Design Justice: Community-Led Practices to Build the Worlds We Need By Sasha Costanza-Chock 
• Design Justice Network 

Register for this event. 

Jared Spool has been practicing UX for decades. When Jobs To Be Done arrived, it seemed to him to be just one of those new labels for stuff we’ve always been doing.

Jim Kalbach doesn’t agree. His decades of UX experience have led him to become a strong proponent and practitioner of Jobs to be Done. In fact, he wrote the best book on the topic, the Jobs to be Done Playbook.

Now, Jared is curious. Since Jim is so passionate about Jobs to be Done, has Jared mis-judged it? Is there more to this than Jared originally thought?

Come watch while Jim tries his darnedest to set Jared right. Or maybe we’ll find out if Jared has been right all along, and this is just new packaging for an old practice. Either way, you don’t want to miss this. Register for this event. 

Steve Krug, author of Don’t Make Me Think, and Rocket Surgery Made Easy, is back for a third appearance on the Rosenfeld Review Podcast! Here, he shares some details with Lou about his book in the works, Writing Made Slightly Easier, and his perspective on the process of writing in general (and why he might advise against it!).

Check our Steve’s previous two appearances:
How To Get Usability Testing Right
Life with the Apple Watch and other wearables

Steve’s wise words for writers:
Don’t be afraid to always start at the beginning. Always assume that your reader knows less rather than more.

Steve recommends:
Follow Laura Klein on Twitter

Lou and Jeff Sussna, author of Designing Delivery: Rethinking IT in the Digital Service Economy, examine the relationships between Design and Operations, DevOps and DesignOps, and DevOps and Agile before wending their way to promise theory, which looks at the “promise” made between a product and its user. Color Lou convinced on the promise of product promises!

• Watch Jeff’s presentation at the 2017 DesignOps Summit
• Read Jeff’s book, Designing Delivery
• Listen to Jeff on a previous episode of the Rosenfeld Review, DesignOps in a Post-Industrial World: Crash-Coursing Complex Systems
• Jeff recommends: Mark Burgess’ Thinking In Promises 

Though trained as a computer scientist, Jamika Burge admits she does not have the heart of a programmer; rather, she’s interested in surfacing and connecting with the humanity of the technology we create. Jamika has taken that approach in her past work, including a stint at DARPA (the Defense Advanced Research Projects Agency), where she studied the impact of games on learning. Jamika now leads AI Design Insights at CapitalOne, and is also one of the Advancing Research 2021 Conference curators. Here she shares the story of her career path, and the work she is doing with blackcomputeHER.org (pronounced ‘black computer’), an organization she co-founded that is dedicated to supporting computation and design workforce development for black women and girls.

Jamika Recommends:
Gendershades.org, a project by Joy Buolamwini, Lead Author and Timnit Gebru, PhD, Co-Author

Keep up with Jamika:
JamikaBurge.com
Twitter
Instagram
LinkedIn

Dr. Jamika D. Burge leads AI Design Insights at Capital One. Her team uncovers learning & research insights across multiple platform experiences, including conversational AI, which supports Eno, Capital One’s customer-facing intelligent assistant. She’s an authority on intersectionality of Black women in computing and co-founder of blackcomputeHER.org (pronounced ‘black computer’), an organization dedicated to supporting computation & design workforce development for black women and girls.

Prior to joining Capital One, she served as a research and tech consultant to DARPA, the Defense Advanced Research Projects Agency, in the Information Innovation Office. While there, she provided technical and management consult for innovative DARPA programs which were funded at over $70M. Jamika is also Founder and Principal of Design & Technology Concepts, LLC, a tech consultancy that focuses on computer science education, tech research, and intersectional design. She has consulted for Google, the National Center for Women in Technology (NCWIT), and the American Association of Colleges & Universities (AAC&U). Jamika holds a PhD in CS from VA Tech.

During our “Ask Me Anything” with Indi Young, author of Mental Models and Practical Empathy, we touched on subjects ranging from opportunity maps and research repositories to Jobs to Be Done and empathy as a design concept. Read on for a recap of the session, and please join our Slack here to stay informed about when our next #rm-chat author AMA will be!

Q: I’m wondering if you have any thoughts to share about using empathy as a concept to design for not just people but also the environment or any larger system. -Behnosh N.

A: I have used it and seen it used for designing systems for people, but not environmental ecosystems. Several government digital offices are using my approach to understand people more deeply, to see the differences in approach, to see different thinking styles … and to think in the problem space so as to discover people they’ve ignored.

Q: I’m curious about using the thinking styles approach in developing key archetypes within a body of population health research. Often, patients tend to get heavily sorted by demographic characteristics because they map to certain physical and social determinants of health conditions. But these don’t go far enough to capture attitudes, beliefs, behaviors etc. How have you used the thinking styles frame for rather large and diverse populations? – Jeremy B.

A: What I’ve done is framed several studies by “a person’s purpose.” Often, with health, their purpose is to “cope with,” so for example one study was “coping with my three ongoing conditions.” You must frame by a person’s purpose, so then you can get deep. (either in solution space or in problem space). You can go deep in listening sessions where you help the person trust you and get into their inner thinking, emotional reactions, and guiding principles as they were pursuing this purpose. Here’s my course on listening deeply.

Q: Research ultimately is about learning what we don’t know. Often we’re so focused on who our customers are that we forget that the real work in understanding how we’ve lost or who we’ve failed to win.How do you find, recruit, and drill down to the why of those who were near loses or recent loses? – Arpy. D

A: I would like to see us quit measuring by “engagement” altogether (“hey, someone looked at me through this glass pane!!”) and start measuring by how well we support each thinking style within each slice of their mental model toward accomplishing their purpose. I encourage people to do listening sessions with stakeholders, over and over, like monthly with each stakeholder at first, to develop rapport and trust. But you could totally make thinking styles if you do enough of them!

Q: I remember attending a talk you gave referencing the image below. A challenge I have is to group various user types based on thinking-style. Personae have been used by Agile coaches. I am having a hard time to convince folks to frame users based on thinking style instead of job titles. any thoughts? – Chika A.

A: You can totally use the word persona to mean thinking style, if that works better for your context. Or you can use “archetype.” There is a problem with any archetype that uses demographics to describe the group: invites subconscious bias. (Unless those demographics are related to a context of discrimination, physiology, and a couple of others.) When you explain to someone how demographics cause assumption, they don’t need to be convinced further. Here are two helpful articles: Challenging the Make-Believe in Personas and Demographic Assumptions.

During our “Ask Me Anything” with Tomer Sharon, author of Validating Product Ideas, we touched on subjects ranging from product testing, to lean UX and how to change a company’s perspective on how to do usability testing. Read on for a recap of the session, and please join our Slack here to stay informed about when our next #rm-chat author AMA will be!

Q: What are your thoughts on adding more features to an already somewhat complicated tool that there is potentially not much helpful use out (according to past studies) but is something the higher up’s have said needs to be implemented. I was thinking of doing some prototyping and having interviews with users to see how they interact with addition to help potentially build a case for potentially not adding the feature. I personally think based on my research, they’re not addressing the root use – but the symptom of a larger issue.

A: Proceed with care, but if you are trying to make a point to higher ups, consider running a usability test with them as participants. Sometimes they need to literally be put in their users’ shoes to understand the effect of their requests and decisions. I tried it once and it worked like magic. But I can see how it can go south. If you have data to back up your recommendation, that helps.

Q: I’m wondering what you would recommend for starting out with sharing atomic insights with teams that are more familiar with traditional decks or reports? I would love to start developing and leveraging a research repository, but I’ve been asked to demonstrate a proof of concept using our existing software suites (i.e. Microsoft).

A: I would argue they are eager to get answers to their questions and that the format/tool is less critical. Sway the discussion away from the tool to the essence.

Q: What are some books you’re currently reading that you’d like to shout out?

A: When I read, I always read several books simultaneously. I’m now reading these:

• Thinking in Systems: A Primer
• Little Red Book of Selling: 12.5 Principles of Sales Greatness
• Writing That Works; How to Communicate Effectively In Business
• Atomic Habits: An Easy & Proven Way to Build Good Habits & Break Bad Ones

Q: What have you found to be most persuasive in convincing a team to invest in getting a pulse on competitive research insights?

A: Your best success in persuading people will be to convince them about something they are already invested in. Start with their questions; what do they want to know? Why? What is the knowledge gap? Once you identify it, answer the questions and fill the gap with knowledge. If the gap is about competitive research insights, so be it.

Q: As a UX’er who wears many different hats, do you have any advice on how to reduce fear or anxiety from others who may think you’re overstepping when trying to validate ideas – when you’re really just trying to complete a project that was given to you by your boss? In my case, I’m not a manager but an internal consultant – and as I get more high priority/impact projects – my boss expects me to ask these difficult questions. I’m sensing a bit of annoyance and animosity from those I was originally close with. I’ve explained that I’m there to understand and work with them to improve where necessary and that we’re a team who impact thousands of users so working together to deliver a validate product is really important.

A: It sounds as if you are doing the right thing. My advice is to continue communicating with people directly and openly. Talk with people, not about them.

Q: For a new product, what questions are you typically using to validate interest vs. likelihood to purchase vs. likelihood loyalty?

A: I don’t. I am not interested in questions about the future. I am interested in problems of the present and recent past, motivations, and behaviors. What people tell us about their future interest and behavior is not trustworthy. Not because they lie to us, but because they have no way of correctly predicting their future behavior. Especially in a research situation, when people want to be perceived as helpful, smart, and friendly.

Q: I’ve just started working as a first user researcher in a company where designers and product managers are doing the research. I am not supposed to replace them, I should be leveling up their research capabilities and start with reops stuff. I was told they were doing lots of discovery but soon realized it’s all about usability testing. It seems to me the it comes from Marty Cagan’s book Inspired (simplification to discovery and delivery). The book is the company’s bible and I am not sure how to approach the change of the mindset so that we can do more exploratory research.

A: If they already do usability testing, that’s a great start. I would recommend you run one such usability test (off to help someone who is stressed out in time) and dedicate some of it to traditional usability testing and the rest to exploratory research. My experience is that at first they won’t understand why you do that, and then they’ll be more interested in that than the usability test.

Q: Are there any successful Lean approaches at regulated organizations (e.g. financial services, healthcare, etc.) where you can’t just experiment and measure live as some Lean UX methods advocate?

A: Yes, experimenting in heavily regulated companies is hard. But if there’s a will, there’s a way. Might take a lot of time and effort to make it happen but it’s doable. If Goldman Sachs did it, anyone can. Trust me…

During our “Ask Me Anything” with Laura Klein, author of Build Better Products, we touched on subjects ranging from how to define “agile,” whether “scope creep” is something we should really consider a mistake, to recommendations around how to scale an agile team. Read on for a recap of the session, and please join our Slack here to stay informed about when our next #rm-chat author AMA will be!

Q: Scope Creep is what you call a product choice that was a mistake, yet in every other scenario we would call it Innovation and Entrepreneurial. How do we manage that risk and maximize the possibilities? -Arpy D.

A: Thanks for the question. I’m sorry, but I’m going to have to argue with your framing here. I don’t think Scope Creep is a product choice that was a mistake. I think Scope Creep is what happens when we don’t really understand the specific thing that we’re building and we keep just adding things onto it. That has nothing to do with innovation in my opinion. Some of the most innovative products are very small and well scoped. Also, scope creep was specifically more of a pre-agile thing when features were 100% scoped and estimated ahead of time. Then, when we did a bad job of that (as we always did because it’s hard), we would start saying “oh, actually, it also needs to do x” and “oh, now that it does x, it won’t work without y”. Again, that’s not innovation. That’s just bad planning.

Q: What advice and/or book recommendations do you have on scaling product teams and ensuring they remain agile? Also, I saw you recently tweet about design in agile teams. Aside from your article any other recommendations on this topic? – Cynthia C.

A: The trick is that you need to be outcome driven for each of your teams so that teams can remain semi-autonomous. You also need to have a strong commitment to iteration. The thing I’ve learned from research on this is that There is no Agile! There are a lot of models to this. There’s the team of teams and dual track and scrum vs kanban and guilds/squads, etc.

Q: Do you have any insights or advice around how designers can work better on agile teams? -Adeline C.

A: I’ve been doing a ton of research on this.The extremely UX answer is that it depends. It turns out that when people talk about “agile” it actually can mean one of about a dozen different things, none of which are really terribly agile. Frequently, people introduce Agile because they just want to go faster, which can be really exhausting and burn-out-inducing for designers and researchers.

If you read the Agile Manifesto, it’s not that complicated. The problem is that it is very high level, and it comes out of a bunch of competing methodologies that have very specific instructions and rituals, and those often get very confusing (ie. kanban vs scrum).

Q: Do you see any reason not to go dual track? -Ben M.

A: Sometimes! First of all, I’ve found at least three different in the wild interpretations of “dual track” which makes this a hard question to answer. A lot of dual track seems to be aimed at developing (and validating) biggish new features. It’s probably overkill if what you need are small, incremental improvements, which is actually true of a lot of products. You also have to be careful that you don’t split things up as “this team gets to do cool new innovative stuff and this other team has to maintain our crappy legacy system!” But that’s more about your particular implementation of it, rather than saying you should or should’t use it. If you do use it, use it responsibly for the things it’s good for. The different types of dual track I’ve seen, by the way, are the ones where there’s a team that’s actually focused on discovery of new opportunities and testing out more risky new things vs one where ux and research are all on the first track. That second one is AgileFall, not dual track.