There’s a day for everything — National Cheese Pizza Day, Mismatched Sock Day, and even Hug Your Cat Day (which, let’s be honest, is every day if you ask my cat). But August 8th? That one stands out. It’s International Allyship Day, and it deserves more than a post or a passing mention.

Here at RingCentral, we’re leaning in in a big way. As Chair of the WISE Allyship Committee — that’s Women in SaaS Empowerment — I’m helping lead August Allyship, a month-long initiative designed to spark conversation and drive action around what allyship really looks like in the workplace and beyond.

But I’ve been thinking about allyship differently — not just as a set of actions or values, but as something much deeper: a user experience.

Allyship as UX: What are you designing?

As someone who thinks a lot about systems, behaviors, and empathy, I keep coming back to this question: What kind of experience are we creating for the women we work with, live with, and learn from?

If allyship were a product or service, would people feel seen in it? Safe in it? Valued in it?

At its best, allyship is a thoughtfully designed experience — built with empathy, tested with humility, and improved through feedback. It’s not static. It’s not perfect. But it’s intentional.

Empathy isn’t just for users — it’s for people

Every good UX process starts with empathy. So does allyship.

Empathy isn’t “feeling bad” for someone. It’s the ability to say:
👉 “Your experience is real, even if it’s different from mine.”
👉 “I believe you. And I want to understand.”

Allyship means creating environments where women don’t have to constantly “explain” their reality, where they don’t have to fight to be heard or be perfect to be respected.

Empathy is the first step — but not the last. In UX, we don’t stop at discovery. We prototype. We iterate. We fix what’s broken.

Men as allies: Are you designing inclusion — or just saying you support it?

Men have enormous power to shape the workplace experience for women. But here’s the key: it has to be intentional. Passive support isn’t design. It’s default.

Real allyship from men looks like:

• Interrupting interruptions. (“Hold on, I’d like to hear her finish.”)
• Reinforcing equity by questioning unequal pay, opportunity, and airtime.
• Taking responsibility for inclusion as a shared goal, not a women’s issue.
• Giving credit where it’s due. Did a woman on your team float an idea that didn’t land until you repeated it? Name her, thank her, and give her the floor.

In UX terms: Don’t just use the system. Improve the system.

Women as allies to each other: Designing trust

Let’s be honest — sometimes, the user experience between women isn’t always great. We can fall into comparison, gatekeeping, or silence. But real allyship means being intentional about designing better interactions with one another.

Here’s what allyship between women can look like:

• Sharing the mic in meetings, even when you’ve earned your moment.
• Backing each other up when ideas are overlooked or misattributed.
• Mentoring without gatekeeping, and promoting women who aren’t carbon copies of ourselves.
• Lifting others as you climb. Being an ally often brings allies in return. Karma has a LinkedIn profile, too.

The best design outcomes come from collaboration. So does real progress.

At RingCentral, we’re designing Allyship August

In UX, we don’t just hope people do the right thing — we design for it. In our teams, we instill best practices and healthy habits in our designers through frameworks like Design Thinking, repeatable rituals, and human-centered feedback loops.

So why should allyship be any different?

They say consistent behaviors over time build strong habits, which is why at RingCentral, we’re launching “Allyship August: 31 Days, 31 Ways to Be an Ally” — a daily guide to help embed allyship into our everyday actions, one intentional choice at a time.

Our goal is to elevate women by making allyship visible, consistent, and rooted in empathy. We’re not just encouraging men to “support women.” We’re designing a cultural shift — where both men and women are encouraged to become stronger allies. Because allyship isn’t a one-way street — it’s a shared design challenge. One where we co-create a more inclusive experience for everyone. One where everyone’s voice matters, and everyone can contribute to better outcomes.

By approaching allyship like we approach great UX — through practice, iteration, and human-centered thinking — we’re making inclusion not just aspirational, but habitual.

A few UX-friendly reminders:

• Awareness matters. Who’s not in the room? Who’s not being heard?
• Feedback is a gift. Don’t just invite it — act on it.
• Don’t over-index on performance. Allyship doesn’t need to be flashy. It needs to be real.
• Test and iterate. You’re going to get it wrong sometimes. Learn. Adjust. Keep showing up.

So this International Allyship Day — and all month long — ask yourself:
🛠 What kind of experience am I designing for the people around me?
🎯 Am I making things more inclusive, more fair, more human?

You don’t have to be perfect. You just have to be present — and intentional.

Let’s design something better. Together.

Designing Allyship: It’s Not a Buzzword, It’s an Experience was originally published in ringcentral-ux on Medium, where people are continuing the conversation by highlighting and responding to this story.

The intersection of songwriting and the art of communicating with executives

So what do songwriting and communicating with executives have in common? Well…

At one point in my career, I was asked to create an executive proposal making a case for more team resources. When I embarked on this task, I wasn’t sure where to begin. So I did my diligence to get some advice from a couple of my mentors. The main advice one mentor gave me was:

Get to the point and keep it as brief as possible.

It sounded so simple and easy at first. But then he also said, “keep it to no more than two slides, max”, “make sure to state the problem using data”, “be sure to include your solution, and back that up with data”, “make sure to show what other competitors do (if you can)”, “don’t overwhelm your audience”, “make sure to tell a story”, and so on. All of this advice was great, but the constraints seemed impossible and sometimes conflicting. After several days and hours of working on this deck, slogging through it, I finally arrived at what I thought was a pretty good draft. Then, I had my big “a ha!” moment.

I realized the challenges I was facing, trying to explain and communicate information to an executive audience (with a very short attention span), were exactly the same challenges artists and songwriters face when trying to write a great pop song.

Being a singer-songwriter as my primary hobby outside of work, I realized that these constraints discussed with my mentor, mirrored almost perfectly with the rules and methods used in great songwriting. Rules such as, “get the listeners attention right away”, “keep the song length under three minutes”, “tell a story”, “get to the chorus quickly”, “use descriptive language”, and so forth.

After thinking about it more, I identified five main similarities in the way songs are written and how we are taught to communicate with executives — and it all makes perfect sense! Because songs are meant to be heard and understood in the same instant the audience listens to them. The average music listener has no attention span. If you don’t catch them in the first 10–15 seconds, you’ve lost them. The same is true with executives. They have no time. So if you don’t engage them right away, they tune out. So that means, the words, the back story, the timing of the delivery, the set up to the main idea all have to be clear, concise and easily digestible in one quick session. On top of that, the main idea conveyed has to evoke some sort of reaction (ideally a positive one).

So, to help you make your executive presentations more effective, try the same techniques great songwriters use, but with a few tweaks in mind:

👂 Get their attention

In some cases, if you’re really short on time, you may skip this part altogether. But in most songs, there’s some sort of short introduction or “hook” that sets the tone and mood. In your executive presentation, depending on the time you have and how well you know your executive, you may keep this shorter or longer. In any case, use the introduction as a way to either establish the problem you want to solve, establish your credibility, introduce yourself, or just set the right tone with a quote or fact to get them in the frame of mind you want them in for what you are about to present next.

