Podcast appearances and mentions of jesse james garrett

From Amphitheaters to Apps: The Evolution of User ExperienceLong before we had screens, scroll wheels, or skeuomorphism, we were already wrestling with what it meant to design for humans.Take the Roman Colosseum, for example.Built nearly two thousand years ago, this wasn't just a feat of architecture—it was a carefully orchestrated user experience. The Romans didn't just think about how to build it. They thought about how people would use it.They designed for easy access, with a ticketing system based on numbered entrances and a layout that could empty 50,000 spectators in under 15 minutes. The acoustics were finely tuned so the roar of the crowd carried across the arena, and shaded awnings (the velarium) helped protect people from the sun. Every detail was intentional.It was, in many ways, a masterclass in UX before UX had a name.UX Has Always Been About PeopleWe like to think of UX as a digital thing. But humans have been designing with users in mind since the first tool was shaped to fit a hand. Egyptian sickles curved to match the arc of an arm. Greek amphitheaters optimized for sightlines and sound. Roman roads were engineered for ease of maintenance—because someone had to clean them, after all.These weren't just technical solutions. They were people-first designs.Even medieval cathedrals were built with experiential thinking. Architects considered the way light would filter through stained glass at different times of day. The experience of awe wasn't accidental.And while we'll skip ahead now (you didn't pick up this book for a lecture on Mesopotamian farming tools), it's worth acknowledging this simple truth:UX isn't new. Only the term is.The Digital ShiftThings changed in the mid-20th century. The rise of aviation and computing forced us to formalize our approach to usability. Mistakes became expensive—or fatal. So, human factors engineering emerged. We studied how people interacted with complex systems and tried to design those systems to be safer and more intuitive.It started in cockpits. Aircraft instrumentation had to be easy to read and understand under pressure. This wasn't about making things pretty. It was about saving lives. That pragmatic approach to human-centred design later shaped everything from microwave interfaces to early computer systems.Fast forward to the 1980s, and computing hit the mainstream.That's when things really took off.At Xerox PARC, researchers introduced the first graphical user interface. Apple took it further with the Macintosh, turning computing from a tool for specialists into something everyone could use. Suddenly, usability wasn't just a nice-to-have. It was a competitive advantage. And in 1993, Don Norman, while working at Apple, coined the term "User Experience."“I invented the term because I thought human interface and usability were too narrow.” — Don NormanThat moment matters. Because what Norman was arguing for was a broader view of design. Not just the screen. Not just the features. But the entire experience—from the first moment someone hears about a product to the support they receive after using it.“User experience encompasses all aspects of the end-user's interaction with the company, its services, and its products.” — Don Norman and Jakob NielsenIn other words, UX was never meant to be confined to wireframes and user flows. It was meant to be everything.UX Gets StrategicBy the early 2000s, UX had a seat at the table—albeit a wobbly one. Jesse James Garrett released The Elements of User Experience in 2002, which became a cornerstone for the field.Garrett didn't just break UX down into layers—strategy, scope, structure, skeleton, and surface—he emphasized that it all starts with strategy. Before we push pixels or run tests, we need to understand user needs and business goals.That idea changed things.We weren't just designing interfaces. We were shaping how people experienced products, services, and even entire brands. UX wasn't just implementation. It was about shaping products from the very beginning, not just making tweaks at the end.And as agile methods took over, UX adapted again. We embraced faster feedback loops, closer collaboration, and more iterative design. We moved from long documentation to quick prototypes. From abstract personas to real user insight.By the 2010s, UX had grown up.Design thinking gained traction. Suddenly, UX was sharing the spotlight with business strategy. Service design entered the conversation. We weren't just designing digital tools—we were solving human problems, often in messy, non-linear ways.UX vs. Everything ElseAs UX matured, we saw these disciplines emerge from within it. Our understanding of UX broadened, leading to specialization in areas like UI design, product design, service design, DesignOps, and even extending into marketing and customer experience.So let's clear things up a bit:UI Design is about what the user sees and interacts with. Think buttons, typography, animations. It's the look and feel.Product Design is broader. It connects user needs with business goals. Product designers care about features, roadmaps, KPIs, and how the product evolves over time.DesignOps and Service Design sit more behind the scenes. They're about scaling design efficiently. They orchestrate people, tools, and workflows to support good outcomes—kind of like stage managers for a show who make sure the lighting, props, and crew all hit their marks. You might never notice them when everything goes well—but without them, the whole production risks falling apart.And UX?UX is front of stage. It's the performance the audience actually experiences. It's the story that unfolds when someone buys your product, uses it, recommends it, or gets frustrated and gives up. Every moment on that journey is part of the user experience, whether it's a sleek onboarding flow, an unreadable error message, or a helpful reply from customer support.UX is the full experience. It's not a department. It's not a phase. It's not a deliverable. It's what happens to your users—whether you intended it or not.Take something as emblematic as buying an Apple product. The UX includes everything from the anticipation built by the marketing, the elegant packaging design, the satisfying moment of lifting the lid, the device that powers on right out of the box, the intuitive setup process, and even the helpful support at the Genius Bar.You might admire the product design. But the experience is everything that surrounds it—something Apple has understood since Don Norman helped shape their approach in the early 1990s.“No product is an island. A product is more than the product. It is a cohesive, integrated set of experiences… Make them all work together seamlessly.” — Don NormanA good UI is important. A strong product strategy is essential. But if the experience feels clunky, frustrating, or inconsistent—none of it matters.UX connects the dots.It asks: How does it feel to use this? Does it make sense? Does it meet a real need?And it reminds us that what we design isn't just a product or a service. It's a human moment.The Reality CheckSo, UX has matured significantly. Most business leaders now understand its importance, at least in theory. You'll rarely hear someone argue against the value of good user experience.But understanding isn't the same as implementation.The reality in many organizations is far from the idealized vision we read about online. UX teams are often understaffed and under-resourced. They're expected to deliver transformative results with minimal support, limited budgets, and impossible timelines.The problem goes deeper than resources. UX has been fundamentally misunderstood and under-appreciated within many organizations. Instead of being involved in strategic decisions from the start, UX professionals are often relegated to implementation roles—brought in to "make things pretty" after all the important decisions have already been made.True UX work—which should touch every aspect of how users interact with an organization—frequently runs into organizational silos. The kind of cross-functional collaboration required for excellent user experience threatens established power structures and comfortable routines. As a result, UX's wings are clipped, its scope limited to safe, contained projects that won't ruffle too many feathers.The promise of UX isn't just about better interfaces—it's about better organizations. But that promise remains largely unfulfilled in many companies.These challenges aren't just frustrating for UX practitioners; they're holding back organizations from delivering truly exceptional user experiences. The gap between what's possible and what's actually being delivered continues to widen.Throughout the rest of this email course, we'll explore these challenges in detail and, more importantly, discuss practical strategies for overcoming them. Because understanding the problem is only the first step—what matters is how we respond to it.Your Turn: Reflect and ShareIn our next email, we'll explore what it means to be a true UX designer within an organization. But, between now and then, I encourage you to reflect on your current role. Consider whether there's a gap between what others in your organization expect from you and what you believe you should be doing. Are you being asked to simply "make things pretty," or are you empowered to shape meaningful experiences.Take a moment to jot down your thoughts. This reflection will be valuable as we dive deeper into defining and claiming our role as UX professionals.Also, if you wouldn't mind, share those thoughts with me by replying to this email. Your insights will help shape the future content of this course, ensuring it addresses the real challenges you face in your UX role. I read every response and use them to make this journey more valuable for everyone.User Experience design has evolved far beyond its digital roots. From ancient Roman architects to industrial designers, and finally to today's digital interfaces - the journey of UX shows how we've always strived to create better human experiences.

In this special, live episode from the Config conference at the Moscone Center in San Francisco, Jesse James Garrett recounts his significant career co-founding Adaptive Path, pioneering foundational processes in software design, and navigating strange waters as his company was sold to Capital One. Just as he was finding his footing as a design executive coach, he got a cancer diagnosis that reshaped his view on work and life. Now on the other side of cancer, he shares what he learned. Transcript and show notes: http://reconsidering.org

Power of Ten is a show about design operating at all levels of zoom, from thoughtful detail to changes in organisation, society and the world, hosted by design leadership coach, Andy Polaine. My guest in this episode is Peter Merholz. We talked about the state of the design nation, the burst bubble of the Cambrian explosion of design from the last 10-15 years, product, business and the issue of mediocrity. Peter has worked at the intersection of design, technology, and humans for over 25 years. Currently, he's an independent consultant focused on improving the effectiveness of design organisations. He was a co-founder of Adaptive Path, acquired by Capital One in 2014 and he co-wrote Org Design for Design Orgs, still the premier book on building in-house design teams. He co-hosts the Finding Our Way podcast exploring design leadership along with another Adaptive Path co-founder, Jesse James Garrett. He also coined the word “blog.” Show Links Peter Peter's website: https://www.petermerholz.com Org Design for Design Orgs: https://www.petermerholz.com/writing/#orgdesign Finding Our Way podcast: https://findingourway.design/ Peter on Mastodon: https://sfba.social/@peterme Peter on LinkedIn: https://www.linkedin.com/in/petermerholz/ Andy Website: https://www.polaine.com Newsletter: https://pln.me/nws Podcast: https://pln.me/p10 Courses: https://courses.polaine.com LinkedIn: https://www.linkedin.com/in/apolaine/ Mastodon: https://pkm.social/@apolaine YouTube: https://www.youtube.com/@apolaine

Aprender design de experiência de forma estruturada envolve adquirir conhecimentos sobre os princípios fundamentais, desenvolver habilidades práticas e ganhar experiência prática. Aqui estão algumas etapas que podem ajudar: Compreender os Fundamentos Educação Formal Leitura e Pesquisa Prática Contínua Ferramentas de Design Participação em Comunidades Onlineão: Ao incorporar esses elementos em sua jornada de aprendizado, você estará construindo uma base sólida para se tornar um designer de experiência mais completo e eficaz. Lembre-se de que o design de experiência é uma disciplina em constante evolução, então esteja preparado para aprender continuamente e adaptar suas habilidades às mudanças na indústria. Tornar-se um bom designer de experiência envolve um comprometimento contínuo com o aprendizado e o desenvolvimento de habilidades. É importante adquirir conhecimentos e habilidades em diversas áreas. Aqui estão algumas diretrizes específicas para ajudá-lo a trilhar o caminho para se tornar um designer de experiência eficiente: Construa um Portfólio Entenda o Processo de Design Compreensão do Negócio Desenvolva Habilidades de Comunicação Mantenha-se Atualizado. Aprimore suas Soft Skills Além desses tópicos, a prática constante e a participação em projetos práticos e diversos são cruciais para consolidar seus conhecimentos. Considere também procurar oportunidades de networking e mentorias para acelerar seu desenvolvimento profissional. Dicas de livros: Design centrado no usuário, de Travis Lowdermilk https://amzn.to/3SvUgyrIntrodução e boas práticas em UX Design, de Fabricio Teixeira https://amzn.to/3w7YLYxThe Elements of User Experience, de Jesse James Garrett https://amzn.to/3OBJrtjDesign para quem não é designer: princípios de design e tipografia para iniciantes. Autor: Robin Williams https://amzn.to/3OvZt8b

This is a special archived episode of Brave UX. Jesse James Garrett reminds us that once we were pirates, encourages us to understand how soft-power works, and to know and be true to our red-lines. Highlights include: How are UX designers like classical composers? What is the role of personal preference in design? Should design leaders leave strategy to product leaders? Is design leadership about actively resisting the status quo? What have you learned as a result of the “no's” in your career? ====== Who is Jesse James Garrett? Jesse is the Principal Leadership Coach of Intentional Associates, the executive design leadership coaching practice that he founded in 2020. And it's through his coaching work that he is helping design leaders to develop the skills to lead with greater purpose, intention and creativity. Many of you may know Jesse for his influential model from the year 2000, “The Elements of User Experience”, and his book of the same name. It's this foundational thinking, at frontier of UX, that has helped to inform, inspire and enlighten multiple generations of UX designers. Jesse was also a Co-Founder and Chief Creative Officer of Adaptive Path, one of the original and most renowned User Experience consultancies. At Adaptive Path, Jesse worked tirelessly for 13 years to put UX design on the enterprise map. Throughout the years, his writing, teaching and public speaking has been unfailingly generous, taking him all over the world, including to events such as UX Lisbon, UX Salon, and USI.  Jesse's contributions continue through the “Finding Our Way” podcast, a show about design leadership that he co-hosts alongside Peter Merholz, his good friend, fellow Adaptive Path Co-Founder, and Brave UX alumnus. ====== Find Jesse here: LinkedIn: https://www.linkedin.com/in/jesse-james-garrett-1341/ Twitter: https://twitter.com/jjg Website: https://jessejamesgarrett.com/ ====== Liked what you heard and want to hear more? Subscribe and support the show by leaving a review on Apple Podcasts (or wherever you listen). Follow us on our other social channels for more great Brave UX content! YouTube: https://www.youtube.com/TheSpaceInBetween/ LinkedIn: https://www.linkedin.com/company/the-space-in-between/  Instagram: https://www.instagram.com/thespaceinbetw__n/  ====== Hosted by Brendan Jarvis: LinkedIn: https://www.linkedin.com/in/brendanjarvis/ Website: https://thespaceinbetween.co.nz/ Twitter: https://twitter.com/brendanjarvis/

Aurelius Podcast - Episode 62 highlights with Jesse James Garrett: - Discussing The Elements of User Experience and its impact - Defining and communicating the value proposition of design - What being a design executive and design leader actually looks like - Steps for success in a design leadership role - The importance relationship building in design leadership

Robb and Josh welcome special guest Jesse James Garrett, legendary information architect and sought-after executive leadership coach. The three discuss the need for experience design in AI and how to get designers to the table.

When UX design guru Jesse James Garrett first started out, user experience as we know it today wasn't even a thing. Yet he remains among the most prominent voices in digital product design. As both witness and catalyst for more than 20 years, Jesse's work in this space triggered much of the UX evolution and … The post 100 / The Emergence of Product + Design Leadership, with Jesse James Garrett appeared first on ITX Corp..

Jesse James Garrett has been one of the most prominent voices in digital product design for more than 20 years. His career highlights include co-founding the groundbreaking UX consultancy, Adaptive Path; writing the foundational book The Elements of User Experience, whose iconic five-plane model has become a staple of the field; and defining Ajax, the dynamic interaction model that transformed web technology and design in the Web 2.0 era. His work has been published in more than a dozen languages and he is a frequent keynote speaker on making designers and organizations more human-centered in their work.We dive into leadership through relationships, how most struggles of unhealthy design teams can be traced back to unhealthy relationship dynamics, paired with leading with authenticity, and how too many designers feel they have to shed some part of who they are in order to fit the mold of leadership. But leadership has no mold and comes in every shape imaginable. 

Jesse James Garrett is a Design Leadership coach, author and speaker with over 25 years of experience in the UX industry. Jesse was part of the first wave of professional user experience designers and co-founder of one of the first user experience consultancies, Adaptive Path. In this episode, we talk with Jesse about what UX leadership needs in order to keep the industry thriving.Help us improve the show and suggest future topics or guests! Click here to take our quick survey.

