Skip to content
Technology

Blog: Code Monkey in Defense of Good Design Work and Tight Cross-Disciplinary Collaboration

11/30/2017

What do designers actually do?

There often is quite a bit of confusion about what “UX designers” and “service designers” actually do in a software project. A common misconception is that they mostly just design the pretty visuals and draw UI mock-up pictures, so that the aesthetically challenged code monkey, such as myself, has a reference to go by while implementing the UI. I used to hold that same misconception when I was starting out my career. Now, after a couple of years, I have learned that I was wrong.

A modern software project tends to be a very cross-disciplinary undertaking and agile software teams are often relatively small. This leads to people having to wear many hats. On the technical side, this has led to the rise of roles such as the much coveted “full-stack developer”, which emphasizes flexibility and versatility. However, designers are often overlooked and underappreciated in this regard, even though a good designer can give many full-stack developers a run for their money in terms of both.

Within the team, the role of the designer usually isn’t limited to doing the visuals and designing the user interaction and usability aspects of the software. They also lay, or at least heavily participate in laying, the groundwork for technical design. They do this by mapping out the underlying needs of the users and drafting a concept to fulfill them, as well as doing the initial modeling of core concepts within the domain at hand. Additionally, they also define the rough logic flows for the various use cases through UI design. All of this requires an extraordinarily wide skillset. In addition to the more obvious ones (like excellent communication skills, ability to understand the user’s application domain, a good grasp on human behavior and psychology, a keen sense of aesthetics, UI design skills etc.), this also includes decent skills in analytical thinking and problem-solving. Not to forget at least a basic understanding of the software development work that goes into translating the concept and design work into an actual software product.

Why is it valuable?

Given that the designer often plays such a major part in the initial design phases of the project, where decisions are made that define the broad strokes and can potentially make or break the whole project, it seems bizarre that they are often given fairly little time and money to do their job, at least when compared to the whole scale of the project. Especially requirements analysis, conceptual modeling and iterative concept work done by a competent designer should be valued similarly as technical architecture and design work, given that they essentially are two sides of the same coin and complement each other. Tight collaboration and balance between the two is required for good results. Neglecting either one or lack of communication between the two will lead to bad decisions, cause unnecessary complexity and get more and more expensive to fix as we go down the line. Good quality concept work and a UX strategy design, which has it’s priorities in order and collaborates actively with the technical side of the team, will pay itself back over and over throughout the project.

Another aspect that might be of interest to those who care about the financial side of things, is the effect of UX design on the success of the product in the marketplace. Nuance and refinement of the user experience often is one of the major factors that makes a product stand out and raises it out of the sea of mediocrity. This can be extremely important, especially when it comes to products that are aimed at the consumer market. Steve Jobs era Apple and Blizzard (the game company) are good examples of companies, whose success is heavily based on this. Though the harsh reality is, that fine detail and refinement often require significant amounts of time and money. However, there is a nice write up here on the Vincit blog by Jussi Ahola, which discusses the merits of such an approach and how to prioritize to be able to have a fighting chance of pulling it off on a limited budget.

If you are here just for an explanation why design work is valuable and you are too busy to read this all, you can stop here. My message for you was above and can be summarized as:

"Don’t underestimate the value of the work of a good designer. If you are someone who controls the budget and you are fairly certain that the designer knows their stuff, understands what you need and is capable of making good compromises, give them the resources and freedom to do their job well. It will benefit you greatly in the long run."

However, if you are someone involved in software development, or any other cross-disciplinary project for that matter (or maybe you are just curious and have the time), then read on. I’ll briefly go through the factors that in my experience are most important for successful collaboration between different professional disciplines, such as designers and the technical side of the development team. These are communication, prioritization, and the ability to make good compromises.

Communication

In the real world, there is never enough time and money for perfection. You have to compromise and discuss to find the balance that gives the best outcome with the limited resources that you have available. When it comes to a software project, the list of different aspects that are competing for the same limited budget is a long one. They also have complex interactions, especially when you add the customer’s business and financial goals into the mix.

Priorities between the different aspects, such as reliability, quality of UX, feature completeness, security, accessibility, maintainability etc. are a bit different for each project. Establishing and maintaining a decent common understanding of what they are, requires a lot of communication between everyone involved, including the customer. The compromises made during a project should always reflect the actual priorities of the project at hand. So when a conflict arises, you should always try to consider how well your side of the argument actually fits the project goals. If after considering the project priorities you feel that you aren’t getting enough time and resources to do your job well enough, and it can’t be solved by readjusting the focus within the project team, it’s time to talk to the person holding the purse strings. The options there are to adjust the scope, or allocate enough extra budget for the project to be completed properly. However, keep in mind that what you are asking for has to be justified in terms of the customer’s business goals. You might think that the product, or at least your favorite aspect of it, absolutely needs to be a shining example of excellence. However, the reality might well be, that if too much time and money is poured into making a total overkill of a product when “good enough” would have sufficed, the whole business case for it falls apart and investments will never be recouped.

Despite the best efforts, priorities often aren’t very clear from the outset and evolve a bit throughout the project. This means, that to fulfill the project goals as well as possible, you will need to adapt your plans and designs to match, as the priorities get clarified. Agile and iterative software development methodologies try to cope with this, but texts about them usually focus on the technical development work, not touching on any related disciplines that might be participating in the project. Though the same core ideas probably apply to many other related disciplines, such as UX design. One such core idea being, that to be able to adapt smoothly throughout the project, you’ll need to try and avoid adding any unnecessary complexity and clutter by focusing too much on details in the beginning of the project. Start adding more depth, nuance, and detail only once the general structure has solidified. This avoids slowing down the development process with excess baggage, that needs to be carried throughout the whole project but might get discarded later on. In other words, start out simple, design for iteration, build up in stages and prepare for compromises.

We are all on the same team, working towards a common goal (even the client)

As a summary, the key to successful collaboration is figuring out together what the common goal actually is, trying to understand what each other’s views on how to best achieve it are, and finally, trying to make the best possible compromises based on that information. All of this requires a lot of communication, there is no avoiding it. Communicate more, be more open and the world will be a better place (at least around you).