📍Get to the point

Now comes the big idea! In a regular pop song, you’d normally start with a verse to set up the backdrop and story for your song, BUT with an executive presentation, you want to start with your chorus. Some popular songs also follow this same structure. In fact, you can check out NPR’s Don’t bore us, get to the chorus: The Playlist page for some great examples.

Get your main message or “ask” out there right away. Your main message is the most important take-away you want to get across, right? So it’s important to hone in on whether your message needs to convince, inform, or impress. Align your message to your desired outcome to ensure your executive hears you and understands the big idea of your presentation. Also, just like a pop song’s chorus, make it memorable — and whatever you do, don’t bore us.

🎨 Be descriptive with your story

Similar to a pop song, the more detailed elements are like the “verse” of your presentation. The verse in a pop song is the part of the lyric that sets up the backdrop, tells the story, provides the details, and evokes imagery for people to grasp onto in their minds. In your presentation to executives, use your data points and visuals to show this more specific level of descriptive information so you can support your storyline and main message (ie. your chorus).

Now, some songs have a bridge. The function and purpose of a bridge in the context of a song is to shed a new light on the story, present a different point of view, or show a new perspective that transports the listener to a different place. In your presentation, the “bridge” might be something like your competitive analysis, customer quotes, retrospective anecdotal evidence, or other data you’ve found to support other angles of your story. Here’s a fun list Billboard Magazine published of the The 100 Greatest Song Bridges of the 21st Century: Staff Picks . If you’re in the mood to listen to songs with a great bridge, this will give you some great examples.

If you’re allotted more time for a longer executive presentation, then a bridge might be a useful, cool tool. But if your presentation is already lengthy and time is short, you might just be going a bridge too far by adding more content. Use your best judgement.

⌛️Keep it brief

As I mentioned previously, the typical constraint of a pop song is the time limit of keeping your song to about three minutes in length, and definitely not longer than four minutes. If you listen to most songs on the radio and look at the song lengths, you’ll see how short they actually are, but man, they really pack a lot in there! Taylor Swift (one of my favorites artists who I respect a lot) is a particular master at this craft, but so are many other songwriters. If you are a “Swiftie” check out this playlist on Spotify, Taylor Swift Songs from Shortest to Longest to check out many of her shortest songs. If you’re into rock songs, this playlist on Apple Music, Right to the Point: Rock Songs Under Three Minutes is also fun.

Check out other artists you love and see which ones are efficient with the length of each part of the song. How long is the intro? When does the chorus come in? How long are the verses?

Just like the songs you love, pay attention to your executive presentation to see if there are areas that go on too long or contain redundant information that you could consolidate. Ideally, try to keep your presentation to no more than two to five slides and try to keep it no more than five minutes in length. As the old cliché saying goes, “less is more!” and it couldn’t be more true with the executive audience.

Remember, always put your most important message at the beginning of your presentation. With, executives sometimes the first slide is all you get through.

In a nutshell, keep your presentation as short as possible, but still make it meaningful and clear so the right message you want comes across.

💬 Leave them wanting more

Finally, the one thing great songs do is they make you want to hear them over and over again. However, if a song is really awesome, it will oftentimes spark a listener to want to hear more songs from that artist. Your executive presentation should have a similar effect. By keeping your presentation brief (as already noted) you have a higher chance of not overstaying your welcome. You also have a higher chance of executives engaging with you to start a discussion if you provide just the right level of information. Providing only the high-level information will create that top layer in your presentation that can then be peeled away if desired. It’s best to only present the absolute critical information to tell your story. Then, just have some extra slides in your “back pocket” in case you are asked for more details. Someone once gave me this great advice,

“Let them ask you questions, they will ask you if they need more information.”

Pretty simple idea, right? — “Let them ask.” But so often we are so excited to talk about our idea or proposal, we talk too much, reveal too much too soon, and blow our chances of real engagement with our audience. So leave them wanting more by simply creating some space in the conversation (and in your presentation) to allow for your executives to get excited and then hopefully want more.

After following the basic five rules above, I have been able to craft much more succinct and effective presentations. Even if I don’t always get what I ask for, at least I now feel more confident when I present, knowing I have a better chance of my message being heard. Whether you write songs, create executive decks, or simply want to be a more effective communicator and presenter, these five rules will help improve your chances for success.

Good luck!

5 things great songs and executive presentations have in common was originally published in ringcentral-ux on Medium, where people are continuing the conversation by highlighting and responding to this story.

Small businesses aren’t one-size-fits-all when it comes to tech solutions. Through our in-depth interviews with small business owners, the UX Research team uncovered four distinct personas that shed light on their motivations and ability to adopt tech solutions. Understanding these personas can help us tailor tech solutions to better serve their unique needs.

The Stereotype

When most think of a small business, they often envision local mom-and-pop shops–simple and resourceful. While small businesses are often portrayed as a homogenous group, in reality, they operate in very unique ways. This diversity extends to how they adopt and utilize technology.

To better understand these differences, the UX Research team at RingCentral and Georgia Patera from Good Problems Innovation conducted in-depth interviews with small to medium-sized business owners (SMBs) across a range of industries. We explored their personal backgrounds, business approaches, current tech stacks, and daily operations to uncover their unique challenges, goals, and tech usage patterns.

What we discovered is that SMBs’ tech needs and behaviors are highly diverse, leading us to categorize them into four unique personas based on two critical factors:

1. Motivation: Their desire to adopt new tech solutions.
2. Ability: Their tech-savviness and confidence in implementing new tech solutions.

These personas help reveal how small business owners integrate tech solutions into their business processes.

The Tech Landscape of Small Businesses

Before diving into the personas, it’s important to acknowledge the unique environment in which SMBs operate in. Unlike larger enterprises with more resources and specialized departments, SMBs often wear multiple hats, making efficiency a top priority. While technology is commonly viewed as a solution to streamline operations, SMBs vary in their adoption of tech based on experience (ability) and needs (motivation) — some use advanced tech stacks, while others prefer simpler, minimal solutions.

SMBs also value independence and control, which can lead to hesitance in delegating tasks, creating a tension between doing everything themselves and sharing responsibilities. This tension often influences their work-life balance, prompting some to seek tech solutions to manage this.

We found that SMBs’ adoption of new tech solutions depends highly on their ability (tech-savviness) and their motivation (business needs). Their ability and motivation to implement tools varies, with some requiring hands-on support and others preferring to manage it independently. These differences allowed us to identify four distinct personas among SMBs, each with its own unique way to adopt and utilize tech solutions.

The Four Small Business Personas

Our research uncovered four personas that small business owners tend to fall into. These personas, represented in the chart above, differ based on their technical ability and motivation to adopt new solutions. Based on these factors, small business owners can be grouped into four personas:

The Novice: Lower Ability, High Motivation

Motto: “Make change less intimidating”