Jesse James Garrett reminds us that once we were pirates, encourages us to understand how soft-power works, and to know and be true to our red-lines. Highlights include: ⭐ How are UX designers like classical composers? ⭐ What is the role of personal preference in design? ⭐ Should design leaders leave strategy to product leaders? ⭐ Is design leadership about actively resisting the status quo? ⭐ What have you learned as a result of the “no's” in your career? ====== Who is Jesse James Garrett? Jesse is the Principal Leadership Coach of Intentional Associates, the executive design leadership coaching practice that he founded in 2020. And it's through his coaching work that he is helping design leaders to develop the skills to lead with greater purpose, intention and creativity. Many of you may know Jesse for his influential model from the year 2000, “The Elements of User Experience”, and his book of the same name. It's this foundational thinking, at frontier of UX, that has helped to inform, inspire and enlighten multiple generations of UX designers. Jesse was also a Co-Founder and Chief Creative Officer of Adaptive Path, one of the original and most renowned User Experience consultancies. At Adaptive Path, Jesse worked tirelessly for 13 years to put UX design on the enterprise map. Throughout the years, his writing, teaching and public speaking has been unfailingly generous, taking him all over the world, including to events such as UX Lisbon, UX Salon, and USI.  Jesse's contributions continue through the “Finding Our Way” podcast, a show about design leadership that he co-hosts alongside Peter Merholz, his good friend, fellow Adaptive Path Co-Founder, and Brave UX alumnus. ====== Find Jesse here: LinkedIn: https://www.linkedin.com/in/jesse-james-garrett-1341/ Twitter: https://twitter.com/jjg Website: https://jessejamesgarrett.com/ ====== Liked what you heard and want to hear more? Subscribe and support the show by leaving a review on Apple Podcasts (or wherever you listen). Follow us on our other social channels for more great Brave UX content! YouTube: https://www.youtube.com/TheSpaceInBetween/ LinkedIn: https://www.linkedin.com/company/the-space-in-between/  Instagram: https://www.instagram.com/thespaceinbetw__n/  ====== Hosted by Brendan Jarvis: LinkedIn: https://www.linkedin.com/in/brendanjarvis/ Website: https://thespaceinbetween.co.nz/ Twitter: https://twitter.com/brendanjarvis/

In the late 1990s, as digital practices like web design and development emerged, experiences were being created and users were getting attention, but the practices that guided that work had not yet been articulated. That's when Jesse James Garrett wrote his book, The Elements of User Experience. After sharing his ideas in numerous client pitches and sketching them on whiteboards for his co-workers, Jesse collected his discoveries into a manuscript that would become the first textbook for the new field of UX design. https://ellessmedia.com/csi/jesse-james-garrett/

In this very special episode, Barry and Phil are joined by none other than Jesse James Garrett, co-founder of formative UX Design agency Adaptive Path and author of the seminal book, "The Elements of User Experience". Jesse takes us through his journey from designer, to entrepreneur, to business leader, to corporate executive, and finally to his current pursuit of providing Creative Leadership coaching. We discuss why being a Creative Leader is different than other types of leadership, the dynamic between team-leading and team-building, and, on the 1-year anniversary of his infamous FastCo article, what attributes do and do not make for great creative leadership today. This is an inspiring and hopeful conversation with one of the true luminaries of the design world. Enjoy! Drinks: Lawson's Finest Liquids Triple Sunshine Imperial IPA, Dogfish Head Brewing Co. Slightly Mighty Low-Cal IPA, Blackhammer Brewing Zoom Room Romance Belgian Tripel Links: Leadership Coaching: https://jessejamesgarrett.com/ Podcast: https://findingourway.design/ Books: https://www.amazon.com/Elements-User-Experience-User-Centered-Design/dp/0735712026 The FastCo Article: https://www.fastcompany.com/90642462/ux-design-is-more-successful-than-ever-but-its-leaders-are-losing-hope --- This episode is sponsored by · Anchor: The easiest way to make a podcast. https://anchor.fm/app --- Send in a voice message: https://anchor.fm/whatbubblesup/message

Today we're going to talk about What Every Design Leader Must Know? As someone who has been practicing design and UX for more than 20 years, I'm very excited about this talk. My guest today is Jesse James Garrett, Design Leadership Coach We will discuss: - Why do you think human-centered design did not pave the way for human-centered enterprises? - What are the challenges design leaders face today? - How do you think Agile methodologies changed the UX impact on the product and enterprises? More about Jesse in: https://lnkd.in/djtqt5zU Thanks for watching Invincible innovation LIVE A Show About The Future Of People With Tech I'm Adi Mazor Kario, #1 Product Innovation & Value Creation Expert, Invincible Innovation. I'd love to hear your feedback and thoughts in the comments below! If you want to know more about me and my work: https://lnkd.in/deCd7QS Invincible Innovation podcast: https://spoti.fi/3wzdBT1 Invincible Innovation on Facebook: https://bit.ly/3xtwPt9 Innovating Through Chaos Book: https://amzn.to/3gAVLbu Adi's LinkedIn: https://bit.ly/3vuAplA Hope you'll enjoy the talk! hashtag#design hashtag#futureofdesign hashtag#business hashtag#leadership hashtag#innovation hashtag#innovationecosystem hashtag#startup hashtag#management hashtag#invincibleinnovation hashtag#openinnovation hashtag#cocreation hashtag#opportunities hashtag#valuecreation hashtag#success Invincible Innovation Innovation Ecosystems Digital Transformation Startups what is digital transformation in business d digital transformation strategy innovation digital transformation series episode what is innovation digital transformation digital transformation trends innovation ecosystem startup philosophy business building how to innovate Digital Transformation and Innovation Secrets | Invincible Innovation Digital Transformation and Innovation Secrets

What is the future of design? In 2002, Jesse James Garret launched the book The Elements of User experience where he introduces us to five elements, which divide the design process into stages. Recently, He posted a controversial article talking about the current moment of the UX industry and the possible misunderstandings happening. We decided to start this new project called Good Morning UX, an extension of another show called Bom Dia UX, with such special-international guests. Actually, we invited 6 professionals who are references for us and that have so much history in our industry. For this, we invited the creator of the term AJAX and Elements of UX's author, Jesse James Garrett to talk to us about the industry, education, his book, and the future of our profession. Follow Jesse on these links: https://jessejamesgarrett.com/ https://en.wikipedia.org/wiki/Jesse_James_Garrett Jesse's book: (FREE) http://www.jjg.net/elements/ https://amzn.to/3yO5m7m https://amzn.to/3skps8h Related Links: https://www.fastcompany.com/90642462/i-helped-pioneer-ux-design-what-i-see-today-horrifies-me https://workspiration.org/jesse-james-garrett ----------------------------- This is the Bom Dia UX, a live show produced and launched at the Design Team channel every Wednesday at 7 am, in the Brazilian time zone. ----------------------------- Sign up the channel https://www.youtube.com/c/designteambr?sub_confirmation=1. Came to membership and have exclusive content https://www.youtube.com/channel/UCTkZTDIq25Czsazq2N493Cg/join Follow us: Rodrigo Lemes Linkedin: https://www.linkedin.com/in/rodrigolemes Twitter: https://twitter.com/rodrigolemes Rafael Burity Linkedin: https://www.linkedin.com/in/rafaelburity Twitter: https://twitter.com/rafaelburity Instagram: http://www.instagram.com/rafaelburity ----------------------------- * Join us at Telegram * https://bit.ly/3dOea2Y * Access our website *

OVERVIEW:In this episode, I am joined by Peter Merholz, Design Executive and Organisational Consultant, Author and Founder of Adaptive Path.His book, co-authored with Kristin Skinner, Organisational Design for Design Orgs is a go-to book for so many Designers, Design and non-design Leaders.   In our conversation, we cover specifically the difference between Tech-First and Legacy Organisations in how they see Design within their organisational structure, what difference this makes to the way they invest in and support Design, what this means for newly minted design executives.  We touch on themes that I covered with both Jose Dos Santos and Clive Grinyer in earlier episodes about the blockers that Design-Leaders face on the way to the c-suite.This is a conversation about the mindset, skills, attention and orientation of executive leadership and what Design needs to ‘get over' (sometimes itself and sometimes others) in order to achieve that. SHOW LINKS & RESOURCES:I referenced an article that Peter published recently on the focus and role of a Design Executive which is really useful to remind Senior Design Executives what is expected of the executive role.Other ways to connect and follow Peter's thinking:Peter Merholz on LinkedInPeters Personal Website contains his writing and musings on humanising DesignOrg Design for Design Orgs the website contains updated reflections on the topic of Design Orgs and Design Leadership and is worth followingPeter has his own podcast - co-hosted with Jesse James Garrett - call Finding Our Way that is absolutely worth adding to your regular downloads - I'm a subscriber and find it invaluable.subscribe to the Business x Design Newsletter hereand connect with your show host Martin Dowson on LinkedIn - we really welcome feedback from our listeners so do get in touch!

