Scott Himmer has been in the User Experience field for over 20 years working with a variety of companies large and small performing the full gambit of UX More aboutScott

United We Stand Or Divided We Fall

In software development UX designers and software engineers can get locked in verbal combat which feels like a chess game of debate and wordplay. Ive been there too many times and have the battle scars to prove it. If there has been anything Ive learned from conflicts in the software development process its that its not exclusively a cultural phenomenon and obviously its not productive.

Web Design And Development Company In Ludhiana

The people involved in the conflicts generally react to a negative state of the world that no one wishes to be in. Sometimes it says more about a particular culture than us as individuals. Regardless of the reason its not a good state for the organization or company to be in and will rob you of productivity team cohesion and focus on delivering customer value. Every company and department has its own challenges. In this article we will go over some areas where you might find the challenges manifesting what some of the contributing factors are and strategies to work through the challenges.

I used to see the conflict between design and engineering in the software development process as annoying and an impediment to software design. When I began to see patterns in people and organizations involved in the conflicts mentioned above I started to lean into the conflicts and see them more as an opportunity. I want to highlight some common contributing factors to design and engineering conflicts and lay out some strategies to work through them.

While engineers hold the keys to feasibility and how the technology works designers hold the keys to the customer/market need and principles toward a delightful user experience.

Web Development Software

If the two sides design and engineering dont come together in perfect harmony it could result in a functional feature that customers dont enjoy or a good experience thats not efficient and/or expensive to build. Its not an either-or but an and. The design and the tech have to come together in harmony to balance the feasibility with aspects of a delightful experience.

I have found that often its easier for an engineer to see the aspects of a good user experience than for a designer to understand the technical aspects of how something functions let alone how feasible it is. Regardless the two sides work best when both lower their guards and reach across the aisle. Only then are your teams truly committed to delivering a great customer experience.

There can be several contributors to the aforementioned dissension. From an organizational structure standpoint contributors to the chasm could be boiled down to the following categories culture teams roles and individuals.

Best Web Development Company

A review of the literature in saylor.orgs course lays these categories out in a bit more detail and they note that sometimes the structure of the organization itself can directly lead to conflict whether that be based on the organizational structure or the authority provided within the structure.

Ive seen these categories manifested in several ways. You may be able to relate to some of them. Lets discuss them below.

People do what they get rewarded for. If your organization incentivizes teams based on productivity they will get good at cranking out widgets. Even if those widgets fall short of the customer expectations the teams will become good at delivering what you asked for. Their focus becomes output over outcomes. This can cause teams to cut corners and produce good-enough solutions that miss the mark once released to customers. This is largely driven by the culture within the organization and can permeate the management hierarchy.

Similar to what I mentioned regarding culture a team while aligned with the larger culture typically has a team sub-culture. Sometimes a team culture can be seemingly at odds with the corporate culture. For example a corporate culture that is collaborative and open can have teams that are hyper-focused on metrics and productivity that misconstrue the intent of the culture to meet productivity metrics. This is generally done to reduce uncertainty. Ive worked with teams that became so hyper-focused on themselves that sizing a single user story practically took up an entire meeting.

Staying in our lanes as designers and engineers. Personally I couldnt be more opposed to people staying in their lanes. I recognize that designers and engineers fulfill specific business needs but we should be a unified body when it comes down to delivering outcomes. Engineers should have opinions on design and designers should have opinions on the applied technical solution. The cross-pollination of views should support one another which almost always leads to a better outcome.

I can be a contributor or a hindrance. I can become so focused on myself and my desires that I close myself off to others views. Rather than focusing on the outcome and the team my views are forced on others including the customer. I have seen this causes engineers to be entirely focused on output Just tell me what you want from me rather than collaborating on the outcome.

Meet TypeScript in 50 Lessons our shiny new guide to TypeScript. With detailed code walkthroughs hands-on examples and common gotchas all broken down into short manageable lessons. For developers who know enough JavaScript to be dangerous.

Let me provide a few examples from my experience. I worked at one company where I tried several experiments to work more effectively with engineering. At a certain point a prevailing schism was entrenched and a rather strong engineering-focused culture of let us build it get out of the way and well let you know what we need. This tension had created an us vs. them mentality.

For this same company I was brainstorming with a team for an upcoming project. As we started to get into sketching I was met with blank stares followed by a litany of technical constraints. It was awkward to say the least. Reflecting on it I dont think it went well because there wasnt Product Owner buy-in nor the proper context was set. I realized from that experience that when we are entrenched in a particular culture/team mindset focused on output for an extended period of time it can be poisonous and entrench not only our behavior but also our mindset.

Last but not least while working at a different company I noticed a middle management cultural problem. The senior leadership spoke about collaboration great design and high quality. The agile teams executing on work agreed with this philosophy and were trying to work towards the leadership vision. However middle management was making decisions that conflicted with senior leadership. The engineering manager would tell engineers to build things that completely excluded design. When designers tried to engage in the process the engineers were just following orders. There were engineering building and shipping things with little to no Product Management or UX Design input which showed in the product.