The Novice is eager to adopt new technology but may become overwhelmed by the process. Often, these are individuals who lack the skills to adopt new tech solutions and/or are afraid of making mistakes when they come across things they don’t understand. They value simplicity and reliability, often preferring tech solutions that integrate with their existing tools. Novices often rely heavily on employees, external resources, and word-of-mouth from other SMBs when making decisions for new tech solutions. Their main challenges include intimidation of new tech and a lack of technical knowledge for implementation.

Key Needs:

• Fill Knowledge Gaps: Novices need solutions that are easy to understand and implement. Clarity regarding the benefits for their business along with solutions that offer user-friendly interfaces can help them overcome their fear of the unknown.
• Seamless Adoption: The less intimidating the adoption process, the more likely they are to embrace tech solutions. Offering hands-on assistance and reliable support can make a significant difference for them.

The Resister: Lower Ability, Low Motivation

“Make this problem go away”

The Resister tends to only adopt tech solutions when they absolutely have to, often because something is broken or has become obsolete. They are the most resistant to change, preferring to stick to what they know. Often they perceive new tech solutions as more of a hassle than a benefit. Resisters aren’t motivated by potential gains, but rather by the fear of disruption to their business. They need reassurance that tech solutions will make their problems go away without complicating their lives.

Key Needs:

• Clear Value: Resisters won’t adopt a new tool unless it’s proven to them that it will fix an existing pain point for their business. They need to see the direct, practical value of tech solutions before they are willing to engage.
• Minimal Disruption: Resisters seek a smooth transition, without adding complexity or disrupting their existing processes.

The Dabbler: Higher Ability, Low Motivation

“Make my life easier”

The Dabbler may have the technical ability to adopt advanced tech solutions, but is primarily motivated by efficiency. They seek new tools only if it simplifies their workload or adds clear value to their day-to-day tasks. Dabblers want tech solutions that fit seamlessly into their existing workflow and reduce their workload, ultimately supporting the efficiency of their processes. The thought of a potential business disruption can also be a powerful motivator for this group as they have a higher technical ability to take action. Dabblers need tech solutions that can free up their time.

Key Needs:

• Efficiency: Dabblers appreciate tools that help them streamline operations without requiring much time or thought. They need tech solutions that integrate seamlessly and provide clear efficiency, making their life easier.
• Simplicity: Even though Dabblers have a higher technical ability, the less complex the tool, the more likely they are to use it. They want tech solutions that make their lives easier, not ones that demand too much effort.

The Tinkerer: Higher Ability, High Motivation

“Make my business better”

The Tinkerer loves experimenting with new tools and finding ways to optimize their business. This group represents the tech-savvy SMBs. They are typically more motivated, comfortable and willing to tinker with technology, always on the lookout for the latest cutting-edge solutions. For them, tech solutions are perceived as tools that can help drive business growth. Tinkerers are motivated to adopt new tech solutions when they believe they have something to gain and have the technical ability to make it happen.

Key Needs:

• Control and Flexibility: Tinkerers want tech solutions that allow them to have full control and flexibility over configurations and integrations. They’re more willing to dive into the nuances of a product to see how they can tailor tech solutions to enhance their business.
• Advanced Innovation: Since Tinkerers are highly capable, they appreciate tools with more robust capabilities. They are often drawn to the newest and most advanced tech solutions that could help support their business.

Why is this Important for Tech Solution Providers?

It’s important to note that personas are not actual people, but rather a collection of attributes that a group of individuals share, both behaviorally and motivationally. While relatively few people may have all the behaviors and attitudes that are represented in each persona, these depictions are valuable tools for understanding common patterns among SMBs. By grouping these attributes, personas can help solution providers think strategically about how to connect with and appeal to a variety of SMBs.

Understanding these personas is crucial for any solution provider looking to tailor their offerings to SMBs. Different personas have different needs: Resisters require more guidance and simpler interfaces, while Tinkerers thrive with advanced, feature-rich tools. Novices benefit from educational resources and onboarding processes that reduce complexity, whereas Dabblers prefer solutions that balance simplicity with power.

Tailoring Tech Solutions to Meet SMB Needs

When developing products for small businesses, a one-size-fits-all approach may not always work. As our research indicated, SMBs vary in their technical abilities and motivations, making it crucial for solution providers to offer flexible solutions that can cater to both the Novices and the Tinkerers of the world. Highlighting the key needs of each persona can help ensure that tech solutions resonate with them on a deeper level.

By recognizing the four personas–Novice, Resister, Dabbler, and Tinkerer–we can more effectively position tech solutions to meet the unique needs of each group, helping them unlock the full potential of tech solutions for their business.

Understanding the Tech Needs of Small Business Owners was originally published in ringcentral-ux on Medium, where people are continuing the conversation by highlighting and responding to this story.

Lessons learned from a game design workshop gone awry

When my son was in Cub Scouts, I was a very active volunteer. I served as Committee Chair for two years which sometimes felt like a second job. I loved using my leadership, project management, and operational know-how to benefit our community and the greater good by supporting a non-profit youth group. While it was a huge time commitment, it was rewarding to help deliver a program where boys and girls embarked on new adventures, expanding their minds.

For those not familiar with Cub Scouts, kids often will choose elective activities that parents typically help lead. Given my innate passion for helping others (along with my tendency to over-volunteer), it came as no surprise to my friends and family when I enthusiastically raised my hand to coordinate a game design elective for a small group of 10-year-old boys. I mean, who doesn’t love a good game?

“What a fun opportunity”, I thought. “to tap into those wondrous kid-energy brains and create something original and cool — a board game.”

In fact, this idea sparked romantic visions in my head. I pictured a beautiful scene, where I would be leading young, curious minds on a glorious design journey through a fruitful UX-style game design workshop. In my mind, I was convinced I could teach these kids the process of Design Thinking, show them how to channel their great ideas, and realize a shared vision. I was convinced that the brainstorming and workshop techniques I had learned (working in the user experience discipline) would yield even better results when applied to these young, uncluttered brains. This was going to be fun. Everyone would feel proud and bonded as a result of building something brand new — TOGETHER.

As fate would have it, my grandiose ideas didn’t go exactly the way I had planned. It would be an understatement to say we ran into a few “hiccups” along the way. However, these challenges actually ended up turning into valuable learnings during this unintended “social experiment.” The entire process and experience made me realize that effective and healthy collaboration requires a whole host of skills that maybe I took for granted, regardless of whether it’s kids or adults involved.

What went well?

Before I get into the challenges of this experience, in typical retrospective fashion, it is important to first look at what worked well. So let’s start there.

✅ Scheduling

The workshop was planned to take place in one day over 90 minutes. Luckily, we were able to find a day and time that worked for everyone. The other parents were very flexible which made the process of aligning on a day and time seamless and simple. So that part was fairly easy and painless.

✅ Planning

To prepare for the workshop, I had to conduct a little bit of research. I had no idea how to create a game, whether it was a video game or board game. I only knew it sounded like something that would benefit from a Design Thinking style approach, since the game design elective would be done as a group project. So I immediately consulted Google Search and ChatGPT. It turns out, ChatGPT was SO USEFUL, it saved me literally hours of time. It outlined a format to fit our 90-minute time slot just perfectly.