In observance of the winter holidays, this episode doesn't feature a guest interview. Instead, I reflect on five themes that emerged in the diverse conversations we hosted on the podcast during 2021. I wish you and yours happy holidays! Cover photo by Waldemar Brandt on Unsplash. If you're enjoying the show, please rate or review it in Apple's Podcasts directory: https://podcasts.apple.com/us/podcast/the-informed-life/id1450117117?itsct=podcast_box&itscg=30200 Show notes The Informed Life episode 53: Jason Ulaszek on Healing Social Rifts The Informed Life episode 54: Kourosh Dini on DEVONthink The Informed Life episode 55: Hà Phan on Product Leadership The Informed Life episode 56: Margot Bloomstein on Trust The Informed Life episode 57: Ben Mosior on Wardley Maps The Informed Life episode 58: Jesse James Garrett on Leadership and IA The Informed Life episode 59: Matt LeMay on One Page / One Hour The Informed Life episode 60: Kat Vellos on Friendship The Informed Life episode 61: Jeff Sussna on Customer Value Charting The Informed Life episode 63: Sophia Prater on Object Oriented UX The Informed Life episode 64: Sarah Barrett on Architectural Scale The Informed Life episode 66: Jim Kalbach on Jobs to Be Done The Informed Life episode 68: Mags Hanley on Career Architecture The Informed Life episode 69: Karl Fast on Interactionism, part 1 The Informed Life episode 70: Karl Fast on Interactionism, part 2 The Informed Life episode 71: Sunni Brown on Deep Self Design The Informed Life episode 73: Patrick Tanguay on Newsletter Curation The Informed Life episode 74: Annie Murphy Paul on The Extended Mind The Informed Life episode 75: Hans Krueger on the Cycle of Emotions The Informed Life episode 76: Dan Brown on IA Lenses Some show notes may include Amazon affiliate links. I get a small commission for purchases made through these links. Read the transcript Jorge: Welcome to the informed life. In each episode of this show, we find out how people organize information to get things done. I am your host horsehair angle. Today, I don't have a guest on the show. Instead, I'm going to try something a little different. Rather than a conversation with a single guest, I'm going to do a review of some of the things that I heard during the course of the year. So, you'll be hearing from several of the folks who graciously agreed to be on the show. And the reason why I'm doing this is because I listen to a lot of interview-based podcasts. And while I find myself getting totally engrossed in each individual conversation, I often lose track of what I've heard before in prior conversations, and I have a hard time making sense of patterns that may be emerging. So, I thought that during this quiet time of year I might take some time out to do just that, to see if there are any themes or patterns that have stood out during the interviews i've done in the past 12 months. Of course, the guests on the show, didn't speak with each other. I don't want to imply that they're somehow in conversation or responding to each other's points. In fact, the only point that any of these conversations have in common was that I was a part of all of them. I'm also aware that when you take snippets of interviews out of context, It may change their meaning, especially when put next to other snippets from other conversations. And that's definitely not my intent. I'm not going to present these in the order in which they were recorded. In fact, I'm going to talk about these in no particular order. So, in this episode, I'm just going to edit these together and see if I can highlight some of these themes that seemed to have come up in more than one conversation. If you want to check out the full conversations, which I encourage you to do, I will include links to each episode in the show notes. Hopefully, this will prove useful to you if you choose to revisit the conversations we've had over the last year. So, now onto the themes. We recorded 25 conversations during 2021. And in revisiting them now, I've grouped them into five high-level themes. There are other ideas that have come up and there are different arrangements you could make, but these are five themes that stood out to me. The first theme, I'm calling, aligning our values with our actions. The second is about using intentional structures for self-development. The third is about practicing information architecture at scale. The fourth is highlighting tools and methods for visualizing systemic intent. And the fifth is about thinking beyond the brain. I'll unpack what these are about one by one and hopefully draw connections between them to try to bring some coherence to the conversations that we've been having throughout the year. Because I do think that there are things that connect them. Aligning our values with our actions Jorge: So now, let's dive into the first of these themes, which has to do with aligning our values with our actions. And this is one that came in this year, particularly strongly and with intent on my part because I was appalled by the January 6th insurrection in Washington, DC. This horrible event brought to life the degree to which there are deep social rifts in the U.S. And I I've been thinking about what designers can do so what can I do through my work to help make these things better. So I wanted to talk with folks who have been explicitly thinking about this stuff. And this led me to reach out to Jason Ulaszek, who has used design to help heal Rwandan society in the wake of the Rwandan genocide, which I think is obviously a much more extreme situation than the one that we're facing here in the U.S. Now, Jason is not originally from Rwanda, he's from the U.S., so I asked him if there's anything that we could learn from his experience that might help us in our society to start healing the rifts that divide us. And I was very intrigued by his answer; he talked about re-engaging with cultural values. And this is what he had to say: Jason Ulaszek: What was part of the Rwandans cultural value system well before the genocide against the Tutsi, and is now swung fully back -- and they're working hard to ensure that that's the case -- is a really strong sense of cultural values. What they've really tapped into -- and I think this is where it gets into design a bit -- is that they've tapped into ways to embody these cultural values inside of the experiences people have within education. Jorge: So there's an explicit attempt there to create structures — in that case, within the educational system — that help highlight the common social values that bind a people together. And in part the way that I understood it, at least the part of the idea there is to try to rebuild a sense of trust among parties. And we had another episode this year where we talked explicitly about building trust. And this was in episode 56, where I had a conversation with Margot Bloomstein about her book on the subject, which came out this year, called Trustworthy. And, as Margot put it in our conversation, a big part of building trust has to do with authenticity: with having our actions be grounded in a clear set of values and having them be aligned with those values. This is how Margot put it: Margot Bloomstein: You used the term "authenticity." And I think that that's a term that we throw around a lot; that's a term marketers love to throw around. Who wouldn't want to be authentic? And I always wonder, authentic to what? Do you know who you are? Know thy self first, and then you can determine, well, how do we align our actions with our values? Because that's how we measure authenticity: it's the distance between our actions and our words, all of that external stuff and our values. And I think for many organizations, they can jump into kind of the national conversation, into the international conversation, around many of those social issues and say, "Here's what we're doing. Here's why we support this. Here's what we're doing internally. And here's what we're doing externally to make this better for everyone." To put a stake in the ground. And they can do it building on that long-term, authentic investment in their values. Jorge: I love this idea of being more intentional about aligning our values and our actions as we seek to be more authentic. And of course Margot was talking here about doing that at the level of organizations, but it's also possible to do it at an individual level. And in my conversation with author Kat Vellos, we dug into that specifically in the context of her work. In nurturing friendships. And I asked Kat about how we might be more authentic in looking to create the structures that allow us to nurture friendships as we get older. And she highlighted the importance of being present. This is what she had to say about it. Kat Vellos: The more you immerse yourself in what is actually happening in that time that you're connecting with the other person, the more likely you are to feel the benefit. You know, when you're spending time sharing stories with a friend say, focus on their story, focus on them. Get curious. Ask followup questions and have that be the focus of your attention, rather than halfway listening and halfway being in your own head. Like, "do I feel less lonely right now? Do I feel less awkward right now?" Get out of that mental evaluation mode and get real immersed and real curious and interested in the other person. And that's actually when somebody feels heard. That's actually when somebody feels more connected is when you're really present and holding space with each other. Intentional structures for self-development Jorge: This idea of being more present was also an important part of our second theme, which has to do with creating intentional structures for self-development. I like to think of this almost as kind of an information architecture of the self. So, while it might seem on the surface like some of these conversations run a bit further a field from the subject of the show, I see them as being quite aligned in that we are creating conceptual structures that help us affect some kind of change. And in this second theme, the change has to do with internal transformation. We delved into this in a few conversations during the year. The first I will highlight is episode 71, where I interviewed Sunni Brown about her work in Deep Self Design, which is a practice rooted in Zen Buddhism and design thinking. And during this conversation, Sunni chastised me for allowing myself to let my devices keep me from being more present during a camping trip with my family. And I loved how Sunni talked about being more present. This is what she had to say: Sunni Brown: Camping, when it's like safe and beautiful... the point of it is to actually get you into a different state. To get your regulatory system in a different state so that you can enjoy your life and be present with your family and look at the sky and realize that you're part of... you are the sky, there's no difference between you and the sky, you just project that there is. And like, you know what I mean? So, you have to understand that that space is essential for your humanity and and make it a priority. And you can tell people, I mean, there's ways to approach it that are gentle on other people. So you can let people know, "I'm going to go dark for 72 hours. You should know that," Or, "I'm going to go dark, and then I'm going to have one hour where I look at stuff," you know? You have to design it for your life and what's actually available for you. Sometimes people have sick parents at home or sick kids or whatever, but you have to start to understand the benefit of it. Because I think most people think it's just like something they would lose. Like, they wouldn't get... something taken away from them. And I'm like, "no! It's something you're giving yourself that is priceless." And you get amazing ideas. Like your productivity goes up. So, I call it going slow to go fast. Actually I read this interesting Nietzsche quote, which I don't read Nietzsche a lot or anything, but like he said like great ideas are found when you're walking. And Steve Jobs was... Also, I'mnot obsessed with Steve Jobs, but he did a lot of walking meetings. So, If you are a productivity junkie, going slow helps you go fast. And it actually frees up a lot of stuck tension in the body and stuck ideas that you can't get through and it gives you solutions and ahas and insights. So there's huge rewards in it anyway, if you need it to be aligned with productivity. But it's like, dude, we're gonna die one day, Jorge. Like all of us! And the last thing I want to do is be like, "I spent my whole life on my iPhone!" That is like the worst thing that could happen. Jorge: So, we need to be more aware about what is going on with our systems, with our bodies — and we need to be present. And this was not the only conversation that I had that delved on similar subjects. In episode 75, I talked with my friend, Hans Krueger, who has also been influenced by Buddhism, on what he calls the cycle of emotions, which is a conceptual structure — a way of thinking about emotions and how emotions affect our behavior. Here's Hans: Hans Krueger: What surprisingly few people realize is that there is like a real system behind this thing, this whole emotional complex. How they work, how they interact with each other, what leads to what, what you can do to actually cultivate your own emotional state. A state that allows you to perceive as clearly as possible what is real, versus what you imagine is real. Jorge: There's an emerging theme here in the power of visualizing, might be one way to think about it, but at the very least naming these conceptual distinctions, becoming more aware of what is happening internally. And again, this might come across to some folks as not being relevant to information architecture at all. But I do think of these as conceptual structures where there are distinctions that we label and we establish relationships between those distinctions. And the structure helps us understand what we're doing so that we can act more skillfully, more mindfully. And at least one guest during the year talked about using such conceptual models, not just to help us personally, but to help us in our careers. In episode 68, Mags Hanley shared with us her work on career architecture, which is also the subject of her book, which was published after we talked. And Mags made the connection between the methods, processes and tools that we use as information architects and how we develop our careers. Mags Hanley: Career architecture is about how we can use the methods that we think about and we use as information architects or as UX professionals and apply that in a very systematic way into how we think about our careers. Practicing information architecture at scale Jorge: I like this idea of using information, architecture and user experience methods, practices, and tools for our own personal development. But we can also use them to develop our teams and to work at a different level of impact. I think of this as information architecture at scale, which is the next theme that emerged in the conversations that we had on the podcast over the year. Two that immediately come to mind, but I'm not going to highlight as much here, are the conversation with Jim Kalbach on jobs to be done, which, in addition to Jim's book, helped me clarify my own understanding of what jobs to be done are. And this is an important subject, one that designers and product managers need to be aware of. So, if you have heard the phrase, but are not entirely clear on what it means, I encourage you to check out my conversation with Jim. Another one is the conversation that I had recently with Dan Brown on information architecture lenses. And as that explained in that episode, the lenses are a set of cards, and now podcasts and YouTube videos, that aim to serve as a tool to help designers deal with architectural conundrums. So again, if you are into information architecture, and you haven't done so already. I encourage you to check out the conversation with Dan Brown. That said, there are a few episodes that I do want to call out here and bring to your attention. One is the conversation I had on episode 63 with Sophia Prater about her object oriented user experience framework. I see this as a way of formalizing conceptual models so they can be shared and discussed with other team members. This is how sophia described it during our conversation: Sophia Prater: OOUX is all about saying, "okay. If we know that our users think in objects and just human beings think in objects - not not just our developers - human beings think in objects, and to be able to gain understanding, you need to understand what the objects are in that system. And to understand what the objects are we need a certain level of consistency and recognizability to our objects." So as the designers of these environments, if we don't get really super clear on what our objects are, there's no way. There's just absolutely no way in hell that we're going to be able to translate that to our end users. We're just not! If we can't get it straight on our team and we can't get it straight among ourselves, then 1) that's going to create a lot of communication problems internally which is a problem that I hear all the time. We've got everybody on the team coming together. And some people, depending on what department you're in or what your role is, you've got the same object, the same thing being called two or three different things and different objects being called the same thing. And you're trying to design complex software. So just getting on the same page internally is going to be absolutely intrinsic to making sure that it's clear to your end users. Jorge: Another conversation that had to do with considering design at a different level of abstraction was in episode 64, where Sarah Barrett shared with us considerations about the architectural scale of the systems we design. I was particularly drawn to the way Sarah described how we should approach the intended effects of our work: Sarah Barrett: Occasionally, I get comments or people worrying that our information architecture isn't innovative enough that we're not doing anything surprising or introducing anything brand new. And I feel very strongly that your architecture is not the place to surprise people. Like, there are actual architects out there building very innovative homes that no one wants to live in. And I have no interest in doing that. I really want us to use the oldest, most standard, most expected way of doing things. I think the example of the grocery store is another great way here. There's a lot of benefit to not innovating in the layout of a grocery store. There probably is some benefit in innovating a little bit around the edges or in some details, but you gain a lot from making it legible and making it expected for people. And so, that one is really about... okay, given these things that we expect to have: we expect to have global navigation, we expect to have metadata on content, we expect to have titles and breadcrumbs... how do we unpack what each of those things is doing for us and make sure that between the suite of those elements we are using? Because you never use just one, you use lots of them together. Between all of those elements, we are presenting a coherent, complete view of the wayfinding people need. Jorge: It's one thing to create a coherent and complete system that allows people to find and understand things, and it's another to create the conditions that allow that system to evolve over time gracefully as conditions change but to retain that cohesiveness. And doing this requires that we understand that the things that we are designing are in fact systems and they are systems that will require stewardship over time. This implies that we need leadership. And that was the subject of episode 58, where I had a conversation with Jesse James Garrett about leadership and information architecture. This is part of what jesse said during that show. Jesse James Garrett: The way that I talk to folks about design leadership, who have come from a design background -that is to say they've been doing design work - is that leadership is just another design problem. And you're working with different materials and you're working toward different outcomes and you're having to follow different principles, but the task is the same task. It is a creative problem-solving task. It is a systems-thinking task, as a leader. So looking at the ways that you're already doing that systems-thinking, the ways in which you already doing that architecture for yourself in the work that you're already doing, and those will be your strengths. And those will be the pillars that you can lean on that are going to support your work as a leader going forward. They will evolve and they will not look like what they looked like when you were doing content inventories or task flows or whatever other artifacts you might've been working on as a designer. But the skill set that you're building is the same skill set. Jorge: The relationship between design and leadership, and how designers can use our tools, methods, practices, et cetera, to take on leadership roles, was also the subject of episode 55, which featured a conversation with hop-on about her own trajectory from design to product leadership. Hà Phan: I think the difficulty was between the role I have now, or the delta between the role I have now versus being a UX designer is that, you know, it's really a leadership role to basically provide the path to clarity. So when you have a vision, even as a seasoned UX designer, you're going to present forth this vision. And usually there's a thousand questions and a thousand steps before you get there, right? And usually you don't get there entirely. You know, you don't get to the vision entirely the way you had envisioned it. You're going to take turns, right? And I think in this role, what I get to do is that I get to enable the team to find that path to clarity, and to provide the milestones or the mission for each of the goals along the way. Jorge: This idea that leaders provide clarity and vision is very important. And it's one of the reasons why designers can make good leaders, because part of what designers do is clarify and help visualize abstract ideas. I keep saying that design is about making possibilities tangible: we take these vague notions, requirements, constraints, ill defined contexts, and we make things. And these things that we make can be validated somehow. We can put them in context and have them be used by the people that we intend to serve, to see whether things are working or not. And we create feedback loops where we make them incrementally better, better suited to meeting the needs of the people they serve. Visualizing systemic intent Jorge: And this idea of leadership as a role that clarifies and articulates a vision, brings us to the fourth theme that I noticed in going back over this year's episodes, which has to do with highlighting tools and methods for visualizing systemic intent. And by that, I mean different ways of mapping systems and making systems more tangible. Again, this idea of making the abstract more relatable. And we had several conversations along those lines. The first I'm going to highlight here is episode 59, in which Matt LeMay may shared with us One Page / One Hour, an approach he's developed to help teams articulate what they're making by working fast and iterating. So, rather than creating some kind of polished deck, the idea here is to articulate a vision really quickly so that you can spend less time upfront creating polished artifacts and spend more time iterating with stakeholders and other team members. Here's Matt describing how he came up with One Page / One Hour. Matt LeMay: I wrote up this pledge to my business partners saying I'm willing to forego the sense of individual accomplishment that comes from presenting finished and polished deliverables to my colleagues. I promise that I will spend no more than one page and one hour working on any deliverable - any document - before I bring it to the team. In other words, if I show up with five beautifully formatted pages or a one-page that took me 10 hours to create, I want you to hold me accountable to that. I want you to say, "man, why did you do this? We made a deal. We made a commitment to each other! We all know that if we actually want to deliver value, if we want to do valuable work, we need to collaborate earlier on. You can't go off onto your own and create this big thing, and then just want us to tell you how great it is!" Jorge: One Page / One Hour is about trying to articulate very quickly what we have in mind and sharing it so that we can start iterating on it. A few of the other conversations that we had during the year around visualizing systems and visualizing intent were about artifacts that are a little more elaborate. An example of this is Customer Value Charting, which Jeff Sussna shared with us in episode 61. Customer Value Charting, as Jeff explained, it is a tool to balance strategy and agility. And the purpose of creating that balance is to drive customer benefits, which are related to but not the same as business benefits. Jeff illustrated this by means of an example using a common service. Jeff Sussna: The benefit of the dry cleaner is that I can get my tuxedo cleaned in time to go to the formal event. It's not fundamentally about a cash register or a counter or even cleaning chemicals. And I mention that because a lot of the conversation I see around outcomes over outputs tends to actually talk about business outcomes. You know, revenue growth and customer retention, and time on site and business outcomes are great. I don't have any problem with them, but people tend to skip this step. We have a hypothesis that this feature will cause this change in customer behavior, which will lead to this business outcome or business impact. But it leaves open the question of, well, why is the customer changing their behavior? What is the benefit to them? Jorge: These are complex questions to take on for designers or for anyone, frankly. And it's helpful to hear about how folks are going about it. Customer Value Charting is one way of doing it. Another way of visualizing systems and visualizing things like customer needs in a systemic way was shared with us by Ben Mosiure in our conversation, which focused on Wardley maps. Ben Mosior: Wardley mapping is a visual way of representing systems: its users, its needs, its capabilities, its relationships between all those three things. And then it's also positioning those things in a way that helps their qualities become more apparent. So there's this thing that Simon Research called "Evolution." It's basically how do things evolve and get better or die under the pressures of supply demand competition, and what you get is like things start out new, uncertain, high risk, high failure, but with a high potential for future value. But then as they evolve, they get better. You know, someone's always like looking at these weird ideas and trying to make them better because capitalism basically suggest there's money to be made. So someone out there is going to try to make it better. And over time, if the idea is worth investing in, it will continue to get better, more known, more boring, more predictable, and the value of it will be more concrete. And eventually, if it evolves to a certain extent, it becomes an invisible part of our everyday lives. And so, Simon says, look, you want to represent the systems that we're a part of both in terms of their parts and relationships, but also in terms of how evolved each of those parts are. Because what that does is it sets you up to understand the implications of those qualities. New stuff is going to be high failure, old stuff that everybody understands, that's just part of everyday reality like power in the wall. It is going to be less surprising, it's going to be less failure. And so that means that depending on the context, depending on the part of the system we're looking at, we need to have a different way of approaching it. And I think that's the entire point. By making visual artifacts -- by talking about our systems visually -- we can come together, look at a specific part of it, appreciate its qualities, and then together determine what our collective intent is about that part of the system. Jorge: That's a great description of this idea that we can take these complex abstract ideas and make them tangible, make them manifest in the world, and as a result, make it possible for us to have conversations about them, to somehow change the state of things, to make things better. Thinking beyond the brain Jorge: And that brings us to the fifth and final theme that emerged over the year and that I want to emphasize here, which has to do with using tools and our environment to extend our cognitive system. So, in some way, when we are putting up stickies or diagrams or anything up on the wall, we are making it possible for us to share a cognitive space of sorts. And this is true, whether we're doing it with a note-taking app or stickies on a whiteboard. In taking stuff out of our heads and putting them out into the world, we can somehow extend our minds. And that's why I'm calling this fifth theme "thinking beyond the brain." Conversations about this theme came in two different flavors. On the one hand, we had folks who shared with us their thinking processes and tools. And on the other hand, we had a few conversations that were about thinking in this way itself and I'll say a little bit more about both of those. So, first with the thinking processes and tools. In episode 75, Patrick Tanguay shared with us, how he uses a combination of tools to write one of my favorite newsletters, Sentiers. And it's a setup that mirrors somewhat closely my own setup. Another great conversation about a particular tool was in episode 54, where Kourosh Dini told us about how he's using DEVONthink for building a personal knowledge management system. I was very excited to talk with Kourosh because he wrote a book that helped me use DEVONthink better. If you're unfamiliar with this tool and you are someone who needs to manage a lot of information, let's say if you're teaching or writing, it behooves you to give episode 54 a listen. As I mentioned, I also hosted a few discussions which were not about tools in particular, but a little more meta about how the mind itself works beyond the brain. I'll be frank with you, these were some of my favorite conversations during the year. One was with Annie Murphy Paul about her book, The Extended Mind. Annie's book is the clearest explanation I've read on the science behind the field of embodied cognition. It was one of my favorite reads of the year because it does a really good job at dispelling erroneous notions about how the brain works. And I think that this is a very important subject for designers to understand. Here's Annie. Annie Murphy Paul: I always like to say we're more like animals than we are like machines. You know, the brain is a biological organ. I mean, I know this is obvious, but we really can get very entranced in a way by this metaphor of "brain as computer." The brain is a biological organ that evolved to carry out tasks that are often very different from the tasks that we expect it to execute today. And so, our misunderstanding of what the brain is leads us, as you were saying, Jorge, to create these structures in society. In education and in the workplace, in our everyday lives, that really don't suit the reality of what the brain is. I mean, I'm thinking about how, for example, we expect ourselves to be productive. Whether that's in the workplace, or what we expect our students to do in school. You know, we often expect ourselves to sit still, don't move around, don't change the space where you're in. Don't talk to other people. Just sit there and kind of work until it's done. And that's how we expect ourselves to get serious thinking done. And that makes sense, if the brain is a computer, you know? You feed it information and it processes the information, then it spits out the answer in this very linear fashion. But that's not at all how the brain works. Because the brain is so exquisitely sensitive to context, and that context can be the way our bodies are feeling and how they're moving, that context can be literally where we are situated and what we see and what we experience around us, and that context can be the social context: whether we're with other people, whether we're talking to them, how those conversations are unfolding -- all those things have an incredibly powerful impact on how we think. And so, when we expect the brain to function like a computer, whether that's in the office or in the classroom, we're really underselling its actual powers -- its actual genius -- and we're cutting ourselves off from the wellsprings of our own intelligence, which is the fact that we are embodied creatures embedded in an environment and set in this network of relationships. So, it really... we're really kind of leaving a lot of potential intelligence on the table when we limit our idea of what the brain is in that way. Jorge: While this may seem like we are venturing a little far from the ostensible subject of the show, which is about how people organize information to get things done, there's two reasons why I think it's important for us to delve into this subject. One reason is that, if we are to properly organize information so that we can find things, understand things and so on, we have to understand how our minds work, because ultimately what we're doing is we are designing for minds. And the second reason is that in so doing — in organizing information, in creating these information environments — we are creating contexts of the sort that Annie was talking about there. Even if they are not physical contexts, they are contexts that influence how we understand things. The second conversation I had this year on this subject and which I want to highlight here is the conversation I had with my friend, Karl Fast over episodes 69 and 70. And as you might know, if you've been listening to the show for a while, that's the first time I've ever done a double header. In other words, that I've split a conversation between two episodes. And it's just because we had so much to talk about. And I don't think I can do that conversation justice by extracting just any one clip. But again, I do believe that this is an important subject for you to know about, so I encourage you to check out the whole thing. Closing Jorge: So there you have it, that's a very high level overview of some of the conversations that have stood out to me in the podcast over the last year. Now, obviously there were many more — I told you that we recorded 25 episodes — I don't want to in any way suggest that the other ones weren't as interesting. I just wanted to highlight the ones that I thought manifested some of these themes. And to recap them, the five themes are: aligning our values with our actions, using intentional structures for self-development, practicing information architecture at scale, tools and methods for visualizing systemic intent and then finally, thinking beyond the brain. These are subjects that I care about. And it's no accident that we end up having conversations about these things on the show. One of the interesting things about revisiting them now at the end of the year, is that I can start seeing threads that run through several of the themes. For example, the idea that we need to visualize abstract and complex systems, and that doing so allows us to have better conversations about them. That seems to be a thread that's running through various of these themes. It's true, whether we are talking about our own internal values or our career development, or whether we're talking about a service that we are looking to develop for our clients. And like I've said before, I think that designers — and particularly structurally- and systemically-minded designers, such as information architects — are particularly well-suited to visualize systems in this way. The other thread that I see running through all of this is the importance of considering the context that we are working with and working on, and not just the content of what we're designing. The things that we make are going to be experienced in some kind of environment, whether it's a physical environment or some kind of information environment. And the environment makes a big difference. We understand things in context. And part of what we do as information architects is establish those contexts. That's one of the reasons why I've been emphasizing these conversations about embodied cognition and the extended mind. Because science is making it increasingly clear that thinking happens, not just in our nervous systems, but in our bodies. And more to the point here, it happens out in the world. It happens in our environments and it happens in the tools that we interact with. And again, it's a system that is comprised by ourselves as actors, agents, but also the environments in which we're operating. And we can configure those environments in various ways to help us think better. And I think that this is an important frontier, so to speak, an important area of development for people who design structures of information, who create contexts through language and signs. I've loved the conversations that we've had on the show this year. And that is mostly due to the fact that the guests have been great. I am very grateful to everyone who has agreed to be on the show to have me interview them, to share their ideas, their work, their research, their experience with us. I also want to thank Sarah Clarkson, who I have not acknowledged in the show before. And I'm long overdue in doing that, but Sarah helps me edit the podcast. And her help has been invaluable in getting these shows out to you on time. And of course, I'm very grateful for you; for the fact that you are listening to this, that you have decided to make the show a part of your podcast listening. I would love to know whether there's anything that we can do to make things better. So, please drop by the informed.life, and leave us a note. But for now, I'll just tell you that I am planning to keep the show going. I have guests already lined up for next year. I'm excited about these conversations: having them and also being able to share them with you. So again, thank you. I wish you and yours happy holidays and I look forward to sharing more with you next year.

