Code monkey in defense of good design work and tight cross-disciplinary collaboration
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 UX 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
Communication between the participants usually is the most important factor that decides the fate of any project, even more so when it comes to a cross-disciplinary one. When you have people with very different ways of approaching the same topic working together, there is always a lot of potential for misunderstandings and friction, even though everyone is ultimately working towards a common goal. In a software project, this can occasionally be seen between developers and UX designers, as well as between the customer and the development team in general.
The friction and conflicts usually stem from incorrect presumptions and inability to see the other person’s point of view. No one can master everything, so it’s pretty much unavoidable that in a cross-disciplinary project, which requires the expertise of professionals with years of experience and training in their respective fields, there always is a certain initial lack of understanding between the different disciplines. The only way to bridge that gap in understanding is communication.
The first step towards successful communication is not to presume anything. Always ask if there is any uncertainty and explain the reasoning behind your views in a way that is easily understood by the listener. As a programmer, if a designer gives you a design that seems unnecessarily complex or impossible to implement within the given budget, they aren’t doing that just to make your life miserable. They probably just can’t see what implementing the design requires on your side of the fence or maybe they have accidentally overlooked something that significantly affects the implementation. And as a designer, if a programmer bluntly shoots down your best idea, it doesn’t necessarily mean that they don’t like it or that it isn’t great from the UX-perspective. It just might take an order of magnitude more work to implement than the “good enough” solution and that time is a lot better spent elsewhere, given your limited budget. Also, remember that no matter which side of the fence you are on, and how much experience you have, you could always be wrong, even when it comes to something in your own field of expertise. Be open and listen to other people. If someone can support their opinion with good arguments, they might be onto something. Never just withdraw to your own cave and murmur behind their backs how the other guys don’t understand anything. A software project is a balancing act between different disciplines and there is never enough budget and time to do everything. Which leads us to our next topic.
Prioritization and good compromises
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).
Antti Martikainen
Code monkey, prefers good tea over bananas, likes to occasionally stop and think about things