✅ Clear agenda

ChatGPT also provided me with a very clear and useful agenda along with a set of instructions on how to run a game design workshop. It told me which activities to do, when to do them, and how long each activity should take, etc. It even added breaks into our agenda, so we wouldn’t get too tired or burnt out. That was awesome!

✅ Rules of engagement

At the very beginning of the meeting with the boys, I set up some very specific rules for the group to make sure that everyone would be respectful, listen to others, and work together. It helped to make sure the environment stayed positive and supportive as we worked together.

✅ Enthusiasm

I decided to have the boys create a board game as I did not want to go down the video game path, since board games felt like a more inclusive format. For example, to make a physical board game did not require coding skills, special technology, or Internet accounts (ie. Roblox Studios) in order for everyone to participate. Using physical form factors and tools to create our board game also helped to foster in-person interactions.

It turns out, the boys were all very excited to create a board game! All of them actively played both video and board games in their spare time. Playing games was a common passion they all shared. This really helped when it came to motivating them to do the activities we needed to get done. At least it helped at the beginning…

What went wrong?

While many things went right, the process also had some snags. I mentioned challenges along the way that made our project very difficult and downright painful at times to get done. Here are some of the highlights.

❌ Brainstorming blockers

One of the misconceptions I had going into this workshop was that kids would be naturally good at brainstorming and coming up with lots of ideas. A child-like imagination can generate a limitless flow of creativity, right? So naturally I thought this phase would go well and be super engaging. During the workshop, I had set up giant sticky, flip chart paper so each kid could have their own space to brainstorm all of their amazing ideas for the game we were making.

However, two of the kids had told me they already had their idea for the game which they came up with prior to our session. Hmmm? In fact, one kid literally had one single sticky note on his board with detailed drawings of his game idea, taking in no other input from anyone. I kept asking this boy to come up with other ideas and his response was, “but this is my idea.” When I explained that brainstorming is the process of coming up with lots of ideas, big or small. It’s FUN to brainstorm. It is when you really let your mind run free and think “big.” He still maintained “but this is my idea.”

Basically, this kid had broken one cardinal rule of design— “don’t fall in love with your own idea.” Well, he was VERY much in love with his idea. As a result, he would not let it go to save his life.

This was my first red flag moment that this meeting was going to be challenging.

❌ Lack of compromise

One key theme that kept coming up throughout the workshop was a general lack of ability to give and take. Many of the conversations centered around one person trying to convince others to follow them, but there was little, if any, willingness to bend or adopt another person’s ideas. As a result, some kids started tuning out and becoming quiet as other voices in the room became louder and more domineering in the discussion.

❌ Unused ideas — taking it personally

At one point during the workshop, the boys finally did settle on a direction. We used a voting system as is commonly used in Design Thinking workshops to help guide the kids to land and converge on their game theme and concept. However, what I didn’t expect was how hurt and personal the kids took it when their idea wasn’t chosen. Kids (and adults) can become very sensitive when their ideas are not used. I explained that it’s perfectly fine to put forth an idea that doesn’t get used. Not all ideas fit the goal of the project.

To make them feel better, I emphasized, “just because an idea isn’t used, doesn’t mean it’s not a great idea.”

I also reminded them that ALL ideas are valuable, but some might be better suited for a different kind of game. No matter how I tried to soften their hurt egos, some still took it personally even though we maintained a respectful tone and set rules at the beginning. This was hard. I could see they didn’t like this voting system AT ALL, and having ideas seemingly “rejected” definitely was a learning curve for them.

❌ Personality clashes

As we worked through the game design project, it was becoming more apparent that some kids with stronger opinions, more developed communication skills, and higher confidence were emerging as the “alpha” kids in the group. I noticed other, more introverted kids, were starting to disengage and become quiet, not offering up ideas anymore. There were definite power plays happening. As some kids doubled down and remained stubborn by not considering other ideas, other kids began losing interest. At one point, one kid, who was one of the more dominant characters, sat with arms folded (back turned to the group) and stated, “I’m not participating anymore!” when I tried to get him to be more open to the ideas of quieter, less dominant personality types. But he was insistent that his idea was, “the one” they all should follow.

When similar gridlock or imbalances happen with adults, it is a little easier to deal with because you can usually mitigate this dynamic by simply calling on the quiet folks and drawing out their ideas. Usually, that is enough of a cue for any dominant folks to stand down a bit. In this scenario with this one kid, we clearly had a standoff happening. In this situation, I explained that we needed to be open and flexible. Refocusing the team to rally around the goals of the project was the only way I could get everyone back on track.

❌ No one listening

One of the other great barriers to collaboration I ran into with a group of 10-year old boys was the fact that no one was really listening to other people’s ideas. Even though we set rules in the beginning, it was something that continued to happen throughout the workshop. People weren’t listening to understand, but instead only waiting so they could present their own ideas and thoughts. Very little acknowledgement of other people’s ideas happened during the session. This made it hard to make progress as well, because it led to misunderstandings and more hurt feelings. As the moderator (ie. one of the adults in the room), all I could do was try to intervene, encouraging more listening. This sometimes worked in the moment, but listening was still an area that needed work!

Lessons learned

As difficult as it was, eventually, we finally finished the game! Most (not all) of the boys were happy with the final design. Not sure I would call it a remarkable success, because there were still some boys who felt left out of the process. They felt as if they had no real input or that they hadn’t added any value, which is a terrible way to feel post-project.

In the end, there wasn’t a shared sense of accomplishment from everyone on the team. That was a huge problem.

The fact that some folks felt left out bothered me. For me, a successful collaboration should make everyone feel proud of their contributions to the project, whether or not the goal from the outset was met. If collaborating is only fulfilling to someone when they are dominating the team, when only that person’s ideas are being used, then can you even call that a collaboration? I don’t think so.

I quickly realized that my prior ideas about creative collaboration being a natural, inherent ability that everyone (especially imaginative kids) can do were false notions. Healthy collaboration requires some key ingredients to be successful. Here are some of my key learnings from this experience.

💡 Collaboration is a mindset

In order to be a good collaborator, you have to be open minded and willing to put the goals of the team and project ahead of your own agenda. You have to be willing to compromise. You must think objectively about how your ideas will add to the goal or theme of what you are trying to accomplish.

In working with these kids, it made me realize that the mindset shift needed for a successful session hadn’t happened. They hadn’t realized that their thinking needed to change when creating something new with others as opposed to strictly working on their own. Possessing a collaborative, open mindset is a major component to becoming a good collaborator.

💡Collaboration isn’t a skill in and of itself

In examining all of what went wrong in our game design journey, it became apparent to me that there are a lot of key skills you need (as a participant and moderator) in order to create a positive, collaborative experience. Communication, interpersonal skills, conflict resolution, and (most of all) listening are all necessary skills to collaborate effectively with others. The ability to communicate ideas, respect other people, resolve conflicts, and hear other ideas in the first place are essential skills for great collaboration.

