How to get the worlds of software development and UX/UI design to work together on common goals.
As the percentage of development teams working with user experience (UX) and user interface (UI) design teams has steadily increased, shifting from being the exclusive purview of large organizations to becoming a critical part of the process of software development for even the smallest of teams, the importance of those roles has become universally accepted. Unfortunately, a smooth integration of all of these roles hasn't followed along at the same pace. In this post, we'll be going through some of the (avoidable) pitfalls in trying to get these teams that speak different languages to work toward a common goal.
Creating software before the inclusion of analysts and designers was incredibly easy... and often incredibly bad. Many developers, having worked with the same set of users, under the same business goals, following the same workflows, were under the impression that their grasp of the functional needs was enough to build the software required. Designs became a glut of tabbed interfaces, a hodgepodge of modal and modeless dialogs, and stacks of input fields in no discernible order. The applications built enabled users to complete their tasks, but were accompanied by endless fighting with the system itself.
Developers are masters of their environment: APIs, frameworks, languages, libraries, best practices, and coherent programming patterns enable them to structure applications in ways that allow for relatively easy modification and addition of new functionality. Applications with size and scope dimensions unimaginable in the early days of programming are now the norm, and creating any piece of software that will be able to grow requires adherence to standards that become the critical piece of learning for junior coders entering the field.
Modern development has reached the point where each tier of an n-tier application can be swapped for a new technology with minimal rewriting of the existing codebase. In fact, with new platforms and frameworks coming out seemingly every month, developers have their hands full trying to stay abreast of the bleeding edge, lest their skillsets become outdated. This leaves very little time to focus on the aspects of software design that goes beyond the underlying architecture and coding standards, one of which is the most crucial to the end user: the user interface.
As developers focus on making sure the machinery of the application runs smoothly and is as future-proof as possible at the time, the actual building of the interface becomes a second thought, and is typically approached from the perspective of the system, rather than the user. The time and expertise to fully understand the workflows and processes that assemble a user's day at the office isn't available to a developer who has to commit their time to their own world. While it is possible for certain individuals to possess the ability to bridge the gap themselves, the vast majority cannot and do not.
This has led to the software community creating canned solutions to the problem—visually appealing pre-built themes that can be incorporated with a few lines of code and UI guidelines that provide set navigational and input paradigms that reduce the mental overhead of interface design to the equivalent of following IKEA furniture assembly instructions. The end product, when compared to the columns of input fields on a battleship-gray background, is aesthetically beautiful, with a somewhat minimized cognitive load due to the use of popular interaction models.
But this "one-size-fits-all" mentality results in the same superficial success as anything else with that label—it's better than nothing, but it ignores the nuances and idiosyncrasies that populate every end user's tasks within their company's specific environment. Developers aren't groomed to be the solvers of these kinds of problems, but are doing their best in environments that lack the resources of people who can, using these canned approaches to at least remove some of the "fight" from the system.
As developers focus on the interactions between different systems and libraries, designers focus on the interactions between the user and the system as a whole—from the actual software, to the environment they're in, the equipment they work with, the people they gather data from and that they report to. With a holistic view of each user in the system, designers create interaction models and visualizations that aim for an intuitive approach to each workflow.
The minimum viable iteration of any product is that which is at least useful to some core set of users, and it is that low watermark that is the nucleus on which everything else is built. While development introduces feature after feature, it becomes design's duty to translate that into usability. They need to ensure that anyone interacting with the software never experiences a "lost" moment—that they can always undo, come back, change something from several steps ago, change things wholesale—in ways that make sense to their understanding of the problem.
Humans tend to gravitate toward laziness or, put more gently, the path of least resistance. They will try to solve problems in a manner most obvious to them, and it becomes up to the designer to suss out that path and help introduce it into the software without a reliance on guidance and documentation. Products that "just work" very quickly gain adoption among the target audience, while the road of development is littered with great ideas that have suffered from poor execution.
Development will often question why design is proposing solutions that aren't "off the shelf" and require a lot more customization and creation of new modes of interaction. Part of design's job is to avoid the garbage pile by translating the useful into the used, and that can only be achieved by modifying the application to the user instead of the other way around. Recognizing that priority will help developers understand their counterparts better, and will change the light in which they see design decisions being made.
Typically the first thought that people have in their minds when they hear the word design is the aesthetic world, the side comprised of colors, patterns, textures, and styles. Software is no different, and visual design plays an important and impactful role in the success or failure of an application.
Aesthetics are key in increasing the enjoyability of using software, and while the individual aspects that constitute visual design seem like a much less complex aspect to integrate, they can contain customizations that are more difficult to implement than the interactions from the UX designers.
While colors in dashboard-type applications are readily apparent in their importance, being able to customize the size/placement/color/weight of text can allow designers to convey a lot of information very quickly. Additionally, those dashboard-type UI elements can be parsed out into multiple sections, all of which can be used to present data to the end user.
Think of something as simple as a gauge, broken out into the needle (color and length), the different slices, the different sections within each slice, the size of each section. All of these modifications can take a fairly simple gauge and transform it into something as complex to develop as an entire workflow.
Now that we have a proper understanding of where both groups can best flex their respective muscles, how do we ensure that things go as harmoniously as possible? Regardless of the stage the project is in, each team has critical value to add—we want to avoid blind handovers and siloed tasks, and provide everyone with a sense of agency during the process.
While it introduces overhead, there needs to be a feedback loop from whomever the primary producer is at each point in the project to every other team. Below we'll discuss one of the ways to organize the flow of information and the expected feedback from each team at each juncture.
During the initial phase, after users have been interviewed and requirements have been gathered, designers will begin creating wireframes. These simple, low fidelity sketches provide an easy way to communicate a desired interaction, and it's during their creation that development can add their voice.
Interactions that seem superfluous, or that could be swapped out with a more easily implementable solution, are often points of contention when there is limited communication between design and development—too often, developers are left holding the bag on trying to implement functionality that wasn't properly assessed ahead of time. To avoid those kinds of scenarios, a sample workflow that elicits feedback from everyone responsible for the application is as follows:
With this design workflow, everyone has had a chance to provide their input when it is of maximum value—developers aren't left with wireframes and style guides that aren't implementable within the given time and budget constraints, and designers don't feel like their vision has been compromised.
The downside is that there is a sizeable increase in the amount of time needed from development resources across every tier involved. The equivalent of 10-15% of the time allocated to wireframing should be matched by time from those teams. Depending on project size, this may seem like a large investment, but this should be viewed as insurance against issues cropping up well after design has finished.
Although the bulk of UX and UI design tasks are complete once the wireframes and style guide have been approved, their input is still needed once development begins. Just as development provides feedback during the design phase, the UX and UI team is on hand to ensure that their vision is carried out.
Issues may arise during development due to miscommunication earlier on (e.g. data thought to be present isn't, estimates for adding functionality were off, existing elements aren't as customizable as assumed, etc.)—the more time spent performing oversight during the design phase, the less of a chance of problems coming up. However, should setbacks occur, design should be involved to construct resolutions that are incorporated into the complete scheme, and not just bolted on.
Because of the "insurance" purchased during design, the overhead of UX and UI during development is much smaller—roughly two hours per week of the development timeline for each designer involved on the project. As teams work together on more and more projects, the need for this type of development-phase design oversight begins to drop.
Though it might seem trivial and unnecessary, highlighting the contributions of each team is critical to engendering goodwill between those teams. Nothing churns up ill will faster than seeing one or two individuals accept praise for an amazing, easy-to-use, and beautiful application when there are several groups whose contributions go unnoticed and unrecognized. The leads of each group should be called out, along with any individuals whose work was extraordinary. Making sure that the credit is handed out in due measure is part of what helps those teams get better at working together through future projects.
Time is the critical ingredient to getting design and development teams to work (and play) well together: time in each other's tasks, time spent listening to each other's requirements and expectations, and time spent from project to project.
Conversely, the more these teams are walled off from each other, the worse the relationship will be, culminating in applications that are just conglomerations of compromises. By understanding the limitations that are part of the reality of each role, the other groups get a better idea of why certain decisions are made, creating empathy and recognition.
Chris has spent the last decade working within the professional services area of software development, with a concentration in front-end technologies, working hand-in-hand with UX architects, visual designers, and developers of all levels of experience in order to provide clients around the world with solutions to drive their business.
Subscribe to be the first to get our expert-written articles and tutorials for developers!
All fields are required