Sophia Prater is a UX design consultant and chief evangelist of object oriented UX, a methodology that helps teams tackle complex design challenges. In this conversation, we discuss OOUX and how it differs from other methodologies. Download episode 63 Show notes @sophiaux on Twitter Rewired (Sophia's consultancy) Ooux.com The Object Oriented UX Podcast Object-Oriented UX, by Sophia Prater (A List Apart article) Double Diamond Object Oriented UX Podcast, episode 10: Information Archaeology with Ren Pope Entity Relationship Diagram (ERD) The Elements of User Experience, by Jesse James Garrett (pdf) Conceptual Models: Core to Good Design, by Austin Henderson and Jeff Johnson Some show notes may include Amazon affiliate links. I get a small commission for purchases made through these links. Read the transcript Jorge: Sophia, welcome to the show. Sophia: Well, thank you for having me. I'm excited to be here! Jorge: Well, I'm excited that you're joining us as well. For folks who might not know you, would you mind please introducing yourself? About Sophia Sophia: Yeah, sure. I'm a user experience designer. I was based out of Atlanta, Georgia, but I recently did a COVID move up to the north Georgia mountains. I am here in the beautiful... the bottom of the Appalachian Mountains. Kind of where the Appalachian trail starts. I'm very close to that. I got into UX in 2009, which was a great time to be entering the field and really kind of what I'm known for is Object-Oriented UX. I wrote an article back in 2015 in "A List Apart." I had about, I guess, 15 minutes of fame on the internet where that article was one of the top articles for "A List Apart" for the year. It got retweeted and tweeted thousands of times. I was very nervous to publish that article, because I did feel like I was turning the UX process — at least, what I considered the traditional UX process — I was sort of turning it on its head or turning it inside out. And I was really worried that people were going to throw tomatoes at me. But it really resonated with people, which was very encouraging to me. I continued, pounding on this process that I had just started to use in my work and slowly over the years, it came to be that people would come to me as a consultant. I started my own... I finally left the corporate world. I had been at cnn.com as a UX designer. That was my only internal role, but I've been at a whole lot of agencies. And I started my own consultancy in 2014 and within a few years, that became what I was known for. So, companies would come to me to specifically get this type of UX design, Object-Oriented UX. And then I started teaching it, and I started teaching it at workshops. First at conferences, and then I started teaching workshops within companies. So, companies would bring me in. I recently had Facebook bring me in. I've had MasterCard, Credit Karma... a lot of big, exciting companies bring me in to train their team on Object-Oriented UX. So, really that's 100% of my world now, is Object-Oriented UX. It is teaching it, delivering it to my clients, teaching it within the context of teams. Coming into a company... doing that online now. Used to do that in person; doing that all online. Spending a lot of time in Mural, moving sticky notes around there. And now I also teach individuals through a certification program that I was just getting off the ground right before COVID hit in March of last year. So now we're about a little over a year and we're in the middle of the fourth cohort of the OOUX certification program. Object-Oriented UX Jorge: Well, that's great. And we'll get into what Object-Oriented UX is in a moment, but I'm wondering why you think that the idea resonated so much with folks. Sophia: Well, I think it resonated so much, the same reason it still resonates today. Is because this is a way to break down complexity. And I think traditionally, we break down complexity by verb, traditionally. By the actions we think about. What are all the things that a user needs to do in the system? And we can get into more of the why around this, but it's a much cleaner way to break down complexity by the noun as opposed to the verb. And I think a lot of user experience designers are thrown in — especially new user experience designers — are thrown into incredibly complex situations, domains. My first project is a user experience designer, I still remember. It was with Blue Cross Blue Shield. And I was going to be designing a system for people that would design insurance packages. It was within insurance. It was a business tool within insurance, and I knew nothing about insurance. And I came on and I was expected to have wireframes by Friday. And I think that that is such a common struggle for user experience designers: they come in and wireframes are immediately expected of them. If they're working in an Agile environment, they're kind of like a wireframe factory or a feature factory. Just churn out those wireframes without a whole lot of time to gain understanding of the structure of the system. Really get an idea of the business rules and get into those business rules in a way that is collaborative and visual. I think that that's what resonated so hard for people is they saw a way out of that. They saw a way out of that rat race or that struggle of constantly having to deliver wireframes and then having these conversations around the structure. You have stakeholders and engineers. You have the engineer reverse engineering, the wireframe to get the data model out of it, and then you have your stakeholders reverse engineering, the wireframe to try to get the business rules out of it. And then what you end up with is you end up with a whole lot of re-work because the wireframe is usually going to be wrong. And so, then you do the, what I call the "Bring me a rock game," where you're like, "Oh, okay, that rock is too big or too bumpy." Like, "Let me go get you a smaller, smoother rock!" And you go and say like, "Oh, is this the type of rock you're looking for?" So, a lot of times information architecture, which is so important, but as you know, often in our industry and the user experience design industry, we don't do enough of that information architecture. And I think that this is a way to do information architecture in a visual way and in a collaborative way. So, you can bring your engineers and you can bring your stakeholders in and you can all sort of explore the complexity together and break down the complexity together and get out of that surface-level design work, where you're just moving wireframes around. And if you don't have that deep understanding of the system, you're just going to be moving the deck chairs around. You're going to be moving UI around. You're not going to be making systemic change. And at the end of the day, UX designers are incredibly idealistic people. We want to make big change. We want to solve big problems, but if we can't figure out how to get out of that moving the deck chairs around on the sinking Titanic, then work isn't very much fun and we don't have a lot of meaning from it either; you can't draw a lot of meaning from it. Jorge: I'm going to try and articulate it back to you to see if I'm getting it correctly, but the idea that there is a way for designers to work at a higher level of abstraction than how these things manifest in more tangible ways. How then does Object-Oriented UX fill that gap? Or asked another way, how do you introduce folks to what Object-Oriented UX is? Sophia: Yeah, okay. So, what Object-Oriented UX is — And I want to differentiate Object-Oriented UX versus what I call the ORCA process — so, Object-Oriented UX is a philosophy; a philosophy that is based in the fact that people think in objects. And there is a lot of interesting research on that, that we can get into, if you want to ask about that, on cognition and how people think and how people understand the world. And a lot of that is based in objects. So, for the philosophy part of it for Object-Oriented UX, if we say, "this is a philosophy that respects and acknowledges the fact that people think in objects. And to gain an understanding of an environment, you really need to understand what that environment is made up of. What are the objects that make up that environment? And thus, we need to make that clear in our digital environments, just like they're clear in our physical environments." So, Object-Oriented UX is all about defining what your objects are, figuring out what those are, what are the objects in the user's mental model, in the business model, those really valuable things. Objects And I need to kind of take a step back, I think, and define what is an object. I'm very specific when I talk about what an object is. An object is a thing that has value to the user. So, when I say objects, I'm not talking about your navbar or your calendar picker or your dropdown. All those things are valuable, but they are a means to an end. And I often say no user is coming to your site for your calendar picker. It could be the best calendar picker in the whole world, but that's not what they're coming for. They're coming for the event, or they're coming for the people that they can invite to the event. So, an object is going to have... I use the acronym SIP. It's going to have structure, it's going to have instances, and it's going to have purpose. So OOUX is all about saying, "okay. If we know that our users think in objects and just human beings think in objects — not just our developers — human beings think in objects, and to be able to gain understanding, you need to understand what the objects are in that system. And to understand what the objects are we need a certain level of consistency and recognizability to our objects." As the designers of these environments, if we don't get super clear on what our objects are, there's no way — there's just absolutely no way in hell that we're going to be able to translate that to our end users. We're just not! If we can't get it straight on our team and we can't get it straight among ourselves, then that's going to create a lot of communication problems internally, which is a problem that I hear all the time. We've got everybody on the team coming together. And some people, depending on what department you're in or what your role is, you've got the same object, the same thing being called two or three different things and different objects being called the same thing. And you're trying to design complex software. So just getting on the same page internally is going to be absolutely intrinsic to making sure that it's clear to your end users. So, one kind of, I guess... not metaphor, but like journey that I could take you on, Jorge, and the listeners, is: imagine going into a coffee shop. And it's a coffee shop you've never been to. You walk into this coffee shop, but this is like, this is a funky coffee shop. Maybe it's a coffee shop in Amsterdam or something. And you walk into this coffee shop, and you can't tell the difference between the tables and the chairs, and the people. Like you know that there are tables and chairs and people there, you can see the things, but you can't tell the difference between them. And you can't actually tell the relationships between them either. You can maybe like, with intense concentration, you identify a chair, but you can't tell what table goes with what chair, right? Or you can identify a chair, but you can't understand the status of that chair. Is that chair occupied or unoccupied? That would be a very difficult environment to navigate and to function in, yet we create digital environments like that all the time where it's difficult for users to understand, what are the valuable things to me here? What can I do to these things? How do these things relate? What are these things in context of this place? And what is the structure of these things? What is the status of these things? What are the attributes of these things? And that kind of gets into the ORCA process, which stands for: objects, relationships, CTA's, which is calls-to-action, and attributes. And that's the process that I use in my work, and I teach to design really awesome object-oriented user experiences. Jorge: This analogy of the coffee shop is an interesting one, because I can contemplate it in the abstract, but in my real world experience, I've never been in a coffee shop where I can't tell the chairs from the tables or what have you. So, it does feel like a discussion that can get abstract quickly. And I'm wondering how do you draw the bounds around an object? Like how do you determine that something is a table in your systems so to speak. Sophia: Right. and that is actually, I mean, saying, "Oh, we need to figure out what the things are." That's so much easier said than done. And that is a huge part of the ORCA process. We actually iterate on it, to say, "all right, how do we figure out what these things are?" And that is all going to come from research. So, the ORCA process is definitely a "garbage in, garbage out" process. You've got to have good research coming into it. I often say that this is a good process for synthesizing your research before you get into design. If you think about the double diamond, you can literally see the weak link between the double diamond, right? Like, what happens after you get through research and then you just start sketching stuff — you just start designing. There needs to be something that happens between research and design, where you are synthesizing that research into structure and into information architecture. And the ORCA process is just this really kind of like... it's like a meat grinder. Like you just throw the research in and... so when I was interviewing Ren Pope, he used the term "information archeology." And I love that. I feel like that's a lot of what this process helps you do is that information archeology, where you're taking all that research and you're analyzing that research to figure out what are your objects, what are the relationships between the objects, what can users do to the objects, and what are their attributes? And specifically with objects, like knowing, is a table a thing in this particular system that we're designing and in this environment that we're designing? One of the first activities that we do is called "noun foraging." It's really fun. You take all that research, user interviews, interviews with your stakeholders, competitive analysis, analytics as well, of course current site audit, content audit as well is great to have if you have access to that. So, you're taking in all this research and you're looking for the nouns, and you're looking for the nouns that get used over and over and over again. And you're looking for synonyms like, "Oh! Are these the same thing or are these not the same things?" And then that turns into conversations to have with your stakeholders. For example, I was working with a company called Blood Relay and basically what they do is they take blood samples... they're software, but they help facilitate blood samples being taken from the hospital to the lab and then getting the analysis back to the hospital. So, it's pretty complex business software with all the complexity that you get in healthcare and the healthcare industry. And when I was doing my noun foraging, I kept hearing the words "sample" and "product." Sample and product. Sample — product. And they were being used interchangeably. They were being used interchangeably by the business. They were being used interchangeably on the marketing site. They were being used interchangeably on the actual software in places. And one of my big jobs in the beginning was to figure out, are these actually the same thing or are these two different things? Is there actually a relationship between these things and that came with conversations with the experts, right? So how do you define a product? How do you define a sample? Are these... and it turns out they are two separate things, and many products can be taken from a sample. So, you have that one-to-many relationship there. And that's so important to define. If I'm going to be designing software for this, I need to understand the difference between those and reinforce the truth of the world through that user interface. Visualizing systems Jorge: What I'm getting from your description of Object-Oriented UX is that it's not just articulating the domain as a series of nouns and relationships between them, but also expressing it in a sort of visual way, right? That allows people to get a shared understanding of that domain. Is that right? Sophia: Right. Yeah, and that gets into some of the artifacts that we produce in the ORCA process. So, you know, Object-Oriented UX, you could use any methodology to say that eah, we need to define what the objects are, and we need to make them super clear within the interface. So, we don't get into that coffee shop scenario." Where, you know, if I'm designing software for a teacher, which, I did a lot of work in EdTech. If I'm designing software for a teacher and the important things for that particular problem domain that we're trying to solve for, are students' lessons, standards and parents, let's say. I want that teacher to open up that application and to immediately recognize those things. To immediately recognize the relationships and say like, "oh, okay. Yeah, this is just... this is how my world is." And then be able to do really amazing things. Have x-ray vision into those things. Have connections in a way that's super meaningful, and then to be able to do things to those objects that are more difficult in the real world without that tool, or that you know, it's just absolutely impossible to do without that tool. Jorge: That step of articulating the understanding of the domain visually is not to be underestimated. It's a huge part of it. I'm certainly always on the lookout for new ways of doing it because it's so hard to do. I find that a lot of folks have a hard time thinking at that more abstract level. Sophia: Yeah. And when you get into something like a system model or domain model, conceptual model. Basically, when you have lots of bubbles and arrows going? Entity relationship diagram, right? Which we do that work. That's part of the process. We build... I call it a system model, but it's basically an ERD. It often turns into a bowl of spaghetti, and it gets a little bit difficult to track, especially when there's multiple types of relationships between two objects. Then what do you do? Do you have multiple arrows, or do you have multiple labels on the same arrow? I mean, God forbid your system has 17 objects in it, which if you're working in electronic healthcare records, if you're working in insurance... I have worked with tools before, or these, you know, these digital systems that we've had double digits of objects and that entity relationship diagram kind of breaks down. What also breaks down is if you try to start putting attributes in there. Which I've seen done before, where you actually blow out that ERD so it's not just your objects. You actually put your operations and your attributes into that document. That gets really crazy. If you have an object that has 60 attributes, again, just the visualization of being able to show: what are the things, what are the relationships, what are the things made of. I don't necessarily think that diagram is the best way to visualize that and to do it in a collaborative way where everybody can be involved, your engineers can be involved, and especially your business folks. Getting those people involved early is gold. It's magic. Because that's when they're going to be the most useful. So, I hear this all the time: One of my main problems... this is just a recurring theme when I've asked people, like, "What is the most annoying thing about practicing UX design?" Managing stakeholders. I hear that over and over again, and even that word, "managing" stakeholders. We should be leveraging our stakeholders. Our stakeholders and our subject matter experts... usually our stakeholders hopefully are some sort of breed of subject matter expert, at least from the business side. We want to be extracting all that knowledge from their minds, and we need to be doing that early on. But what happens is we try to show them wireframes, or we present diagrams to them instead of getting them to co-create diagrams with us and to really feel heard early on in the process. And the thing is, is, your stakeholders are not trained and they're not good at giving you feedback on your wireframe. And it's very easy. You're conflating presentation and content basically, which we know not to do. We've known that for a long time, not to do that. And yet we still do that, and we still expect quality feedback from our stakeholders when they're looking at structure and design all at once. Design collaborations Jorge: I'm glad you dropped the word co-create in there because as you were talking, I was thinking that the way that I approach the relationship with stakeholders is — or I try to at least — is as a collaboration, right? Where you engage their mind, expertise, their drivers, in the process of designing the thing. And to your point, for a complex system, that needs to start way before you're ready to put things down at the screen level. But there's this dilemma that it's hard to understand the implications of decisions until you see them reflected in something more tangible. Sophia: Yeah, and I think that it's an uphill battle. Let's just say, I mean, they want, often, "they," stakeholders, business folks... they want to see the pictures. They want to see what does it actually going to look like? And I think we've trained them to want to see that. Just because we haven't figured out a really good way to involve stakeholders early doesn't mean it's not possible. I've seen success across so many of my students in bringing stakeholders in early by using the object mapping methodology and going through this process of figuring out... it's just it's color-coded sticky notes! That's really all it is. So, in really nicely organized columns. And it's scalable too. If you have 20 objects, that's okay. If you have 60 attributes on an object, that's okay, too. It really does scale nicely and gives you that sort of bird's eye view of the system. I mean, the other thing that's just so important and not just for feedback, but it's so important to get your stakeholders involved early and your product owners — whoever those people, those decision makers are — on determining scope and timeline and budget. Because when you have a subject matter expert/stakeholder — I'll use those terms interchangeably, even though they're not always — I know they're not always, but if they're this close, if they've been working in the industry for 15 years or something and they say, "Oh, we're gonna create this new feature, we're gonna redesign this part of the product," it's difficult for them to really see the complexity and to understand the complexity. And if we can bring them on board with the complexity and also help elucidate assumptions, help them realize where are we making assumptions about our users… So, I was mentioning before that the input of this process is research, right? And we start with the noun foraging and going through all that research, figuring out the nouns, and we're also looking for attributes at the same time. The ORCA process is a really great gauntlet too, to realize, you need to get kicked back to research. You're not ready to start designing yet because you're designing on too many assumptions. It pulls all those questions from the future where you might be figuring them out when you're in high-fidelity wireframes or something like that. Or God forbid, you're in production where you're figuring out some of these really sticky pieces of business rules. So, this is a tool to help bring all those questions from the future, and make sure that your stakeholders potentially are coming up with those questions too through the process. They're right there with you. They're in the weeds, hands dirty, figuring out some of those questions, and this is going to be able to help you sell more research. Because selling research by saying, "We need to find out more about the user" — that is a really hard sell right there. That's super vague. "Oh, we need to get to know our user." "Great. Okay. Can we just design this product?" But if your stakeholder herself or himself says, "Oh, we don't really understand if... does a doctor work at multiple locations or does a doctor only work at one location? What's the relationship between a doctor and a location? We're assuming that the doctor only has one location, but we're actually not sure how much our doctors are moving around from location to location. Put that in a parking lot." That goes in your user interview transcript, okay? And so, it's the actual stakeholder or the businessperson that has gotten invested in those questions. This is how you sell additional research by getting really specific about what are those questions that need to be asked. OOUX and information architecture Jorge: What you're describing seems very familiar to me, as an information architect, and I'm wondering... I revisited the A List Apart article in preparation for our conversation today, and I got the sense from that article that one of the distinctions between this methodology and something like information architecture is perhaps that... I'm going to use air quotes now, like "traditional information architecture" is more oriented towards content-heavy systems. And I'm thinking of like Jesse James Garrett's elements diagram, right? That is split into what he called information-oriented systems versus task-oriented systems. Would it be fair to say that this is more applicable to the task-oriented systems in that duality? Sophia: So, yeah. I see where you're coming from. The naming around this is coming from… my background is in industrial design. I actually started as a product designer, designing refrigerators for Electrolux. Didn't last long in that career, but that's my background. And then I, again, like going back to the timing, so my very first job as a UX designer was in 2009. This is where Jesse James Garrett would have been like, "We're all UX designers." Right? So, that had already happened. I didn't find out about information architecture until years later. Okay, because just thinking about the timing of when I'm coming into this, I'm coming into it from a user experience perspective and also working on, yes, task-heavy products. So, if you think about, you could even — and I often tell people — you can think about an object... The way I define an object, you can think about it as a content type. Now, I don't like the word "content type." I know this is going to be like controversial, but I prefer the term object, because if I'm working on a system — let's say for used car salesmen to manage their sales and their inventory — a vehicle is not a content type. A vehicle is a thing in a parking lot that is connected to customers, that is connected to sales events, that is potentially connected to other salespeople. Which salesperson sold this car? A salesperson isn't a content type. These are all actual things manifested in the real world and that we are using metaphor to reflect in our user interface. That said, I have used Object-Oriented UX for 100% content sites. So, if we think back to the elections in 2012, when... that's how this all started, I was doing my very first responsive design for CNN election results. That was a lot of data viz, but that was all content. There was no user interaction there; it was all content. And that is actually... I guess the crucible for how I started thinking this way. OOUX and conceptual models Jorge: I'm familiar with another approach to this that I think is similar in at least in intent not in the form it takes, which is the one that I often refer to folks when talking about this stuff and it comes from Jeff Johnson and Austin Henderson's book, Conceptual Models. There you go; you've got it! Not fit for radio, but you're holding up the book cover to the camera. And I'm just wondering if you could speak to the differences between those approaches. Sophia: Yeah, I think they kind of feed each other. I looked back over my notes on Conceptual Models, and most of it I'm underlining and I'm happy faces and check marks in the margins here. There were a couple of places where I like vehemently scribbled question marks. And like, "No, no, no!" But it's little things. I mean, if you think about a concept, the difference between a concept and an object. So, a concept can be... it just feels too... I don't know, the work that we do can often feel very ephemeral, very like it's… You just don't have something good and solid to hold onto. And the objects are these like anchors of understanding and getting super clear on what those objects are and making sure that you have really good lines around them. And actually, like one of the best things that we do in the process is make a glossary, like actually define these things. Concepts though can like be a little squishy. Like financial literacy could be a concept, not an object though, right? The object might be like financial literacy quiz or something like that, you know? Or privacy can be a concept. Also, how Johnson and Henderson described building a conceptual model and what a conceptual model is versus the information that is captured in an object map. The conceptual model they describe it... it's kind of this chicken and egg thing. So, they look at task analysis first and build a conceptual model from the task analysis. I'm kind of the opposite: I tend to like to figure out what are the objects in this environment, in this domain, and hone in on the problem domain, sure. Get those big picture goals on what we are actually trying to do here. But then figure out, "Okay, what are the things in this environment?" And then think about the tasks. What is it? What does a user need to do to those things? And we that's the "C" of ORCA: the calls-to-action. So, what actions — what are the affordances? — what actions does that object offer users? And that's how you get into the task. It's splitting hairs a little bit, but Johnson and Henderson do start off with that task analysis. Sometimes from research, if there's already user stories, we are analyzing user stories coming in. But if those aren't there, there's actually a point in the process that you can get user stories out of the ORCA process. So really just how concept is defined. Also, do you start with a task and then get the objects? I prefer to get the objects and then get the tasks. Start with the nouns. Start with those things and get really solid and clear on those and then figure out what the users want to do with them. Jorge: I'm hearing two things there. One is that the idea of an object is easier to relate to then the idea of a concept, because concepts can be much more vague and more abstract. And the other, which — and by the way, I find both of these ideas really intriguing — the other is that, in some ways, starting with the objects might be a bit more open-ended than starting with the tasks. Because with a collection of objects, you're not necessarily enabling any one particular task; you could enable a myriad tasks, right? There's a collection of objects, and people can do things when they have several objects at their disposal — as opposed to thinking, "What do people want to do?" and then, "What objects do we need, or concepts do we need to enable that?" Sophia: There's just so many fewer assumptions on figuring out what the objects are. Because you can go... I mean, if you can do ethnographic research, great. But going and doing your research again, going back to the teacher example, it doesn't matter what software I'm designing. Like, a teacher's world is made up of students, lessons, classes, standards, parents, other teachers — that's just the truth. And that's another thing Johnson and Henderson talk about the conceptual model being how the user thinks about the system and the task. And I am kind of a broken record when I'm talking about... I'm trying to find the truth of the system. I am trying to find — no pun intended — but like, the objective truth. If I go back to the CNN elections example, if I'm going to build a conceptual model of how people think about elections that's going to be very different than what I would call a system model, which is going to be just the truth of the system. I went in in 2012, I built a system model and I use the exact same system model in 2016 because our electoral college had not changed. We still had candidates. We had states. We had races. And we had results. And we had ballot measures. Those things did not change. And the relationships between those things actually wasn't even up to the user. That's just the truth of the world. It's just our job to communicate what are these things and how do these things relate — versus, I think that the conceptual model is a valid thing to do, and that it would've behooved us to make a conceptual model of how people think about elections. But that's going to be different than what I would call the system model. Jorge: I'm hating the fact that we're running out of time here, because this conversation is getting really meaty. When you brought up the phrase "objective truth," again, you can see this on the podcast, but I think my eyebrows shot up. Well, what you're describing there as a conceptual model is what I usually understand as a mental model. And we might have mental models that map to greater or lesser degree to what I understand of as the conceptual model, which is this set of relationships that you're describing, that I understand as standing together — regardless of what different people might think of them or how different people might understand them. Sophia: In some systems... I mean, there's not just that objective truth, you have to go and figure out, like, what are the users actually want. So, if I had to think about a doctor, is a doctor related to one location in this particular context, or is a doctor related to zero to many locations. Maybe some doctors don't have a location at all associated with them. Some doctors are going to have three locations associated with them. So that's going to come from the users and like, what is the truth of the user? You know, again, it comes back to that objective truth and sort of balancing the objective truth of the business and the objective truth of what is happening with those users and what those users actually want and need. And then there's also the back and forth of like how much do we need to create an idea in the user's head? If this is a completely new thing, how do we reinforce that business model and how the business works so it's very, very clear to the users how these things work together. And then do we kind of go back the other way and really understand then the user's mental model of these things and reflecting it back in the system. So it is that kind of... it's a balancing act, for sure. Closing Jorge: Well, thank you. That helps clarify it quite a bit. And I still feel like we have more to talk about and I'm hoping that we'll be able to do so again at some point. For now, where can folks follow up with you? Sophia: Probably the best, easiest place is ooux.com. So, if you go to ooux.com, and there's a green button, says something like, "Join the fam," or "Get involved," or something like that. I forgot what it says. All the good stuff is there. There's an Object-Oriented UX happy hour, so that would be a meetup — an online meetup. There is a podcast, the Object-Oriented UX podcast, newsletter, and of course the certification course as well. But just go to ooux.com and you'll find it. Also, @sophiavux is my Twitter. Jorge: Well, fantastic. I'll link all those from the show notes. Thank you so much, Sophia, for being on the show. Sophia: Thank you so much for having me.

This is the first of a two-episode series focusing on what to think about when making an app. In this episode, we discuss how strategy and project scope can be used as the foundation of a logic structure in developing an app. We share our experience on how you can use your user and business needs to build a solid foundation and set you up for later success. We reference the frameworks and diagrams in Chapter 2 of Jesse James Garrett's seminal user experience book, ‘The Elements of User Experience' throughout our discussion. Click here to Download the free PDF.

Jesse James Garret is a renowned leader in the user experience design field. He's a co-founder of the influential UX consultancy Adaptive Path and author of The Elements of User Experience. These days, Jesse coaches UX design leaders. In this conversation, we discuss the relationship between leadership and information architecture. Listen to the show Download episode 58 Show notes Jesse James Garrett's website @jjg on Twitter Jesse James Garrett on LinkedIn The Elements of User Experience: User-Centered Design for the Web and Beyond, 2nd Edition by Jesse James Garrett Peter Merholz Finding Our Way podcast MacGuffin Concept map Mind maps Some show notes may include Amazon affiliate links. I get a small commission for purchases made through these links. Read the transcript Jorge: Jesse, welcome to the show. Jesse: It's good to be here. Thank you. Jorge: Well, it's my pleasure and honor to have you on the show as a guest. I don't imagine that there are too many folks in the audience who don't know you, but for those who don't, would you please tell us about yourself? About Jesse Jesse: Sure! I'm Jesse James Garrett. I have been working as a professional in the user experience field for, 20 years or so now. If I am known to you at all, I am probably known to you, dear listener, from my book, The Elements of User Experience, which was published in 2002, or the work of my company Adaptive Path, which I co-founded in 2001 and was a part of through its acquisition by Capital One in 2014. I now work as an independent leadership coach working with leaders of UX design teams. Jorge: And as we're recording this, I believe that the founding of Adaptive Path happened 20 years ago. Jesse: Yeah! Yeah, yesterday was the 20th anniversary of the launch, a fun milestone to reflect on. Jorge: Well, the influence that the work has had both in Adaptive Path and The Elements of User Experience is palpable in the field. I occasionally still run into people who bring that diagram — "The Elements of UX" — bring it up so many years later, and it's an artifact that has proven long-lived. And I'm wondering if you have any thoughts on why that might be. On the longevity of The Elements of UX Jesse: It's a little bit of a mystery because Elements seems to have an enduring appeal to people that other similar models don't seem to have that kind of traction. I think that part of it is that I tried with the model to capture — as much as possible — to capture the things that I thought were less likely to change. Although I put the date really prominently at the top of the document when I first published it, in part because I was expecting to update it. I was thoroughly expecting there to be multiple versions and each one would have a date stamp and there would be iterations and evolutions of the model. But then when people started using it and getting really attached to it, I changed my mind about it and felt like I should really leave well enough alone and not tinker with it too much. I've made some little adjustments to the language that I use in the model over time, but the model itself has stayed the same. And I think the fact that people keep picking it up and putting it into practice is surprising to me as it is to anybody, I think. Jorge: Apart from minor tweaks to the language, do you feel like the model stands up overall? Even today? Jesse: Well, I do really think that if it didn't people wouldn't be using it if it didn't produce some sort of positive result... It may not be the positive result I intended. Yeah, I mean, there's a lot more to be said than what is encapsulated in that model. It is intended to provide a basic level framework and obviously there's a lot more complexity to what it takes to actually get those things done. And there is a lot of nuance to how these issues play out. So yeah, in some ways it's not my call as to whether or not the model is still relevant. It's like, it's up to other people as far as I can see. Jorge: Well, that's as good enough as any test for relevance, right? Whether people are using it or not. And for any listeners who might not know what we're talking about, this is a model that describes the work of user experience as happening in... would it be fair to call it five distinct layers? Jesse: Yeah. I call them 'planes' in the book, but it's a visualization. It's this sort of layer cake, sort of visualization of all of the considerations that go into UX work. Jorge: And they range from strategy at the lowest plane, scope, structure, skeleton and surface, which is the stuff that we see when we interact with a product that has been designed. Information architecture and leadership Now, I asked you to come on the show, not to talk about The Elements of User Experience, but because you and your fellow Adaptive Path co-founder and our mutual friend, Peter Merholz recently wrapped up what I'm describing as the first season of your podcast, Finding Our Way, and you and Peter had a conversation in that final episode where you synthesized the things you'd learned in the course of that first season. And you made a statement, you said, and I'm going to quote you back to you now, which is always nerve wracking! You said, "I think leaders are of necessity, orchestrators of systems. And systems instantiate knowledge as information architecture within them. So, the IA that gets embedded and coded, baked into your systems, becomes the way that the organization understands the world. And so, it is on the leader to imbue, infuse, enrich that IA with as complex and nuanced and understanding as they possibly can." There's a lot there... Jesse: I believe that statement. So, so that's a good test. Jorge: That's great. But I feel like there's a lot there to unpack and I wanted to talk about it with you. The context of the podcast, Finding Our Way, is about design leadership, but this strikes me as a statement that might apply to leaders in any field. Jesse: I believe that's true. I believe that any leader, anyone who gives direction to people in an organization, is on some level a steward of the organization's understanding of the problems that the team is trying to solve. And that understanding — when that gets systematized -information architecture is systematized understanding; it takes the associations between ideas that give meaning to human endeavor, human behavior, the world, and makes that concrete in ways that systems can then use. So that knowledge, that insight, can be scaled. And a lot of organizations run into trouble when their information architectures internally don't match the nuances and the complexities of the problems that they're trying to solve. Either problems that they're trying to solve for users or problems that they're trying to solve as a business. Businesses are often getting caught flat footed by market trends that they didn't see coming because they weren't paying attention to the right signals. Because those signals weren't part of the fabric of their understanding of the problem that they were facing. So yes, absolutely. We were talking about the context of design leadership specifically because that's what the mission of that show is. But yeah, I completely agree with you. It is something that I think is a part of what leaders do for organizations is give shape to the ways that organizations, hold onto the ephemeral meaning that otherwise just lives in the heads of the people in the organization. Jorge: Now, this is something that has been happening for way longer than we've had the phrase 'information architecture' and I'm wondering if there are any practices, tools perhaps, that have been around for a while that might point to this function of leadership, as a going concern for leaders. Jesse: It's an interesting question because honestly, a lot of the sensitivity to this stuff, when you're talking about what data does an organization collect, what systems does an organization put in place to make sense of the data that it has collected — this kind of stuff often ends up being the domain of like IT and business analytics and people who do some serious number crunching, which is fine and great. And, in the case of a lot of organizations... I've done a lot of work with financial services organizations. Insurance companies are fascinating in this respect because the actuarial tables rule all, in that business. And the keepers of the actuarial tables really are, expressing a point of view about what constitutes risk in the world. Jorge: And that is a formal structure of information that is stewarded by someone in the org, right? Jesse: Yeah. It's the foundation of the business. If your actuarial tables, as an insurance company, don't reflect the reality of things, then you're a bad insurance company, because you're likely to take on risks that you shouldn't. Jorge: What this implies for folks who are either in positions of leadership or aspiring to be in such positions, is that A) they need to embrace systems thinking, right? A systemic perspective of the work. And the other is that it would behoove them to look for the structures that best articulate the core of the business somehow. And there are formal information structures in a lot of organizations. You've pointed out that in the case of insurance, they're very manifest, but what you're saying there resonates for me in other fields as well. Jesse: Yeah. It's definitely something that I saw in my consulting career across, a lot of different kinds of organizations. I feel like every organization has its own sort of arbiter of truth, internally. I think one thing that we've been doing for a long time as UX practitioners, or at least, one thing that we often did as UX consultants was encourage the leaders that we were working with to step into storytelling as a tool to be able to make their case for what they wanted to do from a design perspective. Storytelling is a sense-making activity. It's a way of giving people an understanding of the world. It's very similar to information architecture in that way. So, for leaders of any stripe, whether you're leading a design team or whether you're leading any other kind of team, to take a step back and ask myself, "Where am I the sense-maker for the organization? Where am I the one who is interpreting and giving meaning to information?" And sometimes that is happening largely in Slack or emails to the team or other kinds of communications, and sometimes that's happening in the context of more formal data structures like you and I have been talking about. So, if the leader is noticing and attending to sense-making as a core part of the value that they bring to the organization as a leader, then they can look across their communications and the various pools of data that they may be responsible for tending and to interpret what they're doing in terms of creating more robust and more nuanced and more accurate information structures. Jorge: I'm hearing two things there. One is that leaders need to have the wherewithal to understand the organization, its context, its goals, its way of being in the world — understand it in some kind of systematic way. And the other thing I'm hearing is that they also need to be able to reflect that understanding back to the organization — through things like stories — in ways that affect how the team understands what they're doing, basically. Jesse: Yes. It gives meaning to the team's activities by placing those activities in a larger frame — a larger context. IA as MacGuffin Jorge: In my experience in interacting with teams and organizations and their leadership, I get the sense that these two functions — the "let's first structure the environment for ourselves, and then, let's think about how we share that structure with others" — they're happening, to greater or lesser degrees, in different organizations. But they're happening somewhat informally. Like, I haven't seen too many processes to say, "let's now draw up the information architecture for what we're doing here." Usually, when people talk about information architecture, it happens in the context of redesigning the website or making changes to the navigation structure of our apps or what have you. And in some ways, those projects end up being kind of MacGuffin for these deeper conversations that need to happen. And I'm wondering if there's a way to overcome that gap where we do information architecture more explicitly in service of having the organization understand itself better, or the team understand itself better and its role. Jesse: Yes. I have done work like that in the guise of process work, that engaging with a team, trying to understand what the different elements of the team are, what each element of the team is intended to accomplish, how those pieces are supposed to work together. In order to engineer any kind of a process like that, that has to be rooted in an understanding at a conceptual level of what are the factors that go into play in producing whatever the team is there to produce. Or achieving whatever the team is attempting to achieve. And how are you making sure that all those factors are accounted for? And how are you setting priorities among those things? These are all decisions that inform the process work, but that's not the process work. That's the IA work that underlies the process work. Jorge: Is this more of a top-down or a bottom-up effort? Jesse: I think of it as being more of a top-down effort, just because I am... I've been thinking a lot about stewardship as one of the elements of leadership that we don't really talk about. Which is that you have a group of people and a set of resources in your care as a leader. And that creates certain obligations from my perspective, on you as a leader, to ensure that you pass those things along to the next leader in the healthiest possible state that you can. And that means looking out for your team. It also means looking out for your processes. It also means looking out for your systems. And it also means looking out for that deep, underlying understanding that drives all of those things. I mean, where are leaders doing that information architecture work right now? I'd say they're doing it every time they structure a document that presents to their executive leadership what they want to try to accomplish with their work. Jorge: What that hints at — to me at least — is the fact that this storytelling function that you were talking about earlier — the part that has to do with sharing with the rest of the organization, the understanding that we have of our own understanding — that act of telling the story influences the understanding. It's like the two are related, right? Jesse: Yeah. Jorge: There's a feedback cycle happening, where you put it out there, you say, "well, this is how we see things." And maybe your peers and other groups might say, "no, it's not like that at all. From our perspective, it looks like this!" And that tweaks your own architecture, no? Jesse: Yeah, I mean when we talk about cross-functional collaboration, what we're often talking about is the process of aligning the differing information architectures. The differing models understanding of the problem that these cross-functional teams have. That the design team has one understanding of a problem, technology team has a different understanding of the problem, business folks have a third different understanding of the problem. These things need to be reconciled in order for those teams to move toward a common goal together. So, we don't end up with the design team is designing a car, but the engineering team is building a submarine while the business folks have sold to the senior leadership that we're building an airplane! Jorge: This is such important work, and it strikes me — just in hearing you describe it — that it's something that happens often as a side effect of other initiatives. It's not like you set out to explicitly build that understanding and compare the delta with the understanding of that other org. It's more that both of you are tasked with collaborating on something and the process of collaboration is what surfaces these distinctions. Jesse: It forces it! Yeah. You're not really doing it as a separate explicit step because it's part of everything you have to do as a leader, in a lot of ways. Leadership as a design problem Jorge: It feels to me like we're talking kind of in the abstract when we talk about these understandings. And when we say that somebody is presenting to their colleagues, what might come to mind is something like a slide deck, right? And folks tend to gravitate towards things that they can see and understand. And the slide deck might be the manifestation of this understanding, but it's not... it might not be its purest expression. And I'm thinking of things like concept maps, where we map out our understanding of a domain, just not even for sharing with others, but to understand it ourselves. And I'm wondering if in the process of stewarding this understanding of who we are, what we do, what our role is, how we're structured, what our processes are... I'm wondering if there are artifacts that could embody that kind of abstract understanding? Jesse: I think so much of it depends on the leader. And I feel like what you're reaching for, or suggesting, is a mode of leadership that is really kind of an IA-centered or an IA-driven leader. And that's a very interesting idea to me. I haven't met one. You know, I would say I have met some leaders who, because of their experience with collaborative ideation processes, are used to getting their ideas out in a way that is still abstract. You talked about concept maps. That's a great example. Mind mapping is a tool that I've seen business leaders use. That is definitely an information architecture tool. You're doing an IA process when you're engaging with mind mapping. But they wouldn't necessarily think of that as IA work. And they don't necessarily make it central to how they analyze problems or make decisions. The people that I've worked with who have been those kinds of leadership roles tend to be a little bit more constrained and not have formal tools for getting their ideas out. They just communicate. And they do it in the context of structuring and organizing their communications. And a lot of times, that is what is foisted upon them by the communications culture of the organization. I have worked with organizations where there were such strong cultural... Taboos around what you could and could not do in the context of a slide deck. Where, you know, like I had worked with an organization, for example, where if you had anything that was going to the board of directors, the Deck had to follow a very specific structure and format. And if your idea needed more than three to five basic sections to express that idea, your idea was not ready for the board of directors. Because they were consuming so much content from across a very large organization, they needed everything encapsulated and summarized and standardized so that they could make the decisions that they had to make. But what that forced on the entire organization was a communication style that drove out nuance. Drove out conversation. Drove out a lot of what you're talking about, which is that moment to moment flexibility in the decision-making process that you know, for a lot of decisions is utterly necessary. Jorge: Yeah, it comes back to this notion of top-down versus bottom-up, right? Because the implication there is that there is a level of nuance that is inappropriate for folks at this level. And that's a questionable stance, I think. Jesse: Yeah. Jorge: So, you advise leaders, you advise folks who are stepping into leadership. How would someone who is either in a leadership position or looking to get into leadership, how could they develop these particular muscles? Jesse: The way that I talk to folks about design leadership, who have come from a design background -that is to say they've been doing design work — is that leadership is just another design problem. And you're working with different materials and you're working toward different outcomes and you're having to follow different principles, but the task is the same task. It is a creative problem-solving task. It is a systems-thinking task, as a leader. So, looking at the ways that you're already doing that systems-thinking, the ways in which you already doing that architecture for yourself in the work that you're already doing, and those will be your strengths. And those will be the pillars that you can lean on that are going to support your work as a leader going forward. They will evolve and they will not look like what they looked like when you were doing content inventories or task flows or whatever other artifacts you might've been working on as a designer. But the skill set that you're building is the same skill set. Jorge: So, it's in you, you just have to recognize it as such, and build into it. Which is kind of what we've been talking about, right? Getting the sensitivity to read the environment and articulate it in a structured way. Jesse: And also, to remain true to your own perspective. You know, I see a lot of people who step into leadership for the first time, and they start trying to emulate what they've seen of other leaders. Which is a totally natural thing to do. It makes total sense. However, every effective leader leads from their own strengths and recognizes that those strengths are going to be different from the strengths of the people around them, and leverages that difference. And leaders who try to emulate modes of leadership that don't suit their natural abilities, they struggle. And they create a lot of hardship for themselves that they don't need to have if they could just believe that they already had the power. Because I believe they do. Closing Jorge: Well, that strikes me as a fabulous place for us to wrap this conversation. It's an empowering exhortation to folks to be themselves and develop their own powers. Thank you so much for that, Jesse. Where can folks follow up with you? Jesse: You can find me on Twitter. I'm @jjg. I'm also on LinkedIn from time to time these days. You can find our podcast, Finding Our Way, at findingourway.design, and you can find out more about my coaching practice at jessejamesgarrett.com. Jorge: Well, thank you so much, Jesse. It's been a real treat having you on the show. Jesse: Thanks, Jorge! It's been fun.

I feel like this is another dream coming true. I talked with Jesse James Garrett, one of my favorite UX authors; he wrote in 2002: The Elements of User Experience. We talked about his history, from a writer to one of the founders of UX, his consultancy Adaptive Path and the acquisition by Capital One. We also found some time to chat about post-rock and his recent work as a coach for design leaders at jessejamesgarrett.com

Have you ever found a framework, a diagram, that perfectly summarized an important and subtle idea? That somehow made that important idea concrete and easy to talk about?   That's why I'm really excited to share today's conversation with Emily Levada, Director of Product Management at Wayfair. We'll dive into a Trust/Communication Map that, as a manager of a huge team, helps her navigate an essential question - is our team talking too much or not enough?    On the conversation design, meta side, I want to point out this important idea: The power of a visual to focus and shift a conversation. All conversations have an interface - either the air, a chat window or a whiteboard - a *place* the conversation actually happens.    A diagram creates a narrative space for a much more clear and focused conversation to take place - the diagram triangulates all of our individual inputs and ideas.   I stumbled across Emily's medium article where she breaks down this trust/communication trade off using this simple visual map. She points out that the map we talk about is commonly attributed to technology entrepreneur and venture capitalist Ben Horowitz. In his book The Hard Thing About Hard Things he writes,    “If I trust you completely, then I require no explanation or communication of your actions whatsoever, because I know that whatever you are doing is in my best interests.” With Communication on the Y axis and Trust on the X, you clearly don't want your team in the lower-left quadrant - low trust and low communication. Things will get pretty rocky there, fast. Increasing communication can help, but wow, will your team get burnt out, fast. The upper right quadrant, from a manager's perspective, is waste - in this region, we're having too many meetings. We can likely decrease communication, slowly, until we find a perfect balance - low friction, high trust teams.    Emily, at the end of the episode outlines how she uses this diagram to have this crucial conversation with the teams she manages: Where does each member of the team feel we are on this chart? Are we spending too much time talking or not enough? If you use this diagram with your team, please let me know! Email me at Daniel@theconversationfactory.com As Emily points out, when there's total trust, there's a sense of safety - When my collaborators trust me to make things work, I feel empowered to find my own way, even if I take the long path, down some blind alleys. Psychological safety is at the absolute core of teams that can make great things happen. We need trust and safety to make good decisions. Amy Edmonson, who coined the term Psychological safety, opens her book “The Fearless organization” with this amazing quote from Edmund Burke, an English philosopher from the mid-1700s “No passion so effectively robs the mind of all its powers of acting and reasoning as fear.” With the right balance of trust and communication, teams can feel safe to act, learn and iterate.  For all of this and a lot more, listen to the rest of the episode! Show Links The Trust/Communication Curve https://medium.com/@elevada/the-trust-communication-trade-off-4238993e2da4 Agile at a large experience design organization https://medium.com/wayfair-design/the-agile-methodology-of-a-large-experience-design-organization-178eccbb73c8   The Agile manifesto https://agilemanifesto.org/ The Five Elements of User Experience from Jesse James Garrett http://jjg.net/elements/pdf/elements.pdf   Minimum Viable vs Minimum Lovable Products https://themindstudios.com/blog/mlp-vs-mvp-vs-mmp/   Making Time in the Morning https://www.jeffsanders.com/the-5-am-miracle-podcast/   Project Aristotle and Psychological Safety https://rework.withgoogle.com/print/guides/5721312655835136/   Amy Edmondson, The Fearless Organization https://www.amazon.com/Fearless-Organization-Psychological-Workplace-Innovation/dp/1119477247   The Learning Zone https://hackernoon.com/great-teams-5f15cb718c20   The Trust Equation from the Trusted Advisor https://trustedadvisor.com/why-trust-matters/understanding-trust/understanding-the-trust-equation   High CUA Organizations, from High Output Management by Andy Grove https://www.amazon.com/High-Output-Management-Andrew-Grove/dp/0679762884/   Helpful summary is here: https://charles.io/high-output-management/ Full Transcription   Daniel:            Emily, we're going to officially welcome you to the conversation factory. Thank you for making the time to do this and for waiting for me while I fixed all of my technical difficulties.   Emily:              Thank you for having me.   Daniel:            Awesome. so you can you tell the listeners a little bit about who you are and what your role is?   Emily:              I can start. Sure, sure. I'm a director of product management at Wayfair. I own a set of technologies that sit at what we call the bottom of our purchase funnel. So when you're shopping on Wayfair, that's the product detail page, the page that tells you about the things we sell, ah, they cart and checkout experiences. And then some other things like customer reviews or financing, how you apply for financing, understand financing on our side, our loyalty program. And I run a team of product managers doing that.   Daniel:            Yeah. And so we talked a little bit about how do you get a hundred designers to all talk the same language. Like, cause you've got to, you have a big team. How do you get them all pointed in the same direction as a word? Like tell us about managing that conversation cause like you literally can't have a conversation unless you're speaking the same language. And so like there's that step back that you're working with.   Emily:              Yeah. So I just shared an article that my design partner had written about our written design process or design toolkit as you might say. I think, you know, in any organization that scaling how you build the mechanisms for people to build shared vocabulary to be using the same tools. It's one that we invest time in. I don't know that there's any magic to it besides you know, making the time to have the conversation of what's the language that we want to use. Daniel:            Yeah.   Emily:              ...And being really intentional about it, right? What's language we do want to use, what's the language we don't want to use? How do we want to talk to new employees about these things in ways that are simple and digestible for them. And then they can build on over time. And then creating the mechanisms to make sure that coordination keeps happening. And you know, I think as we get more into this, you'll see that for me, how, how people communicate across the organization is a big part of what I spend my time thinking about.   Daniel:            Yeah. I really enjoyed Jessie's article. We'll definitely link to it. One of the things that kind of blew me away was this idea that because I've worked with organizations where they're having a sense that, oh, we should have our own proprietary design thinking process. We should have our own flavor of agile. And he's like, we wanted something that anybody coming in would generally recognize. And so it's like, yeah, it's nothing. Here it is, it's kind of the double diamond. It's, it's the basics of design thinking, but doing it is the hard part.   Emily:              Yeah. And I think one thing that's interesting is that we're actually not that dogmatic about how those things get applied. So really there's a lot of license to do what works best for your team. Right. Designers are part of a cross functional team with engineers, and analysts, QA, product managers and the designer should bring the tools to bear that are gonna help us understand customer problems and talk to our customers and prototype and test things. But we, but we're creating a toolkit that designers can pull from in order to do their work effectively.   Daniel:            Yeah. It seems like a lot of work went into, into building that, that toolkit that they can pull from, but also like, I mean, this is the, this is the essence of agile, right? It's, it's, it's people and interactions over processes and tools or am I misquoting it? That's embarrassing. It's something like that. So like, let's talk about your origin story. Like how did you get into this work? How did you get your start and you know, where are you hoping to sort of ...what's next on your journey with, with the work that you're doing? Sure.   Emily:              More so. I, rewinding to, let's say college I have two degrees. I have a degree in psychology and a degree in theater production. I'm a theater kid.   Daniel:            That's amazing. I could see how that could prepare you for many, many, because everything's a circus and you know how to put on that. Let's put on a show like you know how to do that.   Emily:              Keep the drama on the stage, we say yes. I actually, there's a tremendous number of parallels that I think are really interesting. But psychology and theater, they're both studies of how individuals behave. One scientific and one's artistic, but that's a common theme. And as I transitioned in technology and got an MBA, I fell in love with the idea of customer insights. So that we could understand it and influence people's behavior with the technology that you build. And so that's kind of one thread that pulls through here. And then that, that also fuels a passion for organizational behavior. How do I understand the behavior of the people around me and how we interact with each other in the conversations that we have in our organization? And then I think the other interesting thing about theater, well there's a, there's a product management tie. Building theater is cross functional. You have designers, you've technicians. I've learned over the years that the conversation that happens between a set designer, a stage carpenter and a scenic painter is no different than the conversation that happens between the UX designer, a backend engineer and a front end engineer.   Daniel:            Okay. Can we, can you break that down? Cause like I don't think many people know those roles in maybe, maybe those words in either context. Yeah. Lay those out. Cause like this is the difference between like the, like the skin and the concept and how it works, Maybe....   Emily:              Right...Well, so, so in both cases you have someone like a designer who's coming up with a concept or understanding maybe it's user behavior or the story that we're trying to tell. The content that we want to have in what we're publishing. And then but having the concept or having the vision is different than having the executed product. And so then you have a technician, right? You have engineers you have carpenters and painters and, and then really that's really just specialization, right? Those people are delivering on the thing that's been designed. And and they may have different types of specialization. And then I think where the thing that's the same in my role about that is that what you deliver is never going to be exactly the thing that you designed. And there's a constant process of learning and discovering the unknown and prototyping or having to cut to meet a budget or a timeline changing scope.   Emily:              And that's the same, right? It's actually the same conversation. So I found a lot of skills in software development, product management that were skills that I had had developed earlier and loved that, that managing that conversation between those people and that translation between the functions. And then the other thing that I think is super relevant to the trust part of the work that I do is that the theater is a space and it's a workspace where coming to work emotionally available every day is part of what allows you to deliver the work. Like my, my early career, my conception of a business meeting was a bunch of people get in a room, we'd watch, a play. And if at the end of the business meeting everybody wasn't crying or laughing or right, whatever it was then like your product was not delivering the emotional experience that you need it.   Emily:              And so your ability to then work through you know, how do I build something that resonates more emotionally, it was a, it was a critical part of that experience. And so I think that in the business world that translates into being, you know, high EQ, whatever that means. But there are some notion that that idea that you sort of come to work present and authentic and kind of with your emotional switch "on". That is something that I'm just really interested in and passionate about. That's kind of the way that I'm built. And and so how that translates into a different, you know, range of the world that I'm in today has been interesting question. I mean, so like, let's, let's dig into that a little bit because I think the idea that our product should turn the customer on like that it should hit   Daniel:            Them and the gut the way like a great production should is a provocative one. And then like, so there's, there's these, there's that level of the, it should have that effect on our, our end user, but we should also be excited about doing it. And then I also need to sort of manage myself through that whole process of, you know bringing my best self to that dialogue, the interaction with all the people who are supposed to be making this thing. But there's a lot of, there can be a lot of conflict intention in that black box of making something that people are gonna love.   Emily:              Yeah. Yeah. I mean, I definitely, I think sometimes it's surprising to people that even just this concept of, hey, I want to build something that people love, that hey have emotional reaction to that, that I might talk about ecommerce that way. Right. Can we stupid. You're selling stuff, right? Yeah. But we all have to buy stuff, right? You right. You still want an experience that people really love. And also, you know, your home is intensely personal. And so for us, the experience of finding the right things for your home and crafting a space, crafting an environment that is a backdrop for really important parts of your life and your family and your friends your kids that's very emotional. It's a very emotional process. And so you want the tools that you're giving people to, to, to go through that journey to be emotionally resonant for them.   Emily:              You know, I think this is, there's lots of conversations about this in the product world. This is sort of, you know, you're aiming for a minimum viable product versus a minimum lovable product, right? Yeah. It's that that difference. But I think for me the organizational side of it is equally as important. You know, we, we know that we, we all want to have teams that are creative, that are risk tolerant, that move fast. And then we have these really complex organizations and at the end of the day, like how do you build teams that can do those things? My point of view is that you really need to have the emotional component in order to build teams that can, can embody those qualities. Daniel:            Yeah. So I want to go back, I want to, I want, I want to go deeper, deeper into the trust and safety piece because that's, that's important. But I was trying to find this diagram that I just sent to you. And the chat window, I need to find who originated it. This was like one of my favorite diagrams when I was getting started in UX, just to like talk about the difference between like vision and concept and details. This is another version of it. Product is functionality. Product is information. There's so many versions of this just the idea that like, there's all these different layers in the process of making something real and my own sense that like everybody wants a seat at the table, right? Cause like even those people are highly specialized where they're like, oh, I'm just gonna make an "x". If they don't understand the vision and if they're not bought into the vision, people feel excluded. Yeah. People feel like, oh, I'm just a doer. Like, so I guess my question is like, you as a leader, how do you make sure that the people who are part of creating that vision feel like they're all included? Like how do you create inclusion?   Emily:              Yeah. I mean it's interesting because yes, they want to feel included, but I would actually go so far as to say that they need to be included if you want to get the right product. Because if you tell people what to build, they'll build you what you tell them. If you tell them why you want to build it, they're going to build something better than what you asked them to build.   Daniel:            Yeah. I'm just...that's a solid gold quote right there.   Emily:              Uh and so I think that the question then very tactically becomes when is the right moment in the process to involve which person, what pieces of information are you giving them? But I think really it is about orienting around why, why are we here, what outcome are we trying to drive, not what are we trying to build. And you know, ultimately the conversation shifts to what are you trying to build. But I think partly there's a, there's also a listening aspect here, right? You listen to the conversations that people are having and if people are getting stuck and you start listening and are having conversation about the what you try to back them up to the why, right?   Daniel:            Yeah. No I agree. Yeah. I mean there's so many avenues to go down because in a way like there's another piece which is like how are you seeing the patterns and all of that and all of those conversations that you're, you're, you're pulling together cause you're, you're looking at this at an organizational level as well, right? Like you're in a lot of different places and listening to a lot of different things. Like how do you make the time to start to weave it back together for yourself and to a clear narrative like "this is What's happening?"   Emily:              Some of it is I think about pattern recognition, right? This is true of all feedback. So one thing that I say about feedback a lot is that you know, any feedback, whether you're giving, receiving feedback, it's a data point. And if you, if every piece of feedback you get, you took immediate action on and treated as equal to every other piece of feedback, like you'd go mad. And so when you get feedback or when you hear a thing, it becomes a piece of data and then up to you to look at all of the pieces of data, have you got and, see the patterns, prioritize which things you want to act on and then go act on them. And so I think, you know, as an organizational leader, as I'm doing one on ones or doing skip level meetings or listening to questions, people are asking in various forums or listening to the water cooler talk. It's sort of data that goes into the pattern recognition machine, right?   Daniel:            Which is your brain. Are you using a whiteboard or a like a dashboard or anything to track that? Or is it just really like just filtering …   Emily:              Yup. I have some, I have a notebook that I you know, clutch very tightly and carry with me everywhere I go. That I think is my primary, you know, hey, I'm just gonna write down things that I see or observe. I have a window of time. I get to work very early in the morning. I get to work at seven. And so from seven in the morning until nine when the kind of meetings start is my time to really kind of step back, reflect on what I'm need to do or what I've heard, what's new, where things are and get some focused work time. And so I think being able to just carve out the time to sort of step back and say, okay, is there anything here that I, that I need to be paying more attention to or taking more action?   Daniel:            I have to say like in so many of the interviews I've done, one of the insights for me is that of all the conversations that we have to manage and maybe design the one with ourselves is maybe the most important one. And so having just, just having a notebook is like, like that's, that's huge. Right? Yeah. Really amazing.   Emily:              Yeah. You know, I'm also very lucky, I have a wonderful set of people around me who are great sounding board for all the Times that I'm like, Hey, I think maybe there's a thing here, but I'm not really sure. I let me just say it out loud to you and play it back for me and you know, help me see if there's really a pattern or not. Yeah,   Daniel:            Yeah. Analysis through dialog. Super important. So I think it would be useful for us to talk about like, so I found that this medium article that you wrote using this, you know, don't I just love visual frameworks of trust versus communication curve. And how did you, like where did that how does that framework filter into your life? Where did it come from for you and how do you, how do you actually apply that in your own work you use? Just talk to us a little bit about that little knowledge chunk and then we'll, sure, sure,   Emily:              Sure. So we, we first introduced the concept of psychological safety, which related but not the same in 2017. I actually, so psychological safety I think was popularized based on Google work, Google's project Aristotle. There's a New York Times magazine article about it that profiles a woman who's on Google's people analytics team. And she was a classmate of mine in my MBA program. And so I had been following the work and thought it was really interesting. And we actually introduced a concept of that is one level higher than the psychological safety concept, which is the learning zone. So the, the researcher who, who came up with the concept of psychological safety actually has a framework that's two axes and psychological safety is one access. And the other access is accountability, accountability to results. And, and when you have both of those things, you get this magic thing called learning.   Emily:              And I think that what was really important about that, cause you ain't swim it cause like I'm looking at that as a two by two from like very accountable and very safe means I've learned something. Yeah. Put that together for me. Yeah. So, so very accountable means like there's pressure, there's pressure to do, right? Like you, you, you're gonna run fast because there's pressure. But if you have high pressure and low psychological safety, you get anxiety, you get fear of failure, right. That, that and that is a killer, right? Especially in an agile process where there's a requirement to like take risks and try things and it, you know, that every single thing you do is not going to be a win. What you want is for every single thing you do to teach you something, right. The, to be another step on the journey to understanding where you're going.   Emily:              Oh, this is incredibly important in spaces where I remember it's it's Andy Grove. It's from high output management. He has this concept of, high CUA organizations or tasks that is complexity, uncertainty and ambiguity, right? So you don't have a roadmap. You don't know where you're going. You have some idea where you're going, but you might be wrong. You don't really know how you're going to get there along the way. And there's a high degree of complexity that you need to be able to fail and you need to be able to challenge people's ideas. You know, we know that the creative process, it's not that people just have brilliant ideas, they actually have not great ideas that then other people add slightly less, not great things too. And then, you know, you build, you like you, you build on top of each other and you make connections and then all of a sudden there's an Aha moment that you, you've landed on something that has value, right?   Daniel:            So I would say that these CUA things can only be done through conversation. It's only through like one person can't do it by themselves. Through that, you have to…   Emily:              Right, right. And so you have to have a group. And that group has to be willing to say stupid things and to say that they disagree, to challenge the status quo. And you can't do those things if you don't have psychological safety. If you're afraid that you will be judged for what you say or for challenging, then you don't get any of that behavior. And so, so when you have psychological safety, that's when you get... And performance pressure. That's when you get, okay, we're going to try something and then we're going to learn from it. And so learning becomes the kind of cornerstone to continuous improvement with that flavor of, hey, we're willing to take risks.   Emily:              We want to move fast. We're listening to each other. We understand that the solution we get you together is going to be better than the solution any of us could come to individually. And so that, that, it was a few years ago that that really became an important piece of how my department was thinking about the culture that we wanted to build. And, and in that I was thinking about, okay, what does this mean for my teams and how do I figure out when my teams are feeling that anxiety and how can I help them have the right conversations to get them back into that learning zone? And one of the observations that I had is that we spend a lot of time talking about how we talk to each other, right?   Daniel:            Amazing!   Emily:              I say to the conversation designer but, but that in the organization that often takes the format of, you know, do we really need to have this meeting? We should add this meeting. We should remove this meeting. I think we should write a new update email. We're getting too many emails. I, everybody needs to go into this spreadsheet and fill out this information. And there's just this, there's a cycle of "add a bunch of communication and process and then think there there's too much and take it away. And then I think there's too little and add more."   Emily:              And there's a justification that, that sort of a natural cycle. And the observation that I had a, and I talk a little bit about where those pieces came from, but the kind of connection that I made in my brain at some point in doing this is that the amount of communication that you need is the dependent variable. The independent variable is how much trust you have. It's not an objective, hey, in order to do this thing, I need this amount of communication period.   Emily:              The amount of communication that you need to be successful is dependent on how much trust already exists between the individuals doing the work. And so for me the interesting moment was, hey, let's reframe all of these, communicate all of these conversations that we're having about communication into conversations about trust and what does that look like? What would that mean? Yeah. And that actually you, you these, the costs of all of this communication, we call it coordination cost often. Yeah. That it's, that it's not a given. Like as your organization gets complex, you will need more communication. That is true.   Daniel:            So I'm going to, I'm going to sketch, this diagram just for the listeners. So they don't have to go any place else like okay, it's the, the y axis is amount of communication required. The X-axis, is access trust between team members. And in a way what you're implying is that there's a, a curve, a line that goes from the upper left to the lower right where basically the more trust you have, the less communication is required. Emily:              Right? That's exactly it. To accomplish any goal, the amount of trust that you have and the amount of communication that you need or inversely related. So if you have very little trust, you need a tremendous amount of communication. If you have a lot of trust, you need way less.   Daniel:            Can I push back on this concept? Just like, cause I feel like in a way like when there's a lot of trust, communication flows really freely to be like I can see on the graph anything that's above the line is inefficient use of resources and anything below it creates like friction of confusion or like, and I've seen this in projects where you're like waiting for someone else to like tell you it's okay to do what you think needs to be done. But at the same time I feel like my fiance and I talk a lot, you know, we, we have a lot of communication. There's also a lot of trust. Like I'm checking in with her and telling her my evening plans, not because I think she's worried that she doesn't, you know, where are you off with? She just wants to know and I want to tell her. So like maybe that's, maybe that's different cause it's, it's a personal context. I don't know.   Emily:              Yeah. Maybe trust and communication are actually self-reinforcing. And so when I say you have high trust and low communication that that implies that you actually have a higher degree of communication. I think, you know, maybe you could think about this as sort of additional communication or required communication, formal communication, right? And there are lots of different ways you could cut that. Although I do think that you actually just see less communication partly because one of the primary pieces of that is if I trust you, then I trust that you will understand when I need to be involved and you will proactively communicate to me and therefore I don't need to be doing the inbound communication to you. And so you know, you, I do think that there's an opportunity. I think the, and the really important piece of that is that we think we spend a lot of time talking about how we can add or subtract communication. And my thesis is that if you actually invest in building trust in teams, you can run more efficient organizations because you reduce the amount of communication that everybody to do.   Daniel:            Wow. So that upfront investment pays off. And your, I mean this is the classic go slow to go fast. Like you're like definitely has proved for you.   Emily:              Well yeah, I mean you, you, you invest in trust that allows you to pull out this communication. It certainly makes people happier and it gives you more of these other things like a willingness to take risks. You know speed to delivery risk tolerance. Yeah. Some of those other components that I think are really important.   Daniel:            So can we talk a little bit about the mechanisms, cause you, we talked about this in the pre-talk, like what are the mechanisms of creating value for the company through that, but then there's also the question of how do you actually, what is the process by which you create this kind of trust and psychological safety in your teams? So this is like the two side, like how do you do it and then how do you show that it's, how do you prove that thing that we, we were just talking about that it's, that the investment's worth it. Yeah. Cause people ask me all the time and I have a mixed answers for that.   Emily:              Yeah. I think, you know, I do think it's hard, right? It's hard. This is why the, some of these concepts like psychological safety and trust and vulnerability and Kulik they feel squishy cause it's hard to understand the value. But I do think that one of the things that's been interesting about this framework is that it is pretty easy when you start to look around and you start to diagnose, okay, where are my teams? And you start to actually selectively pull levers like, okay, I'm going to add communication here or I'm going to just remove communication here. That as a manager, having a framework like this just helps you be more active in how you manage those things, right? So if, if a manager can, if having this framework and diagnosing where their teams are effectively allows them to pull, you know, just a handful of pieces of communication out of the system without impacting the result, it's being delivered. You're delivering value right now. If you pull that communication out in a place where you don't actually have their trust, then you, you risk poor execution on the work. Right? And so the ability to make good decisions about where you can do that and where you can I think is what I'm trying to help managers do. I think in terms of actually building trust I have one go-to tool that I share. Although there's really many, many different ways to think about this. I'm a big fan of the trust equation, which is from the book the trusted advisor. Yeah. The trusted advisor is really about building trust in client relationships. But there's this concept in it called the trust equation, which is just a one way of breaking down what does trust really mean? And that trust equation says that trust is needed before components.   Emily:              There are three things that create trust, credibility, which is I trust your words. You know what you're talking about. You say, I don't know. When you don't know what you're talking about. That's one. Reliability is you do what you say you're going to do. So I'd say trust your actions. And then the third is they use the word intimacy. That can be a loaded word in business contexts. I tend to think of that as discretion is, is probably the closest thing. Like I, I trust you with a secret. Or I trust your judgment. It can mean I, it can mean you sort of know me personally. And then there's one thing that is sort of the great destroyer of trusts, which is self orientation. So if I believe that you will act in your own self interest instead of in my best interest then I don't trust you if I believe that you will take into account my best interest and think about my point of view, then we build trust.   Emily:              And the really important thing or the reason that that's my sort of critical tool is because it allows us to give feedback about trust that's much more specific. So it allows us to give feedback, allows me to give feedback about communication that's happening in the workplace. That is feedback about trust, but using those underlying concepts. So, Hey, when you well... Shit your way through the answer to that answer in that meeting and then had to go back and admit that you didn't know what you were talking about, you damaged your credibility with that stakeholder. Yeah. Right. Or when you didn't respond to that email, you damaged your reliability yeah. Or, right, then and then the positive version of that to hey, the fact that you thought to include that person in that meeting showed low self orientation and helps you build that relationship. And so more than anything that's just given people the vocabulary to have a conversation about trust without using the squishy word of trust.   Daniel:            Yeah. Breaking it down into components. Use the word levers, which I like. I talk about that a lot in my conversation design work, which is like, wow, how do we actually grab hold of this squishy thing and say like, oh, how do we manipulate it? How we actually move in? And you're like, at least you and you can focus on reliability, credibility, intimacy and intimacy is important. Like, I, I've begun to realize like the importance of actually spending time getting to know people. Like you forget this, otherwise people think it's just transactional. And that's, that's really, really critical.   Emily:              Right? And, and I think that also sorry, I just lost my train of thought for a moment.   Daniel:            I mean it's amazing by the way, like, I don't know like that you had the trusted advisor equation in your, in your brain. Like, so you get, you get a tunnel pass, it may come back to you.   Emily:              It meant that's okay. We can keep going.   Daniel:            What's that?   Emily:              I said we could keep going... Daniel:            Oh, so we, yeah, we are actually getting close to our time. So like I usually ask the, what haven't we talked about that we should talk about, which may or may not jog your memory…   Emily:              I remember what I was thinking.   Daniel: Yeah. There's the key - distraction!   Emily:              So the other thing about the trust equation is that it's actually true that different people value different parts of that equation. Well, the other thing that it allows you to do is have the conversation of saying, you know, sometimes like I've had situations where I'm kind of not connecting with someone or we just seem to be missing each other and not building the kind of relationship that I want. And then the ability to have a conversation that's like, Hey, I, what I'm looking for really is, you know, intimacy. And the other person says, well, I really want reliability and I don't really care about intimacy in this relationship that that allows you to figure out what matters for trust in that relationship more effectively.   Daniel:            It does. And so when you, you talked about how you spend a lot of time in your team talking about conversations like this is, this is the conversation about what matters to you in your conversations with the conversation about how often you want to be talking, the conversation about all of these different pieces of it. And I just did an interview with my dear friend Jocelyn Ling. We'll publish soon as well. She was the first person who ever I sat down in a meeting with who said, let's talk about how you like to work. Are you a calendar person? I mean this was almost 10 years ago, so there was no Skype, there was Skype, there was no slack, there was, there were fewer tools, but it was still an important conversation to have.   Emily:              Right, incredibly.   Daniel:            Like I have a calendar/ spreadsheet orientation and that's like if somebody is making something in a word document that could be a spreadsheet. It, it, it, you know, cause me hives. Emily:              Right, Totally. And you know, it's important to know if you're working with someone who really needs time to digest before they get into a room, then writing that preread is going to be that much more important. Right. Or if you know, obviously understanding the intimacy part, understanding what parts of the day are more difficult for people. You know, for me, I get in super early, but then I leave, I need to get home to my kids. And so, you know, if you catch me while I'm walking out the door, I'm not going to be, no,... I'm less likely to take the time to stop and have that conversation right. Daniel:            And don't have an extra five minutes!   Emily:              I really don't. Yes. So I think that that's, those things are super important and, and actually just giving people the ability to have those conversations really openly, really directly or giving them tools to do that.   Daniel:            That's awesome. So is there anything we haven't talked about that we should talk about around trust, psychological safety, organizational conversations?   Emily:              Yeah, there's, there's no one big thing. I think, you know, my, the thing that I hope is just that people feel like this is a tool that they can use and, and to really think about that the next time they hear somebody having a conversation about communication, to think about, hey, are we really having a conversation about, about trust? Right? So somebody is asking you for communication, is it really because they don't, they don't trust some piece of this, they don't trust you're going to deliver something or we've missed an opportunity to, to keep them informed and vice versa. If people are complaining about having too much communication. Is that really because there's more trust than you're building credit for and how do we, how do we change the conversation more? Daniel:            Yeah. Well that's awesome. We, I guess, I mean I'm, I'm going to try and squeeze in one more question cause like I said, I'm looking at that framework and I'm thinking to myself is that a framework for Emily to think more clearly and to talk with another manager about stuff or is it a conversation that a team can have? Like it's not like a two by two matrix. I'm not looking at it as like a importance difficulty matrix where somebody is doing an exercise with it. It is, it is both. So there's definitely, yeah, only a piece   Emily:              Of it that is as a manager, I want to have a sense of where my team is or where different project teams that I work with are and be able to actively manage. But there's definitely a team component here and I think it's a really interesting exercise to do. It requires a really good facilitator, which is get your team in a room, draw the framework on the board, two axes and a line, right? Make sure people understand it and then say, everybody grab a marker. Where do you think we are? Or, or if you don't think your team has enough trust to do that, everybody grab a sticky note and draw the framework on your sticky note and fold it up and hand it to me, right? We'll do this sort of anonymously and then you plot on the graph like where does the team think we are?   Emily:              And the interesting conversation is not about coming to objective alignment that "we are here today", but actually that some of your team members think your team has a high degree of trust and some of your team members go, right. And how do we, you know, some, some team members think that we've got too much communication and some think we have too little because they actually have different communications styles. And, and communication isn't connecting on the same for everybody. And then how do we use that as a lead in to this conversation of, hey, how do we work more effectively as a team?   Daniel:            I'm so glad I asked that question because I think that's a really, that, that's a, it's a classic visual facilitation move of where are we, where do you think we are? And then the, the benefit is not, oh, we need to get into the same place. It's like, Oh wow, you think we're here and I think we're there. Let me hear more about what you think, why you think that. And you talked to the other person about why they think they think that's what they think. That's awesome. Okay, then we're definitely out of time now, Emily, I really appreciate you making the time for this. This is really delightful conversation. I think this is super duper important stuff for everyone to get a grasp on.   Emily:              Thanks for having me!   Daniel:            Awesome. And we'll call it "and scene!"

Speaker: Jesse James GarrettWhether you design websites or shopping malls, hospitals or mobile phones, you're designing for people, and people want to be engaged by the products and services in their lives. But human engagement comes in many different forms, and traditional design practices don't say much about creating engagement. As design evolves toward delivering integrated experiences across media, designers need ways to understand modes of engagement and mechanisms for creating it. In this presentation, Jesse James Garrett looks at ways the designers of all kinds of products and services can maximize the human engagement of their work.

Episode 39 - How to Approach Front-end Development                                      Subscribe on iTunes Subscribe to RSS Download MP3 Melanie Archer joined us on this episode to enlighten us about how to approach front-end development. She breaks it down into easier steps and principles that anybody can follow to get a good front-end built in little time. She packs years worth of experience into her recommendations. This is a must listen! Note: There is some background white noise from Melanie’s mic, which we tried to minizmize. Show notes You’re an experienced backend developer suddenly given front-end tasks–where to start? Understand basic user interface principles;  "common concepts" of how user perceive the interface subconsciously. Consistency over “pretty.” Keep to standards users are accustomed to–familiar labels and placement of elements. Find help at the Yahoo! design pattern library: https://developer.yahoo.com/ypatterns/ or PatternTap: http://patterntap.com Learn the basics of information architecture. Read primers like The Elements of User Experience by Jesse James Garrett (http://jjg.net/elements/) How to start building an interface from scratch How to start building an interface from Photoshop or designer’s comp The role of HTML/CSS frameworks like the HTM5 Boilerplate or Twitter Bootstrap How to organize CSS How to improve. One hint–look at prospective interview questions for front-end developers:  https://github.com/darcyclarke/Front-end-Developer-Interview-Questions#readme Talentopoly links - Noteworthy links posted on Talentopoly in the last two weeks Sticky Menus Are Quicker To Navigate Introducing: CSSValues.com Pagoda Box Is Easier Than Amazon Web Services, But More Customizable Than Heroku Bootsnipp - Gallery of free HTML snippets for Twitter Bootstrap

Jesse James Garrett and Secil Watson talk about managing customer experiences through Wells Fargo's web sites and its phone and electronic servicing channels.

Even the best design teams, methods, architecture and tools are no match for a project beset with political infighting, divided priorities or unfocused goals. To truly make an impact, product teams need to have business buy-in and a shared understanding of the project’s direction. Often, it’s up to designers to smooth the way and facilitate this consensus. By greasing the tracks in the early stages of a project, designers can gain the much-needed support of business stakeholders, avoid wasted effort, increase their influence (within their teams and the company at large), and make a more meaningful difference with their work. The key is to bridge competing viewpoints, develop a common vision and break through project roadblocks. And it all starts with the right combination of tools and techniques. In this session, you will: * Discover how to bridge competing viewpoints, develop a common vision and eliminate roadblocks on your next project. * Explore the ways in which your existing design skill-sets can be expanded to improve communication within your team and throughout you company. * Learn facilitation techniques to help engage business stakeholders and manage the conflicting priorities and lack of direction that so often derail a project. About Jess McMullin Since 1997, Jess has focused his career on understanding and developing positive user experiences for his clients and their customers. Drawing on sources ranging from social sciences and behavioral research to gaming, market analysis and future trends, Jess generates client insights that drive innovation and create better customer experiences. Jess often speaks at conferences focusing on user experience, design thinking and innovation, topics he also writes about on a regular basis. His ideas have been featured in several user-experience books, including Lou Rosenfeld and Peter Morville’s Information Architecture for the World Wide Web, 2nd Ed. and Jesse James Garrett’s The Elements of User Experience. In 2003, Jess founded nForm User Experience, a boutique consultancy that counts Comcast, Ancestry.com and the Canadian Patient Safety Institute as clients. Jess also organizes CanUX, the annual Canadian User Experience Workshop in Banff, Alberta, and he is the cofounder of the international Information Architecture Institute. For Jess’s latest thoughts on business, design and innovation, visit his blog, bplusd (business + design).

Flow diagrams are a key component of an interaction design specification. Jesse James Garrett’s Visual Vocabulary uses a set of simple shapes to diagram user flow and illustrate basic relationships between webpages.

I asked Jesse James Garrett about his "Nine Pillars of Successful Web Teams" model. See Jesse's article (on the Adaptive Path website) for the graphical representation of his model, and his brief article on the subject.I highly recommend Jesse's book "The Elements of User Experience", which is a model of clarity.Jesse's website is well worth a visit for his thoughts on information architecture, user experience design, and his visual vocabulary for information architecture and interaction design.(References to books on this webiste are links to Amazon.com - we earn a small commission on any purchases you make on following such links).