💡Collaboration requires mature thinking & self awareness

Especially after observing the kids I was working with (and even recalling some experiences I’ve had with adults), it became very clear to me that to be a good collaborative partner, there is a level of maturity that must be present for that partnership to flourish. This required level of maturity includes the ability to accept when your ideas are rejected and to not immediately withdraw or just stop participating. It also includes the ability to have empathy and awareness of others around you. It requires a level of maturity to self-police your own tendencies to perhaps overtake a conversation or dominate a group discussion.

I am sure many of us have been both overly vocal and not vocal enough in workshops and so-called “collaborative” meetings. From my experience in working with this group of kids, it seemed obvious to me that the ability to collaborate well is directly related to our ability to acknowledge the needs and voices of those around us, instead of just our own.

Being a good collaborator is less about one person having the best ideas in the room. It’s more about making space for all ideas to be heard. This way, all ideas have potential to take flight, setting the stage for actual innovation.

💡Collaboration can be messy

Whether it’s with adults or with kids, my experience is that collaborative efforts don’t always fit into a nice, tidy process. This is especially true when you are trying to invent something new from scratch. The “magic” that happens during the creation process doesn’t happen the same way every time. Keeping our expectations flexible is important. Also, the vibe and productivity can change drastically from one session to the next. If folks in the room have never worked together before, like in the case of our Cub Scout group, it can take time to find a groove and build trust. If a team has been working together for a while, sometimes those established relationships make collaboration go smoother. Every collaboration is different.

Maybe we just have to factor in some unpredictability, instead of expecting collaboration to be perfect or something we have full control over.

Beyond the board game

Today, those 10-year old boys I helped guide have moved on from Cub Scouts. They are older, more mature, and hopefully a little wiser after experiencing our little game design adventure together. My biggest hope is that the next time these boys are working on projects with other people, they are better listeners, more flexible, and more positive team mates as a result of our project. Or at the very least, I hope they come up with more than one idea the next time they brainstorm! 😊

As these kids continue learning and growing as human beings, my hope is that they will move closer and closer, one sticky note at a time, towards a collaborative utopia.

From collaboration to calamity was originally published in ringcentral-ux on Medium, where people are continuing the conversation by highlighting and responding to this story.

Applying UX design thinking to the craft of songwriting

I have a secret to share with the world. When I was a kid, not once did I ever dream about becoming a UX (User Experience) Design Program Manager. Shocker! Instead, I had a passion for music. I always dreamed about becoming a professional singer/songwriter. That’s right. In my late teens and early twenties, I spent most of my time learning guitar, singing, writing songs, and playing in rock bands. I even recorded a couple of independent solo albums as a singer/songwriter. However, like so many independent musicians who start getting older, I eventually decided to pursue other careers in life so I could save for retirement, pay my bills, and survive the expensive cost of living in an area like the San Francisco Bay. I ended up finding my way into a UX Design Program Manager role within Design Operations because I really wanted to combine my love of innovation, user experience, and program management into a viable career that still felt fun and creative.

After spending several years working as a UX Design Program Manager, getting married, raising my kids, then pursuing an M.S. Degree in UX Design, I had left music far, far behind. I wrote off my musical side as being associated with a past version of myself that no longer served a purpose for me. However, a couple years ago during a soul searching journey, I reconnected with where my personal joy (as an individual) truly lives— in music.

I realized, singing and writing songs is a very important part of who I am.

Creating music gives me energy. It helps me cope with life’s ups and downs and manage my emotions and stress. So, I eventually found my way back into playing music, singing, and writing songs once again. As a result, I started to spend time honing in on my songwriting craft and trying to write quality songs that have: a solid structure, great lyrics, and catchy melodic hooks.

Part of what has made this new leg of my musical journey the most interesting and effective for me (this time around) is realizing how much user experience and design thinking is involved in the process of writing songs. I’m realizing more and more that songwriting can be more a series of experiments than art at times. This is especially true when you get into the commercial side of songwriting, and you want to start licensing your music or songs for various purposes (ie. writing for another artist, writing for movies or television, etc.). I’ve realized, that the business of songwriting, and the process of writing commercially viable songs (though I’ve never written “a hit” myself), is very similar to the UX design process and how you would create a viable and successful software product.

To help explain the UX of songwriting, I will walk you through the general design thinking process of writing a song and then show you examples of my song entitled, Stay Young that I wrote (fairly recently at the time of writing this article). I’ll explain how it started off as a “low-fi” idea and evolved into a completed song with examples along the way to show you how it changed with each iteration. WARNING! You may hear off-key notes and gibberish singing, or even some ideas that weren’t quite working right. But that’s all part of the process, isn’t it? It’s also part of the fun!

So let’s get started.

Gather song requirements

Just like a product you are creating, for a song you usually start with some requirements. Much like the UX process, songwriting has its set of requirements too. Songwriting requirements depend on which goal you are trying to achieve. Just like in a software design project, you always have to work within certain constraints, and writing songs is no different. You might need to answer some basic questions to figure out what your goals are:

• Who is the audience of the song?
• Is the goal to write a commercial song or is it just for fun or for your own artistic expression?
• Is the goal to write a song for another artist to perform or are you the artist?
• Which genre are you writing for?
• What do you want it to sound like?

Once you’ve narrowed in on answers to these questions, you can get more into the hard, mechanical requirements of your song. For example, if you’re writing a pop song intended for a specific artist and you want it to get played on commercial radio, you’ll want to make sure your song fits the artist’s music style and vocal range. You also want to make sure the song fits into the typical song structure, length, melodic hooks, and lyrical content that make up a conventional, commercial pop song.

For my song, Stay Young, my goals were pretty simple. I wanted to write a light, modern, indie-pop song.

But I wanted the song to have some depth for the topic that was inspiring me in that moment: my kids growing out of various stages of their lives and into new ones.

Create initial low-fidelity song ideas

Now that you have an idea of who you are writing for and the song’s general purpose, then you can start working out your ideas. If you’re a songwriter, you might have a bunch of ideas for songs started already. Melodies and ideas may pop into your head randomly with no purpose, that’s okay! You may find that you already have an idea started that fits your song requirements. Feel free to scour your existing backlog of ideas. Also, feel free to begin noodling to get some chords, melodies, and words started. Either way, I recommend recording your ideas with just your voice and/or instrument in the most accessible and disposable format possible such as your voice memos app on your phone or computer. For lyrics, I like using a physical notebook, the Notes app on my phone, or just a Google Doc to capture my lyrical ideas. The low-fidelity process of songwriting is very similar to the stage of UX design where you simply whiteboard out ideas or use wireframes to start hashing out ideas and directions. None of these initial ideas or performances are going to go into the final product and these formats are much more easy to change and adjust when feedback comes into the picture.

