06.03.25
|
Coming soon, in the works.
|
05.27.25
|
Today, I want to talk about collaboration, and at its core, governance of design.
Design tools are constantly changing. When I first began, designers 'did their thing' in XD, and the design was solely controlled by the UX team. Then, we could officially refine or read out the product and own it. Today, that just isn't the case anymore with the rise of cloud-based collaboration tools like Figma. So, what's the big point? Why ramble? The other day, a batch of small enhancements were made to an application I've been working on. The product manager decided to take it upon himself to make the changes and present that work as his own. This angered me. Now - keep in mind- in my current organization, we just went through a reorganization. The culture was essentially turned upside down from everyone work together for the common good to how do I keep myself indespensable? So, naturally, my first instinct is to think: he's stealing my job! However, there is some protein here. Tools like Figma that bring everyone to the same playing field means that designers must work harder, and be more intentional, to assert the work they do well--and deserve to take ownership of. It doesn't have to be a war. But there is a potential for us to slip through the cracks when our business partners want to shave us off projects. Is it the end of the solely designer role as we know it? Not yet, but potentially. |
05.20.25
|
When I set out on my design career path in college, I didn’t necessarily know why I wanted to be a designer or go into the user experience field. After many years of practicing, and I’m still at the beginning—a few themes rise to the top of why I wanted to—and still continue to—admire design.
At the forefront, I love design because it nurtures a connection to people. People as in people I work with, as well as users I build for. Whether it be leaders of a team, a researcher in the field, or a designer working with pixels; it all requires empathy. As a user receiving design changes, why should I cooperate if the person demanding change thinks they’re better than me? Users can smell bullshit from a mile away. To enable effective change and receive accurate feedback, we must uphold a sincere connection to the people we work with and understand their points of view, and trace back core meaning of why they might feel a certain way. Good designers, and their work follow a deep, instinctual connection to emotional intelligence. |
05.13.25
|
I work at a larger energy utility company. Jane works over at Small Pharmacy Startup across the street. We both are design professionals, but our experiences of what good design is varies greatly. After all—at a global level—all of our workplaces vary in size, and industry type, so knowing what good is gets difficult.
Today, when we look at skilling, we don’t filter out what is with our organization and what is in the global design community. Today, I’d like to coin new terminologies: Organizational Design Practices and Global Design Practices. Organizational Design Practices would signify what we do as professionals within the boundaries of the organization and industry we work in. Jane wouldn’t care about my utility company’s design practices because her company doesn’t have in-house engineers, and they aren’t a regulated monopoly, and they’re not Agile. Both interact with user persona artifacts, but in a different ways. Global Design Practices signify best practices outside of the boundaries of the organization and industry we work in. Both of our companies use Figma for prototyping. They use Dovetail for research synthesis. They’re global for our design industry. Regardless of whether we’re looking at organizational or global design practices, at our company we don’t have consistent documentation on what good looks like. Today, if I’m looking for ‘good’ global design practices, I encounter one-size-fits-all certification courses where only chunks apply to my own specific work scenarios. I complete courses to say I did, to satisfy internal development plans; completing wild timed open-book certifications. Or, sometimes I’ll receive a subscribed email, or get a push notification from LinkedIn to gawk at specific industry influencers, where again, scenarios may not apply to my specific role. Moreover, if I’m looking for ‘good’ organizational design practices, they’re even harder to find. Other practices such as product management or engineering might store their ways of working on a Confluence site. In the past, I’ve seen UX teams put this documentation on a monument design system page. Whether its Confluence, monument pages, it doesn’t matter—all of these examples of good global and organizational practices need to be kept in a democratic, transparent place where any designer, or business partner can learn from them. Additionally, these playbooks cannot be produced in a vacuum. Developing what ‘good design’ is should be held in a workshop with other related professions like engineers to be inclusive. And, global design practices such as the double diamond loop in and out of other dependent processes like Agile. For example, currently, two different siloed ‘playbooks’ are being created within my organization. The major takeaway from filtering organizational and global design practices is that it helps us understand what keeps us marketable for other companies. If most of my design work is improving the organizational practices, not only am I just molding myself for one company, but my portfolio will be less relevant for interviewing. Managers need to keep practices global when possible, and document when work becomes organizational to educate their teams. The real question is, can we create a playbook that features core process and principles that is universal enough that can be used by designers everywhere? This documentation will be kept at an extremely high level where designers can adjust and mold it to their roles. |
05.06.25
|
The past few weeks, I have had the opportunity to go out into the field multiple times and conduct UX research for a new tool we are building. Most recently, for the first time, being the solo design voice in the field. While going out into the field and interviewing our inspectors that inspect our electric assets, I got so much out of this experiences and wanted to share to my other fellow designers (or anyone else who wants to listen.)
Upon Arrival: Setting the Culture Design is incredible and beautiful. It’s fresh, its different and it’s unbelievably raw; and that is not the culture of many organizations. I really wanted to go in and set the tone and create trust before interviewing users. That means clearly establishing who I am—and why I’m here—to listen, and not to speak my assumptions. To understand the truth and problem solve for all the ugliness the truth may have. I hypothesized that the more psychologically safe the users felt, the more they would open up about their true experiences while inspecting. And I felt good that they wanted to after I set the culture. In the Field: Witnessing Real Challenges I was able to experience beautiful challenges that were truly fascinating. Challenges I would have never been able to empathize, rather than sympathize, while remote. I was able to feel the sun’s intense heat and see the sun’s glare on screens. I felt the mud suck my own work boots into the ground, while almost stumbling the uneven terrain filled with vegetation. It's all in the small things, like watching users' eyes squint to read information on worn out, non-backlit screens. But its not just the challenges you can see—it also what you learn when talking to face-to-face. During the Interview: Hearing the Small Stories Face-to-Face Because I was face to face with our users, I got to hear their stories. Stories where user’s faces became red and angry. Beautiful moments where everyone laughed in unison by the ridiculousness of something that happened. Stories of user’s past jobs where they felt stress from change. Part of who I am is figuring out how things work. This part of my brain was activated when users would tell stories of tribal knowledge, bits and pieces of sticky situations—and my brain could connect the dots to the inevitable, beautiful “a-ha!” moment. How they solve problems is truly incredible. Not just technological problems with software or hardware; but what they actually do when the elements of mother nature fight back. After the Interview: Where Design & Decisioning Comes In It’s amazing to have the opportunity to be creative and figure out how we can solve these problems that arose during the interview. Watching the process of problems turning to solutioning is when the rush comes in. Seeing an insight—and how it turns into a backlog item— truly makes this job worthwhile; knowing you’re the voice between the user and the business, making it easier for users to do their jobs. I was able to create a simple, clean readout deck with insights that clearly correlate to accurate data so the business (product managers) can take action. And that is what I want to see. Beautiful actions that put our users first; even if they're little steps in the right direction. Final Thoughts The most moving part of these experiences was that I was able to see people as people, and not just remote users. Real people with real stories and challenges. Real emotions. These inspectors—they have a passion to do their jobs right. They have an appetite for evolution, and it’s our job as designers to make the evolution as smooth as possible. I also have the privilege of working with a phenomenal change management lead for the first time. She and I quickly realized we share the same goal of empathy, putting people first and treating them with respect. Ever thankful for this project team, as well as our my design team and management, to support and allow these connections and discoveries to happen. We may not be able to solve all the problems instantly (cough, cough, agile). But I know we’re working towards the right organizational culture to get there. There were beautiful moments in these sessions. |
