← Blog

3 years ago

The pitfalls of being a design island in a small software company

By Kelly Rauwerdink, Creative Director

At times, I feel like an island.

As a software designer, I have been a team of one almost my entire career.

While it can be inspiring to have a blank canvas with complete autonomy, it can also be daunting to take on such responsibility solo. Working alone on design at my company or on a client project usually means that I will have a wide spectrum of roles. I begin a project by interviewing my client to find out what they’re trying to achieve. I then do market research and come up with some ideas to propose to them for how we might go about meeting their requirements. From there, I continually switch out my hats of being a visual designer and a developer in order to bring the ideas to life.

I have a sneaking suspicion that there are lots of other islands out there, too. It’s important for us to share our knowledge, challenges, and successes, and most importantly, find ways to involve the talented people around us in our design process in order to become a part of the mainland.

Design Isolation

Isolation comes in two forms when we discuss my design experience. Isolation can be felt physically by working alone, and also felt mentally when there’s no one to collaborate or share ideas with.

There are at least two commonly held beliefs at software companies that are root causes of design isolation. I do not believe that they benefit design quality for the reasons that I discuss below.

  • Design is a solo activity.
  • Design can only be advised by other designers.

Working Alone

In contrast to how design projects usually work, our development team typically uses pair programming as a way to reach the best outcomes on a project. In this mode of working, two developers collaborate together on one computer to solve a problem together using code. We use it for ramping someone up on a project, to learn new languages and skills, problem solve and transfer knowledge.

Design, however, is not usually a paired activity; this is de facto true when you are the only designer in house or the only designer on a project. Some reasons for this could be that developers feel like they don’t have much expertise to contribute to design. Developers may have an idea that they aren’t good at design, or that their ideas aren’t sophisticated enough to be shared. Additionally, developers are often under pressure to finish the work that they have been assigned for their iteration cycle. Therefore, it doesn’t occur to them or their managers that they might be spending their time wisely to pair with a designer.

Catching The Issues

Unfortunately, I usually don’t stumble upon the effects of my decisions and actions until they reach the code phase in a project. The little, unchallenged issues that skipped past my attention now get worked through the implementation phase and always bubble to the surface. By that time, these decisions are being seen by the client, good or bad, and developers and I have to create solutions on the fly. Typically, project deadlines are short in my work, so decisions have to be made quickly. If the choices I made earlier are not the best for the project, I might not have an opportunity to redirect or iterate, or risk extending my deadline and putting stress on the other people on the team or project.

Input from other people early and often in the design process always has a positive effect on the project quality and timeline.

The Design Mindset

As with any creative work, if someone isn’t directly involved in the process of creating, design can look like magic. Often there is a perception that it takes no time at all to do design. Team members who aren’t involved with design have difficulty conceptualizing the decisions and thought processes that were put into the work, and therefore can have more difficulty empathizing with the overall process.

This is one reason why it can be beneficial to the project for developers in particular to get exposure to design work. They can get a deep understanding of the product they’re building very quickly, which makes it more likely that they will build the right thing the first time around. Design also gets exposure to the issues that developers are facing (what does the data structure look like, again?) Developers and designers spending time collaborating is beneficial to both roles.

Who Is Qualified To Help?

When I am the only one making design decisions, they are solely based on my experiences and interactions with the world. The choices I make are in response to what I remember doing, seeing, and hearing consciously or subconsciously, that can be applied to the design problems I face. Unfortunately, that means that all my assumptions stick, and reach many people. I need to take a diverse set of views into consideration so that I understand the variety of needs and interests of my audience.

To me, it feels especially important to emphasis the importance of collaboration because I credit a lot of my success to experiences that I’ve had in which I was challenged or questioned. I excelled in school because I had skilled people to bounce ideas off of, learn new techniques from, or to use as inspiration.

Developers aren’t the only other role that can cross-pollinate with design. Having a design opinion makes you a human with unique experiences and a valid understanding of the world. What this means is, if you’re a person who isn’t me, chances are that I will be interested in hearing what you have to say about a problem. It helps me to know what other people’s interpretations are of the things I design, so I can express intentions across a broader audience.

Beyond Design

As the only designer on my team or project, I am responsible for much more than creating the UX/UI and visuals. The additional tasks outside of the design title range from copywriting/microcopy, cross-browser testing, client communication & feedback loops, project management, and front-end development. These types of activities require different types of thought, time and skill. These tasks often fall to the designer, but can also be dispersed throughout a team in the absence of a true product manager.

This takes some conscious organizational work and buy-in from the other team members, but the effect is that everyone is more engaged overall and the shipped product is of higher quality.

What Can Be Done?

Check the pulse

Say ‘Hi,’ to the designer in your team’s neighborhood. Ask to see if they want to discuss what they’re working on, or collaborate on any upcoming work. Talk to them to find out if they’ve been getting enough useful input on their projects.

Talk to your manager(s)

Sometimes isolation creeps up on you. If you think your designer isn’t getting enough participation from the people around and are taking on a larger share of the work than they can handle, chat with your manager about whether you and your teammates can re-allocate some of that labor.

Try some design!

Pick a problem to solve, and try to solve it using design! A pen and paper is enough to sketch out what an application might look like to solve a specific problem. It’s fun, and helps you get into a product oriented design mindset.