The point is that you want to work out your initial ideas in a low-fidelity format that is quick and easy for you to just get ideas out of your head and into a format you can access later on. The other reason you should start with a low fidelity, disposable format is because it prevents you from investing too much time into a high-fidelity idea that may be harder to adjust and change later on in the process. Committing to high-fidelity (such as a studio recording with full instrumentation, drum loops, etc.) versions of songs too early on in the process can lead to tons of rework later on when there are changes. Even worse, committing to a high-fidelity format too early, can lead to mental resistance to rework an idea or direction that was weak or bad in the first place. High-fidelity can easily fool you into thinking your song is better than it actually is. Don’t do it! Stick to low-fidelity in the beginning stage of your songwriting process. This is very similar to the way UX designers work.

You want to keep your ideas as malleable as possible in the beginning so you can easily change and adapt your ideas and direction as the process evolves.

For my song, luckily I still have the original iPhone recording I made that captured the first initial idea I had worked out for the song melody and some lyrical ideas. Below is a link to it on Soundcloud:

• Stay Young — Initial Idea on iPhone 5–23–2020

The recording I started with is pretty rough and low-fi. It’s a good thing too. If I had spent all that energy recording it onto tracks at that point, I may have stopped developing the idea. Just like a designer would whiteboard out their ideas before committing to digital forms, a songwriter can also use low-fi formats to just gather ideas. Just the beginning, no where near “done” yet!

Use song data to inform your decisions

Yes, I know this sounds very uncreative for many songwriters (and designers sometimes), but it matters. What I mean is simply that you don’t need to reinvent the wheel. Examine other artists or products success and use that as your data points to inform your decisions. There are patterns in music just as there are in interaction design. Consider the genre you are writing for and what elements are in those songs.

For example, a pop song now-a-days is typically around 3 minutes in length and typically has this basic structure:

verse | pre-chorus | chorus |verse |pre-chorus |chorus | bridge| chorus

As you work out your ideas, it is important to consider the requirements and constraints you defined up front in your process. In both software products and songwriting, there are “patterns” and “formulas” used in both the UX design process and songwriting process that are, for lack of a better word, “industry standard.” These standards exist because it’s what your audience is used to and expects when consuming your product. Creating within a familiar framework is more likely to gain you a larger audience and therefore, more success. However, using a standard framework, doesn’t mean you are any less creative or innovative within that framework, it simply means you are following a familiar format to create your product to make it more accessible.

Once I worked out my ideas on my phone and got my song and lyrics to a structure I thought was working, I then created my first higher fidelity demo of the song to start laying down the building blocks. Below is a link to what it sounded like. A good start with a definite idea starting to form, but definitely not done yet!

• Stay Young — Scratch Vocal Demo — 6:7:30, 6:32 PM

The first demo was OK. I laid down a scratch vocal and just some drum loops and the bass to give it some sense of fullness. I think you can even hear my son in the background on this one! A song demo is like a concept design in UX terms. It gives people a way to hear a more “finished” version of your idea with more structure around it, but it is never the final product.

Solicit feedback on your song

Now that you have your requirements and have worked through our ideas, go back and check to make sure your song fits those requirements. If it’s a pop song, is it around 3 minutes in length? Does the content fit your audience? Is it a story telling song? If yes, is the story clear? Do your lyrics have imagery that help the listener get placed in the world you are creating for them? If any of your requirements don’t look like they are met and you don’t love it, keep working on it. The first source of feedback for a song will be your own critique of yourself. To help you stay on track and not get lost in the “oh my song just isn’t working” mode, use your original direction and requirements to really evaluate whether or not the song is doing what you want it to do. For example, if your song is 5 minutes in length, look for ways to cut out extra parts. Do you have too many verses? Are there too many filler, instrumental parts? Pull ’em out! Then rework it down so it fits into a 3 minute song. Does your story not flow well? Go back and break down the events of the story into their parts and translate those events into your verses. What about the chorus? Have you honed in on the main message you want people to remember? If not, go back and break down your idea into one simple message you want your listener to take away. In other words, what is the job this song needs to perform for the listener? Make sure your song fulfills its job.

Once you’ve really honed your own feedback and crafted your song, you can record a scratch or demo version of it that represents how you want it to generally sound. Then, once you have that version, play it for more people and get even more feedback. You can collect feedback from others in multiple ways and you can decide which people are your most trusted sources. Do you want to just get general feedback from your fans? Do you want to share with other songwriters? Maybe all of the above. It’s up to you to decide at what point to share your song to get feedback and with whom.

The point is, you should have a plan to get feedback and then determine whose feedback is most valuable to you.

The most important thing about feedback is to look for patterns in what you are hearing. If you see a very similar pattern, then it’s feedback you may want to consider. If you are simply hearing a lot of opinions, but no real clear feedback, then you may want to not consider that feedback. It’s always up to you to decide. The important thing is to be honest and open.

The link below is a version of one I recorded to see how it sounded with some additional guitars and a little experimental keyboard part. I listened on my own and solicited some feedback to get input on this version. This version was OK, but not really hitting the mark of what I wanted the song to sound like. Not done yet.

• Stay Young — First Guitars Demo 7:19:20, 12.06 AM

Iterate on the song feedback

Now that you’ve collected feedback, it’s time to go back and incorporate the relevant feedback into your song. One thing I like to do is separate “opinion feedback” from “technical feedback”. To me someone’s opinion is “it’s cool” or “meh?” as some examples. But if someone says, “your song is too long” or “your melody is monotone” or “you’re off key in your chorus”, those are very easily fixable things that are truly objective. Fix your technical stuff first and don’t give it much thought. As far as opinions go, again, look for the patterns. If overall, many folks give it an enthusiastic “thumbs up”, then you’re probably good to go. If you get a lot of, “meh” on your reactions, maybe you need to rework some areas of your song to make it connect more.

Also consider if you’ve really chosen the right group of people to give you feedback. Your feedback audience should reflect the core audience your song is meant for. So if that isn’t the case, go find more of your audience and get their feedback. You may find very different reactions and results. Also, trust your gut and instincts too. If something still doesn’t sound or feel right, your song may not be ready yet, so keep iterating and getting feedback.

After using my own ears and getting feedback I realized that I wanted to give the song a more “dreamy” quality instead of the more organic or country quality it had originally. I ended up recording a different bass line and my husband helped me by putting down a more effected lead guitar line. It started getting there! Not done yet.

• Stay Young — First Dreamy Guitars Demo 12:31:20, 4.29 PM

Finalize the hi-fidelity song recording

Once the song structure, lyrics and melody are solid based on a few rounds of feedback and iterations, only then I will spend time and money recording the songs in a studio. As I’ve been studying songwriting books and learning more about the music recording process, I realized that the process of writing and recording songs is very similar to the way UX design process works.

Be prepared to throw out bad or weak ideas and rework a song if you have to. It’s worth the extra rounds of iterations to get closer to the perfect song (which you will never write by the way!).

