Who wants to be a unicorn? 🔗 **Source:** [Who wants to be a unicorn?](https://www.youtube.com/watch?v=1Q4tdrkQOqM) > [!note]+ Document Notes > tags: [design-development-collaboration, unicorn-designer-developer, workplace-relationships, team-communication, t-shaped-skills] > author: Laura Kalbag > source: PenpotFest > reference: https://www.youtube.com/watch?v=1Q4tdrkQOqM > date created: 2025-01-03 08:15 > > # 🏷️ Title: Who Wants to Be a Unicorn? Designer-Developer Collaboration Insights > <!-- deep-read:sections start --> ## 🧰 Action Inbox - [H1] Share work early and often — build feedback loops into team processes #collaboration - [H2] Learn technical constraints of your platform — bridge knowledge gaps between design/dev #skill-development - [H3] Document design decisions with context — create shared language and understanding #documentation ## 🧭 Table of Contents - [📝 Summary](#-summary) - [📖 Main Content](#-main-content) - [🗒️ Notes](#️-notes) - [📚 References](#-references) - [🗣️ Paraphrase](#️-paraphrase) - [📰 Newsletter](#-newsletter) - [✅ Action Items](#-action-items) - [🧪 Hypotheses](#-hypotheses) - [📊 Methodology](#-methodology) - [❓ Questions](#-questions) - [🔮 Future Research](#-future-research) - [💡 Implications](#-implications) - [🧠 Learning Styles Assessment](#-learning-styles-assessment) - [📊 Accessibility Assessment](#-accessibility-assessment) - [🌍 DEIB Assessment](#-deib-assessment) - [✅ Logical Validity](#-logical-validity) - [🛡️ DARVO Analysis](#-darvo-analysis) - [🎯 Conclusion](#-conclusion) ### 🔗 References - [PenpotFest Talk](https://www.youtube.com/watch?v=1Q4tdrkQOqM) - [Laura Kalbag](https://laurakalbag.com) ## 📝 Summary - Laura Kalbag presents survey data and insights about designer-developer collaboration through a game show format - Working relationships are the most valued workplace aspect (71% vs 44% for compensation) - Daily collaboration happens for 46% of teams, but 16% of developers never work with designers - Key pain points: designers not understanding technical constraints, developers not grasping design principles - Most teams have 5 developers to 1 designer, with 25% having no designers - Solution involves T-shaped skills, early sharing, frequent communication, and learning each other's constraints ## 📖 Main Content Laura Kalbag, a self-described "unicorn" who does both design and development, shares research-backed insights about designer-developer collaboration. Through a "Who Wants to Be a Unicorn?" game show format, she reveals surprising statistics about workplace priorities and collaboration patterns. The presentation challenges the myth of unicorn designer-developers while advocating for better collaboration through T-shaped skills - deep expertise in one area with broad understanding across disciplines. Key findings show that working relationships matter more than compensation, daily collaboration is common but not universal, and mutual understanding of constraints is crucial. The talk emphasizes that while we can't all be unicorns, we can work magic through early sharing, frequent communication, and learning about each other's work. Kalbag concludes by connecting design-development collaboration to broader social responsibility and making positive impact. ## 🗒️ Notes #### ⏱️ [00:00](https://www.youtube.com/watch?v=1Q4tdrkQOqM?t=0) — [H1] Introduction to Designer-Developer "Unicorns" - Key idea: "Unicorn" refers to people who do both design and development - Evidence: "This is a term I started hearing maybe around 15 years ago" #### ⏱️ [02:30](https://www.youtube.com/watch?v=1Q4tdrkQOqM?t=150) — [H2] Most Valued Workplace Aspect Survey Results - Key idea: Working relationships trump compensation as workplace priority - Evidence: "Relationships were 71%, culture 46%, and working conditions 60%, compensation 44%" #### ⏱️ [04:15](https://www.youtube.com/watch?v=1Q4tdrkQOqM?t=255) — [H3] Share Work Early and Leave Ego Behind - Key idea: Early feedback prevents going too far in wrong direction - Evidence: "Share your work early... get feedback before you go too far in the wrong direction" #### ⏱️ [05:45](https://www.youtube.com/watch?v=1Q4tdrkQOqM?t=345) — [H2] Daily Collaboration is Most Common - Key idea: Nearly half of designer-dev teams collaborate daily or several times weekly - Evidence: "46% of designers and devs collaborate either daily or several times a week" #### ⏱️ [07:20](https://www.youtube.com/watch?v=1Q4tdrkQOqM?t=440) — [H3] Make It Easy to Ask Questions - Key idea: Ignorance is continuing to struggle without asking, not lacking initial knowledge - Evidence: "What is ignorant is to continue to struggle in not knowing without asking any questions" #### ⏱️ [08:30](https://www.youtube.com/watch?v=1Q4tdrkQOqM?t=510) — [H2] One-to-One Communication Preferred - Key idea: Personal calls and in-person beats async tools for designer-dev communication - Evidence: "The correct answer is D. It was one-to-one calls and in person" #### ⏱️ [10:00](https://www.youtube.com/watch?v=1Q4tdrkQOqM?t=600) — [H2] Developers' Top Complaint About Designers - Key idea: Designers don't understand technical platform constraints - Evidence: "They don't understand the platform's technical constraints... B, C, and D are all really kind of A" #### ⏱️ [11:45](https://www.youtube.com/watch?v=1Q4tdrkQOqM?t=705) — [H3] Learning Development Concepts Helps Designers - Key idea: Designers benefit from learning about native elements, components, and performance - Evidence: "Learning about topics like native elements, components and state and performance" #### ⏱️ [13:15](https://www.youtube.com/watch?v=1Q4tdrkQOqM?t=795) — [H2] Designers' Top Complaint About Developers - Key idea: Developers don't understand design principles - Evidence: "Not enough developers understand design principles... funny how much of a mirror there is" #### ⏱️ [14:30](https://www.youtube.com/watch?v=1Q4tdrkQOqM?t=870) — [H3] Documentation Provides Context Beyond Images - Key idea: Design documentation should explain the why, not just show the what - Evidence: "My work was always so much more successful when I provided more than just images" #### ⏱️ [16:00](https://www.youtube.com/watch?v=1Q4tdrkQOqM?t=960) — [H2] Five-to-One Developer-Designer Ratio - Key idea: Most teams have 2-5 developers per designer, 25% have no designers - Evidence: "The most common teams contain around two to five developers to one designer" #### ⏱️ [17:30](https://www.youtube.com/watch?v=1Q4tdrkQOqM?t=1050) — [H3] Time Appreciation Gap Between Disciplines - Key idea: Neither side appreciates how much time the other's work requires - Evidence: "Design work does take a lot of time... development work is not just a case of how the thing looks" #### ⏱️ [19:00](https://www.youtube.com/watch?v=1Q4tdrkQOqM?t=1140) — [H2] Universal Wishes: All of the Above - Key idea: Both groups want design systems, accessibility knowledge, and better process involvement - Evidence: "It's a trick question. All of the above was actually correct" #### ⏱️ [20:15](https://www.youtube.com/watch?v=1Q4tdrkQOqM?t=1215) — [H1] T-Shaped Skills Over Unicorn Myth - Key idea: Develop deep expertise in one area plus broad understanding across disciplines - Evidence: "The horizontal crossbar represents our more general understanding and the vertical stroke represents our deepest skills" #### ⏱️ [22:00](https://www.youtube.com/watch?v=1Q4tdrkQOqM?t=1320) — [H1] Focus on User Benefit Over Technical Arguments - Key idea: Team collaboration should prioritize user outcomes over framework debates - Evidence: "How do these arguments solve the goals of our work? Do they benefit our users or are they a distraction?" ## 📚 References - [Laura Kalbag's Website](https://laurakalbag.com) - [PenpotFest Conference](https://penpot.app/penpotfest/) - [Penpot Design Tool](https://penpot.app/) ## 🗣️ Paraphrase - Workplace relationships matter more to designers and developers than compensation, with 71% valuing collaboration over 44% prioritizing money - The biggest mutual complaints are mirror images: designers don't understand technical constraints while developers don't grasp design principles - T-shaped professionals with deep expertise in one area and broad knowledge across disciplines are more valuable than mythical "unicorns" who supposedly excel at everything ## 📰 Newsletter **Designer-Developer Collaboration: Beyond the Unicorn Myth** Laura Kalbag's PenpotFest talk reveals that successful design-development teams prioritize relationships over individual heroics. Her survey data shows 71% of professionals value working relationships most, while daily collaboration happens for nearly half of all teams. The key insight? Stop chasing unicorns and start building T-shaped skills - deep expertise in your area plus broad understanding of your collaborators' constraints. Early sharing, frequent communication, and mutual learning create the real magic. **Practical Takeaways:** - Share rough work early to get feedback before going wrong direction - Document design decisions with context, not just visual mockups - Learn enough about other disciplines to ask smart questions - Focus team energy on user outcomes over technical debates Resources: [Learn WordPress](https://learn.wordpress.org/), [Developer Docs](https://developer.wordpress.org/), [WP-CLI](https://wp-cli.org/) ## ✅ Action Items #### DevRel - Developer advocacy: Create content bridging design-dev knowledge gaps, showcase T-shaped skill development - Education: Develop workshops on design principles for developers, technical constraints for designers - Developer experience: Improve documentation to include design context and implementation rationale - Developer marketing: Feature collaborative success stories over individual "unicorn" narratives - Community management: Facilitate cross-disciplinary discussions, moderate design-dev flame wars constructively #### WordPress - Core: Include designers in technical architecture decisions, involve developers in early design reviews - Design: Create technical constraint documentation for designers, design principle guides for developers - Documentation: Add design rationale to technical docs, include implementation notes in design specs - Community: Foster designer-developer mentorship programs, create collaboration best practice guides - Training: Develop T-shaped skill curricula covering design+development basics for both audiences ## 🧪 Hypotheses - Teams with daily designer-developer collaboration ship higher-quality user experiences than weekly collaborators - T-shaped professionals contribute more to team velocity than specialists or claimed "unicorns" - Early work sharing reduces iteration cycles and improves final output quality - Documentation including design rationale reduces developer implementation questions by 40% ### 📊 Methodology - Survey teams on collaboration frequency vs user satisfaction metrics and iteration cycles - Compare output quality and team velocity across different skill distribution models - A/B test early sharing processes vs traditional handoff workflows - Measure question volume before/after implementing contextual design documentation ### ❓ Questions - How do we measure the ROI of investing in cross-disciplinary skill development? - What specific technical concepts should designers learn first for maximum collaboration impact? - How can we structure design documentation to be maximally useful for developers? ### 🔮 Future Research - Longitudinal study on career progression of T-shaped vs specialized professionals - Analysis of collaboration patterns in remote vs co-located design-dev teams - Investigation of design system adoption impact on designer-developer relationships ### 💡 Implications - Practice: Prioritize relationship building and cross-disciplinary learning over individual expertise growth - Policy: Structure teams for daily collaboration rather than sequential handoffs - Security: Include security constraints in designer education, UX principles in security team training - Education: Develop T-shaped curricula that emphasize collaborative skills alongside technical depth - Funding: Invest in collaboration tools and processes rather than seeking "unicorn" hires ### 🧠 Learning Styles Assessment Reading level estimate: Flesch-Kincaid Grade Level 8 #### 👀 Visual learners - Present: Game show format with clear statistics, T-shaped skills diagram - Improve: Process flow diagrams, collaboration pattern visualizations, before/after examples #### 🔊 Aural learners - Present: Conference talk with clear narration and audience interaction - Improve: Audio summary of key statistics, downloadable podcast version #### 🗣️ Verbal learners - Present: Story-driven presentation with relatable anecdotes, clear definitions - Improve: Glossary of collaboration terms, metaphor-rich explanations #### 🧩 Kinesthetic learners - Present: Interactive audience participation, actionable tips - Improve: Collaboration assessment checklist, hands-on workshop exercises #### 🧠 Logical learners - Present: Survey data, statistical evidence, clear cause-effect relationships - Improve: Decision trees for collaboration approaches, ROI calculations #### 🧑‍🤝‍🧑 Social learners - Present: Focus on team dynamics and relationship building - Improve: Group collaboration exercises, peer review frameworks #### 🧘‍♀️ Solitary learners - Present: Self-assessment opportunities, individual skill development focus - Improve: Personal T-shaped skills worksheet, solo learning paths #### 🌿 Naturalistic learners - Present: Ecosystem thinking about team dynamics - Improve: Organizational health metaphors, sustainable collaboration practices ### 📊 Accessibility Assessment #### Screen reader semantics - Present: Clear heading structure, descriptive slide content - Improve: Alt text for visual statistics, ARIA labels for interactive elements #### Keyboard navigation - Present: Standard presentation navigation - Improve: Skip links for lengthy statistics sections, keyboard shortcuts #### Contrast and readability - Present: High contrast slides with readable fonts - Improve: Color-blind friendly chart colors, consistent text sizing #### Text resizing and reflow - Present: Scalable presentation format - Improve: Responsive slide layouts, mobile-friendly viewing #### Media and captions - Present: Audio/visual presentation with transcript - Improve: Real-time captions, downloadable transcript with timestamps #### Forms and interactions - Present: Simple audience participation - Improve: Alternative participation methods for different abilities #### Standards reference - Meets WCAG 2.2 AA for contrast and structure, could improve caption timing ### 🌍 DEIB Assessment #### Cultural breadth - Present: Universal workplace challenges, cross-industry relevance - Improve: Global remote work examples, cultural communication style differences #### Inclusive language - Present: Gender-neutral terms, accessible technical language - Improve: Plain language alternatives for jargon, cultural idiom awareness #### Neurodiversity support - Present: Clear structure with numbered sections, consistent format - Improve: Content warnings for statistics anxiety, processing time allowances #### Representation - Present: Single speaker perspective, tech industry focus - Improve: Diverse collaboration examples, non-tech analogies #### Psychological safety - Present: Respectful framing of both design and development challenges - Improve: Explicit bias acknowledgment, inclusive team examples ### ✅ Logical Validity #### Strong reasoning - Deductive strength: Survey data supports specific collaboration conclusions - Inductive strength: Anecdotal evidence patterns match statistical findings - Causal reasoning: Clear links between collaboration practices and outcomes - Analogical strength: T-shaped skills metaphor effectively explains concept #### Fallacies - Appeal to authority: Relies on survey data without citing specific methodology - False dichotomy: Presents unicorn vs specialist as only options, ignoring gradations - Hasty generalization: Extrapolates from tech industry to all collaborative work #### Tone of voice - Overall tone: Conversational and encouraging with data-backed authority, uses humor appropriately ### 🛡️ DARVO Analysis - Deny: No denial patterns observed - acknowledges challenges on both sides - Attack: No attacks on accusers - treats both designers and developers respectfully - Reverse victim/offender: No victim/offender reversals - presents mutual responsibility - Emotional cues and rhetoric: Positive, solution-focused language encouraging collaboration ## 🎯 Conclusion The "unicorn" designer-developer is a harmful myth that creates unrealistic expectations. Instead, successful teams cultivate T-shaped professionals with deep expertise in one area and broad understanding across disciplines. The key to effective collaboration is sharing work early, communicating frequently, and learning about each other's constraints. With working relationships valued more than compensation, teams that prioritize collaborative processes over individual heroics will create better outcomes for users and more satisfying work environments for practitioners. ## 🧱 Refactor Appendix ### 📚 Literature Split Pad Purpose: Stage CEE units that become Literature notes. Split level: H3 ### [H1] Working relationships outweigh compensation in workplace satisfaction > [!quote] [Who Wants to Be a Unicorn?](https://www.youtube.com/watch?v=1Q4tdrkQOqM) by [[Laura Kalbag]] via [[PenpotFest]]. Published 2025-10-30. Accessed 2025-01-03. > "Relationships were 71%, culture 46%, and working conditions 60%, compensation 44%." Survey data challenging tech industry money-first assumptions about motivation. [view highlight](https://www.youtube.com/watch?v=1Q4tdrkQOqM#relationships) #collaboration #workplace ID:rw_001 ### [H2] T-shaped skills model beats unicorn expectations > [!quote] [Who Wants to Be a Unicorn?](https://www.youtube.com/watch?v=1Q4tdrkQOqM) > "The horizontal crossbar represents our more general understanding and the vertical stroke represents our deepest skills." Framework for professional development that acknowledges expertise limits while enabling collaboration. [view highlight](https://www.youtube.com/watch?v=1Q4tdrkQOqM#t-shaped) #skills #collaboration ID:rw_002 --- ### 🔖 Atomic Split Pad (Zettel Candidates) Purpose: Promote reusable claims into Atomic notes. Split level: H4 #### [Z1] Early work sharing prevents costly direction changes - Applies to any creative collaborative work, not just design-development - Pointer to 04:15 timestamp and multiple anecdotal confirmations - Links: [[Feedback-Loops]] [[Creative-Collaboration]] #### [Z2] Technical constraints drive most designer-developer conflicts - Consistent across multiple survey questions and complaint categories - Pointer to 10:00 timestamp and supporting statistics - Links: [[Platform-Constraints]] [[Cross-Disciplinary-Communication]] --- ### ✏️ Fleeting Queue Purpose: Capture quick actions for Fleeting notes. - [F1] Research specific design system ROI metrics — collaboration impact measurement #fleeting #research - [F2] Create technical constraints guide for WordPress designers — bridge knowledge gap #fleeting #documentation - [F3] Survey local developer community about designer collaboration frequency — validate findings #fleeting #community <!-- deep-read:sections end --> ## 📺 Video  --- # 📄 Full Transcript *Auto-generated from YouTube captions · timestamps roughly every 30 seconds · [watch on YouTube](https://www.youtube.com/watch?v=1Q4tdrkQOqM)* **[00:04]** [Music] So, hi. In case you don't recognize me from the various PenP videos or the Penop community or the UI design with Penpop course, I'm Laura and there's my slide. Fabulous. So, I've already said I'm Laura Calbag, and you may already know me from the Penot hands-on demos or the UI design with Pempot course. And I am a socalled **[00:37]** unicorn. This is a term I started hearing maybe around 15 years ago to refer to those of us who do both design and development. And as someone who has done jobs as both a UI and a UX designer and as a front-end developer and as both at the same time, I feel for all of you. And while I have a load of kind of baffling and wonderful experiences I could share with you, I wanted to make **[01:07]** sure that I wasn't just sharing freakish tales that only happened to a weirdo like me. So, I did some non-specific metaanalysis. I'm using big words to make it sound like real science of tech industry surveys and collected a whole range of anecdotal data. Basically, I've backed up my assumptions in some way. But personally, I find statistics and data can be quite dry and quite boring. So, let's play Who Wants to Be a **[01:38]** Unicorn? There might be audio. We'll see. Today, we're going to test your knowledge of the designer developer experience, and you can be in with a chance of winning unicorn sparkles. I'm sorry. I can't pretend that I have any money to give away to you. So for 1,000 sparkles, which is the most **[02:12]** valued aspect of a workplace to designers and developers? Is it A compensation, B, working relationships, C, company culture, or D, working conditions. Now, I'm going to get you to raise your hands because this game show is 100% Ask the audience. So, who says A compensation? Money, money, money. **[02:43]** Okay. B working relationships. C company culture. Okay. And D working conditions. Okay. We're fairly mixed results here. Actually, you're all pretty confident that you're not in it for the money. And the answer is B. Working relationships are the most valued. And you know, it kind of surprised me as well. I did think more people in the tech industry were more **[03:13]** all about the money. And compensation actually came down the list at 44%. Relationships were 71%, culture 46%, and working conditions 60%. I think that's a lot of people that take their working conditions for granted, but it does go to show that we do really care about collaboration. And so what does sparkles translate to here? I wanted to actually give you something in return. And well, tips. And sure, it's tips from me, but also a **[03:45]** whole load of people in my social media feed who kindly responded when I asked for feedback and tips. So, one of the key tips that I heard was share your work early. And I think this is something that Gloria spoke about earlier, too. It doesn't matter if it doesn't look good or isn't working exactly as you expect yet. The key is to get feedback before you go too far in the wrong direction. And leaving your ego at the door. Don't **[04:16]** worry about sharing a rough draft and thinking that people might think you're not a very good designer or a developer. When everyone on the team is on board with early drafts and sharing early, your final drafts will be so much better as a result. So our next question for 5,000 sparkles, how often do designers and developers collaborate on a single project? Is it A **[04:47]** daily, B once a week, C a few times a month, or is it D never? So, who thinks A? Yeah. B. Maybe this is reflective of your own working practices. C. Few times a month. Anyone for never. No one's bold enough to stand out here, are they? Well, the correct answer is **[05:18]** daily. Yeah, you're right. 46% of designers and devs collaborate either daily or several times a week. 16% collaborate around once a week. 11% a few times a month. And that's pretty good if we're referring like going back to this theme of communication. When you share your work or your ideas early, you need to make it easy for other people to ask questions. Like, there's nothing wrong with not knowing something about a **[05:49]** design or about what's been made already or not understanding it yet. It's not ignorant to not know. What is ignorant is to continue to struggle in not knowing without asking any questions. And even if you really do think that the other person asking the questions should already know that six fonts is far too many on one page or that every element should align to the grid nicely. Be kind. They answer enthusiastically and let your collaborator know that you are **[06:21]** very happy to learn from each other. Returning back to this question because there was an answer that said never on here. What I found most shocking about this particular survey result was that 16% of people they surveyed developers never collaborated with a designer because they didn't have any designers on their teams and the developer they just weren't involved in the project at all. So let's go to our next question **[06:52]** for 10,000 sparkles. Which communication channels do developers and designers use the most? Is it A comments in software? Is it B async chats and email? Is it C team meetings? Or is it D onetoone calls and inperson? So, who thinks A comments in your software? Oh, I surprised myself there. I spoiled **[07:25]** the answer. Well, the correct answer is D. You didn't get a chance in that. It was onetoone calls and in person. I'm too eager with the trigger finger on that one. When we're collaborating frequently, we need to make sure that our working relationships run really smoothly. Like, what if somebody else's work has missed the mark? What if they've done something wrong? How do we help them get back on track? because you you do want to help them get back on track, right? And we need to receive other people's work as **[07:57]** we would like our work to be received. Like constructive criticism is key and learning how to objectively approach an issue in somebody else's work and kindly correct the work and not the person. So, our next question for 50,000 sparkles. What do developers find the most annoying about designers? Oh, it's a good one. A. **[08:28]** They don't understand the platform's technical constraints. We've already had a bit of discussion about this today. B. They only design for one or two screen sizes. C. They don't value performance. All those fonts, massive images. Or D, they don't design for edge cases. Oh, I'm seeing some phones being held up over there. That's telling. **[08:58]** So, who thinks the answer is A? Okay. And B C. I I'm I'm learning a lot about you as individuals right now. And D. Okay. Would you like a 50/50? I don't actually have a slide for that. The answer is A. And that's really actually because B, C, and D are all really kind of A, **[09:28]** aren't they? Um, they're all really issues with misunderstanding the constraints of the platform that you're working within. And if we don't know how the platform works technically, like if we aren't close to the metal as Gloria would say, how are we to know what's required? One of the most common complaints I had anecdotally was that designers don't learn enough about development and the constraints of their platform. Whether that's the web, whether that's web apps, **[09:59]** whether that's native apps. Many designers though do go as far as learning CSS or something like that in order to be able to communicate with developers in a language that they understand. But it's not always a solution because with modern web frameworks often even learning CSS isn't good enough because developers are abstracted away from CSS itself. But designers can still pick up a great deal of information from developers as part of the design and the development **[10:30]** process and can help make designs more useful. It's learning about topics like native elements, what's included on a platform, components and state and performance, of course, responsive design, that's a biggie, and of course design tokens, obviously. So, right, we've done the big hit on designers. Now it's the developer's turn for 100,000 sparkles. What do designers find the most annoying about developers? **[11:03]** Is it that they're always saying no? That they don't understand design principles? That they make up designs without asking first? Oh, wow. I really hit a nerve. or D. Is it It doesn't look like my design. Who thinks it's A? And what about B? **[11:35]** See? Yeah, I saw there's a bunch of you over there that might think that. And D. And the answer is the correct answer is B. It's actually that not enough developers understand design principles. It's funny how much of a mirror there is of the same thing for designers and developers. One of the most valuable things I learned during my freelance days was that for both clients and for **[12:05]** developers, my work was always so much more successful when I provided more than just images of a design documentation. like whether it's annotations, whether it's written explanations or video walkthroughs, it all helps provide context as to the why behind the design. And documentation can also help developers learn design terminology. This is part of the shared language that we were discussing in the Q&A earlier as well. It can help us **[12:38]** better discuss those implementation details and have that understanding between each other. And importantly, documentation is there when you're not. So when you're working async with a developer, maybe when the client needs to think it over, or it's there for you when you come back to your design 6 months later and you're like, uh, what did I do here? So our next question, four 500,000 sparkles, we're getting up there. Which is the most common **[13:10]** developer to designer ratio on the team? Now, I found this interesting earlier in Pablo's talk where he was covering what the ratio is for penot users. Is it a one designer, one developer? Love it. Is it B? Two designers to one developer. That's some people's dreams, isn't it? Is it C, five developers to one designer? Or is it D? All developers, no **[13:45]** designers. Would you like to phone a friend? There's no time for that. Okay. Who thinks it's A? I can tell from the chuckles. Nobody. And who thinks it's B? Yeah, that's unlikely, isn't it? Okay. C. 5 to one. Yeah. And D. Yeah, it it it happens. The answer is five to one developers to designers. The most common teams apparently contain **[14:15]** around two to five developers to one designer, one poor designer. And 25% of design teams uh development teams have no designers, which it's unbelievable. But it's devs using UI frameworks, pre-existing design systems, and things like that to complete their projects to essentially do the design work themselves. And maybe that's not really surprising given the earlier question about collaboration. Remember, 16% of **[14:47]** developers never collaborated with a designer. I don't know what kind of work they were producing. And one of the most frequent gripes I hear from both designers and developers is that they're not given the time it takes to actually complete their work and that they don't the other side doesn't appreciate how much time they need because design work does take a lot of time. It's not just a case of drawing boxes on a canvas. You've got to create, **[15:17]** you've got to reconfigure, you've got to ask questions, you got to try all these different solutions. The process itself is a very long journey. And development work is not just a case of how the thing looks, but it's also all of the extensive work that makes it actually work. So like a signup form isn't a case of just coding up a few input boxes and a button. It's you got to think about managing accounts, sending emails, catching, handling errors, and that's before we even get to further validation **[15:47]** and security. So for the big final question for 1 million sparkles, what do both developers and designers wish for the most? Is it A design systems? Is it B accessibility knowledge? Is it C developers being involved earlier in the design process? or is it D? Designers **[16:18]** involved throughout the entirety of the design process, not just early on. Okay, who thinks it's A? Okay. And B, nobody. C. Okay. And D, I would tell you that people do want accessibility knowledge and there's going to be a great workshop shortly. So, you get up there. The answer is [Music] **[16:49]** it's a trick question. All of the above was actually correct. And you can have a million sparkles, whatever that means. It's a bit of an anti-limax. So, while we can't all be unicorns, we can work that little bit of magic into our collaborative processes. And even if my statistics or my questions aren't really perfect, the same issues keep coming up over and over again. I think we'll see that throughout the course of the discussions that we're having at the whole of PenultFest when we're talking **[17:21]** about collaboration. The same things keep coming up. And often these things boiled down to the same two points. It's share early talk often. I guess that's kind of two points in one. And learn more about each other's work. And I'm very sorry if you did come to this talk expecting to hear about the magical horses with horns uh or how to create a billion-dollar startup. Whether it's unicorns or hybrids, it's no mistake that these things are **[17:52]** named after mythological creatures. It's because like real unicorns and business unicorns, unicorn designer developers don't really exist or can create quite harmful expectations. We all have different skill sets and different experiences and usually we're very specialized and deepest in one particular area that most interests us or that's required by our daily work as well as all the stuff that requires more **[18:22]** general knowledge and skills. And this is often referred to as being T-shaped. And so it's where the horizontal crossbar of that T represents our more general understanding and the vertical stroke represents our deepest skills. There we go. And often seniority in a role is kind of because we've developed a longer crossbar. We have more of an understanding of other people's roles and their day-to-day constraints. But **[18:55]** having T-shaped skills doesn't mean we could do an equally good job as those people who have deep skills in those areas where we're relatively shallow. It takes a long time for experts to develop expertise. And a little knowledge usually means we've learned just about enough to know who I need to ask in order to get that job done properly and what I need to do to stop them getting annoyed at me. And as individuals, we can't know **[19:25]** everything. It's impossible. But as a team, we can cover a hell of a lot. And that's why we can achieve so much from learning from each other and working together. And it's what I often consider when I'm faced with this latest online discourse about designers and developers or REM versus M or this front-end framework versus that front-end framework. How do these arguments solve the goals of our work? Do they benefit our users or are they a distraction? Are they just **[19:57]** a comfy place where we can show off everything that we know and blow off a bit of steam? And even more importantly, with the world as it is right now, what knowledge can we gain that can actually genuinely benefit the lives of our users and increase our tees with areas like accessibility and community and inclusivity and sustainability and safety through privacy and security. And I know that as other people who clearly **[20:29]** care about open source, if you're at an event like this, these are probably areas that do already interest you. And now with the planet that we live on, like with human lives being impacted by climate change and authoritarian governments and wars and famine and genocide, we should also question how our work affects the world around us because it does. Are we respecting human rights with what **[21:00]** we're building and the work we're creating? Are we contributing a part to a greater hole that is actually being used to hurt people? And at the very least, what can we do to prevent causing more harm? Or more optimistically, how can we work together to make the world better? Thank you. [Music] [Applause] **[21:32]** [Music]