For an organization to be successful they need to be united. We need to balance our thought processes and cross-pollinate our skills for our organizations to thrive.

It is wise to give the organization and teams the benefit of the doubt. Too often were all just caught in the middle of what appears to be dysfunction. That dysfunction can be an opportunity for change if we learn to navigate the distraction that leads to conflicts.

Several studies have dug into this problem space of conflicts with teams specifically UX designers and software engineers. A 2002 study by Dejana Tomasevic and Tea Pavicevic found that tasks conflicts are the most common type of conflict. A 2019 study by Marissa Wilson also found that 100 of conflicts reported were task conflicts.

After being in the trenches for a while Im not surprised by these studies so Id like to add some color to the study findings directly from the trenches. From my experience most of the barriers to engineering and design collaboration are simply distractions. Although cultural issues can be barriers to collaboration if people really want to bring about a positive change they will find a way.

Though the list above is not exhaustive there have been common themes in the various companies and teams Ive worked with. The teams you work with within your company may be experiencing one or multiple of these distractions. Hopefully not all of them Regardless designers and engineers will have conflicts if they work together. Its our job as business partners to lean into them and work through them for teams to be successful.

I think its crucial to understand that trust has to be the cornerstone of any team unity. In an article by Built In in 2021 they provide a variety of examples for uniting teams. In it Jillian Priese Engineering Manager at Granular tells us that for her teams When trust is present it makes all the difference in the world. And that without trust its easy for engineers and designers to question one anothers motivations and abilities. Whatever the barrier we must employ strategies to close the gaps and bring unity to the team.

Its really powerful and rewarding when engineers are more aligned with UX designers because they can elevate good designs to be great designs when theyre fully engaged. I like to believe that engineers breathe life into UX designs through the power of technology.

As noted above no company is the same and different tactics should be used depending on your teams challenges. Here are some practical examples of how I have put the tips above into practice.

At one organization I came in as the lone designer being dropped into an existing team. It was awkward because the culture had generally been tech-centric. I was the outsider and struggled to make headway. Over time I realized that the team was open to more design collaboration but was a bit new to working with a designer. The team was in another country so I petitioned to spend a few days working with them.

Part of my plan was to focus on our epic which has a lot of frontend work the other part of applying some design exercises. Since the team was new to design thinking we did a lateral thinking exercise and UI pattern workshop. After that things began to gel with us. The team became more user aware and empathetic and the team started to come to me with UI defects and great ideas for solutions. I enjoyed working with that team.

At another smaller organization the UX team was positioned with the Product Management PM department. The PM and Engineering departments were located on separate floors in the same building. It didnt take long to realize that the barriers to collaboration while manifesting in several ways were rooted in physical separation.

To start working to resolve this I set up shop in the engineering space a few times per week. A sort of UX Help Deck if you will. At first I think they thought it was weird but eventually people began to open up. It facilitated many opportunities to better understand the teams needs educate them on the users needs learn about their tech stack and find in-roads with Product Owners and Engineering Managers. Fortunately much of the engineering team appreciated it. So we built great relationships and made a lot of progress in a short amount of time.

At a much larger organization I worked against a heavily entrenched engineering-centric culture. I made quite a few mistakes in that environment such as not seeking more clarity on the authority of roles for the project not pursuing more clarity in the project direction and priorities and pushing back more against unreasonable hot-headed stakeholders.

I gained a lot of patience working with architects that had little experience working with UX designers. We were speaking different languages at different levels about different needs. They had a ton of domain knowledge from years of experience. So they would pull these obscure edge cases out of thin air in conversations as a sort of trump card to any reasonable design recommendation. It was frustrating and humbling. To them UX was all about looking pretty the visceral aspects of the user interface. Sigh.

From my end they saw UX as the lipstick they could just apply to the pigs they wanted to build. The in-road there was playing to their mindset. The architects fundamentally wanted to build a system that was robust scalable and easy to maintain quickly. The system being user-centered was the least important in their mind and even that was generally boiled down to looking nice which is not user-centered.

However I believed we could build user-centered solutions and teach them along the way but I had to think more modular and scalable. We needed to establish a frontend framework quickly and lay down some foundational guidelines we could build upon. We used that as building blocks that engineering could buy into. That helped them see UX as an ally to their goals rather than an adversary. We created a design system that helped us focus on user needs yet efficiently design at scale. While we got buy-in pretty quickly with engineers we eventually began to see traction with the architects as the slow grueling process slugged on.

Finding the impediments that are preventing the unification of the clan is important. Its essential for your organization your customers and your sanity. It does entail effort but is well worth it. Experiment with your teams to find what works for them. The same strategy might not work for every team. When you meet resistance dont pull away but lean into it and be patient.

Challenge the status quo when appropriate. You may ruffle some feathers at first but sometimes disruption is needed to get to a better state.

You may not make friends at first but you will get respect. You may find that thirty percent of the people are on board with you. Another thirty percent are interested but not yet sold. The remaining percent of nay-sayers who want to continue with the status quo will eventually come along as the rest of the clan unites around them. Fight the good fight my friends and unite the clans