As I continued to get feedback on the song and develop the ideas, I realized I wanted to take the song to a new level. I ended up working with a producer, Kenny Schick at Basement 3 Productions who really helped me take the song into an even more modern direction. Check out the “final-ish” version of my song Stay Young!

• Stay Young — Final Version

And here is the final mastered and released version on Spotify, Apple Music and other streaming services. Enjoy!

Stay tuned and always, stay young!

The UX of Songwriting & Recording was originally published in ringcentral-ux on Medium, where people are continuing the conversation by highlighting and responding to this story.

Last year, we were fortunate to move into a 100-year-old house. Naturally several items in the old house needed (still need!) updates or improvements. Unfortunately we are only 30% handy with power tools. This has necessitated hiring contractors for various pieces of construction work.

One of the things we’ve learned when working with contractors for our home is how to separate “installers” from “craftspeople.”

Installers show up with a truck and a toolbox, and get to work. That work might not consider the entire house in context. But individual pieces of work get done, masterfully and efficiently.

Craftspeople show up with a truck and a toolbox, and ask lots of questions before getting to work. They walk around the house, and talk about a shared vision. They look at the structural engineer’s report. They view the house in broader context, and recommend courses of action. Even if that means not doing any work at all!

Note that though the tools are exactly the same, the outcomes are different. And those outcomes depend on whether the contractor approaches the worksite as just a material thing to be installed, or an improvement on the worksite as a whole.

The parallels to UX are abundant!

When I joined RingCentral 6 months ago with my own truck and toolbox, one of the things that appealed was the chance to make impact as part of a small but mighty team. Some old colleagues were surprised by my move, viewing it as a hard left career turn after 15 years in automotive. I didn’t see it that way, and still don’t. What I saw was a new and fascinating worksite. And it was already populated by a growing team of UX craftspeople.

My colleagues at RingCentral came from a wide range of worksites. Banking. Sportswear. FinTech. Health & medicine. Online commerce. Social psych research. Social media.

At each of those worksites, the tools for a successful UX practitioner are the same. This is not to say context is unimportant- far from it. But awareness of context, and the ability to adjust for it, are crucial. This ability to consider context or constraint separates installers from craftspeople in UX.

This is also not to say that installers are unimportant. Their efficient and masterful work is a key piece of a positive outcome. But are we installing one thing, or are we improving the house? Are we putting in a new water heater, or do we want to ensure that hot water is delivered to any sink or shower on demand? If it’s the latter, a house full of old, inefficient pipes could certainly challenge that outcome!

Here’s an example of context and constraint from a UX worksite: Distraction might be a somewhat desirable design consideration for commerce or social media, where gathering eyeballs and attention are important. But distraction might be an annoyance in other contexts. It might even have deadly outcomes in fields like automotive, medicine, or the military.

An installer must do the best job they can to deliver a quality product, and a craftsperson must understand the aspects of UX that the product might improve or harm. Acceptance of distraction is one characteristic of a worksite that affects the holistic outcome. As Jared Spool encourages design leaders to ask: “If we do a fantastic job delivering this product (or service or feature), how will we improve someone’s life?”

Skilled installers and craftspeople are both crucial to successful outcomes in home projects, and both start with the same trucks and toolboxes. An installer focuses on building the best thing possible, while a craftsperson considers the broader impact of an outcome on a homeowner’s life. These abilities apply to all successful UX installers and craftspeople, as well. Regardless of worksite.

Same Tools, Different Worksites: Switching Verticals in UX was originally published in ringcentral-ux on Medium, where people are continuing the conversation by highlighting and responding to this story.

I work in Design-ops at RingCentral and during our discussions with new hires, our team felt that there was some gap between how the UX onboarding process was intended and how the new hires perceived it. This led our design ops team to create a project to try to understand the potential gaps better and attempt to solve them.

Working on this project was a good opportunity to use my design thinking approach and employ some user research principles to understand how new hires feel and what they think about our UX team’s onboarding process.

Objective

The objective of this research was to understand the end-to-end onboarding experience for new hires to gain meaningful insights on their behaviors, needs, challenges, and pain points to make the UX team’s onboarding process a better experience.To achieve this goal, qualitative methods were used — user interviews, affinity, and journey mapping. The different research methods used helped us understand their current experience and identify and prioritize their pain points to find some actionable solutions.

Our Process

Conducting User Interviews

We conducted user interviews for 6 team members who were onboarded in the past few months. It helped us identify their pain points, frustrations and what aspects of the process worked well for them.

The first step to conduct the interview was creating a user interview script that is the foundation for talking with users about your product or service. I wrote a script of questions that acted as a guide during my discussions and it also helped by asking probing questions about what the new hires were thinking and feeling. Questions were asked based on different stages of the onboarding process based on our assumptions of how the current process was — before joining RingCentral’s’s UX team and the first 90 days after joining.

Synthesis of Data

Affinity mapping

This is a quick way to pull out insights from your research notes (typically done using sticky notes) and then group similar insights together to look for common themes.

Once we collected all the qualitative data, we started mapping our insights into clusters. We saw some themes emerge about the onboarding phases — which were very close to our initial assumptions. But it wasn’t time to jump to any conclusions yet! We came up with the following themes-

1. Before joining — Pre-interview, Interview, Offer decision and Acceptance to Joining
2. After joining — Initial set up, Training and First project
3. End of first 90 days

This exercise helped us look at the problem with a new perspective and draw some new connections.

Journey mapping

A journey map is a visual depiction of the actions a user takes and includes their thoughts and emotions. We charted out these themes we identified from affinity mapping to find out what the new hires

• Thought about each phase
• Felt about each phase
• Were frustrated about and their challenges
• Were happy about
• Thought could change from their perspective

This journey map was created using Miro.

Conclusion

We came up with some workable solutions to solve some of the challenges we had identified, and they are being incorporated in our current onboarding process. Our next steps would be to continue this study to determine the impact and compare with previous data.

My takeaways

• Approaching UX processes from a researcher’s lens helps understand the core of the problem.
• Divergent and convergent thinking helps to segregate what is important and what is not to solve the problem.
• To validate your assumptions, thinking from the user’s point of view creates empathy and solutions created thereafter are based on insights we received from their feedback and not simply based on our hunch or assumptions.
• When you combine scientific research methodology with design thinking mindset, it is a win-win for all!

Applying UX Principles to New Hire Onboarding Process was originally published in ringcentral-ux on Medium, where people are continuing the conversation by highlighting and responding to this story.

As a product designer who has experience working at a startup and an established company in Silicon Valley, I’d like to share some thoughts comparing these two based on my personal experience and observations.

Here’re my background stories: the startup I worked for as a UI/UX design intern is Datrium, it’s a B2B startup that helps enterprises preserve and secure their data by providing unified cloud solutions to primary storage, backup, and disaster recovery. At the time I joined Datrium, there were about 200 employees in total. (Fun fact: Datrium was acquired by VMWare in July 2020, which made it become a “large established company” now).

On the other hand, the established company I’m working for now is RingCentral, a larger company with nearly 5000 employees globally, 2400 of them in the US. RingCentral offers cloud enterprise Unified Communications as a service (UCaaS), including cloud phone systems, SMS, team messaging, video conferencing, etc.

After I reflected on my experience working at a startup vs an established company, I visualized the comparison via this table from several aspects such as work culture, work-life balance, salary, etc. This table was created based on my own experience and observations. I’d say it’s generic and may not apply to every case.

Below are a few questions I get frequently from aspiring designers who are in a job search phase or trying to decide which company they should go to after receiving a couple of offers. Here’re my insights into those questions.

Q: How do I choose between a startup or an established company?

A: I’d say it depends on your goals and background at the current stage of your career. I’d recommend evaluating different options based on the dimensions you care about most.

For instance, I’d look into future coworkers/managers, project type (2B/2C/internal tools), company culture, compensation/benefits, work-life balance, work VISA policy (since I’m an international student on F1 VISA). You can prioritize or mix and match the above dimensions according to your own preference.

I’ve heard a lot from people who have been in the industry that the deciding factor of being happy at work is always the people you work with. Before making a final decision, reaching out to future coworkers, asking them what they feel about working there, or even reading Glassdoor reviews would definitely get you some useful insights.

If you feel the people/work culture/compensation between the two options that you’re considering are similar, and you’re a new grad without any prior industry experience, I’d definitely recommend going with an established company. As a junior designer, receiving systematic training and mentorship in your early career could be very beneficial to your career growth. On the other hand, if you’re a new grad who already has a couple of years of work experience and who likes wearing multiple hats from UX research to visual design, taking ownership of a product from head-to-toe, then I’d say you can consider working for a startup.

Q: How do I know if I’ll like working at startups/established companies?

A: My answer is — you never know until you get your feet wet. In 2019, before I joined Datrium as a UX/UI intern, I had some false expectations toward the internship. I was under the impression that working at a startup could be chaotic, long work hours, stressful, fewer swags and benefits. And it turned out that it wasn’t the case. Datrium was a mature startup that raised 60M in series D funding and made revenue steadily. As you can imagine, this startup experience was way better than I had expected. Over the summer, I accomplished a project independently with mentorship along the way and got myself another highlight project on my portfolio which is beneficial to my future job search.

This experience enlightened me that I’m more interested in B2C than B2B and I didn’t know this until I worked on a project in the B2B field. It also made me want to look for UX design opportunities at established companies in my early career. I figured as a junior designer without too much industry experience, I still wanted to grow in a structured UX team and receive systematic training/mentorship at least the first couple of years after I graduate from school.

My advice to junior designers is that — be open-minded and be brave to try out different possibilities in your early career. Doing a couple of internships in different product/company settings before getting into the industry full-time also helps a lot. It does not necessarily mean that you won’t be able to get into established companies if you start your career at startups, vice versa. I’ve seen those people who are so obsessed with certain brand names and feel anxious and self-doubting about not being at the place he/she was hoping for, which might even hinder their opportunities to grow and learn in the future.

To me, each experience, no matter good or bad, is precious learning. Those experiences enabled me to know more about myself and picture my UX career path — what kind of a UX designer I am, what type of companies I’d like to look for in the future, what product field I’m more interested in, what work culture I like more, what kind of people I like to work with, etc. It’s like you gotta put some dots on a blank sheet of paper first, and after that, pick your favorite dots, connect them into your one-of-a-kind UX path.

Thanks for reading till here! Feel free to share your thoughts with me and drop comments below, or hit the clap button if you like this article. : )

Previous articles:

Why I loved my product design internship at RingCentral, and you will too!

Dear Junior UX designers: startup vs established company, which one suits you best? was originally published in ringcentral-ux on Medium, where people are continuing the conversation by highlighting and responding to this story.

Our first foster was Harper, a 1-year-old German shepherd mix found as a stray in rural Eastern Washington. She was in rough shape when we met her, emaciated from life in the wild, and medicated from surgery to remove a bad kidney. Her first 2 weeks with us were a haze of wound care, pill pockets, and veterinarian visits, so not much was “known” about Harper’s personality.

One key trait the foster organization was clear about: Harper was not friendly with other dogs. Before Harper was medicated, she barked and lunged at any dog she saw.

When “marketing” a dog for adoption, any less-desirable personality trait presents a significant challenge. If a dog isn’t friendly toward other dogs, this limits the pool of potential adopters to households without dogs. So with our goal of giving Harper a better chance at adoption, we set out to solve this barking problem, or at least understand the limits of Harper’s dog tolerance.

Once Harper healed, we took her to supervised meetups on leashed walks, in parks, and in fenced yards with dogs we knew would be friendly. At each of these meetups, Harper did indeed bark like mad when she saw a new dog. But a fascinating pattern began to appear: After an initial greeting and 5 minutes together, Harper always settled down. The barking would stop. She would even play with the other dog!

Harper wasn’t barking because she was unfriendly to other dogs. She was barking because she was *excited* to meet other dogs.

The happy epilogue: Armed with this new data, Harper’s adoption profile was changed, and she found an amazing new home… with another dog.

— — —

No matter what species you’re designing for, you need to understand the “why,” if you want to understand the behavior. This is design thinking at its most pure. And it’s applicable not just to dog adoption but product development as well.

If your design goal is a useful or delightful experience, you can’t simply look at one engagement metric, like frequency or time spent on an app. You must understand the “why” behind that metric. And to understand that, you must conduct research that captures a fuller context of use.

A hypothetical example: Let’s imagine your team has existing data which shows a large percentage of users engaging with a core feature far less than expected. It would be easy to assume that people don’t use that feature often because they don’t like it or it’s not useful. (In other words: It’s easy to assume that the dog is barking because it is unfriendly.) One might assume this less-used feature could be removed from future versions of the app.

But once you look beyond this data point and explore the context for this behavior (via interviews, contextual inquiries, or even other quantitative sources), you might uncover new data that completely disproves your hypothesis. You might discover that folks are using this feature once per week for a very specific but very important purpose, and they’re actually quite pleased with the experience. You might find behavior that isn’t tracked by your data, such as visual searching or browsing.

So, although a usage profile might look bad if you rely on metrics like frequency or engagement (the dog is barking), in reality the app experience is useful and delightful (the dog is excited to meet other dogs).

— — —

For designers and researchers, design thinking isn’t just about collecting behavioral data. It’s about understanding the goals for your product. And once established, it’s about collecting the right data, at the right time, in the right context, with the right outcomes to align toward those goals.

And of course, whether your goal is a useful app feature or a happy home for a stray dog, always be mindful of assumptions affecting your hypotheses. It’s important to understand not only which dogs are barking, but why they’re barking in the first place.

— — —

If you would like to donate to a local animal rescue organization or humane society, here are a few suggestions:

Peninsula Humane Society & SPCA

Big Dog Rescue Project

Red Waggin’ Rescue

Design thinking for pet adoption and product development was originally published in ringcentral-ux on Medium, where people are continuing the conversation by highlighting and responding to this story.