Developing with Design

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.

Table of Contents

• Table of Contents
• Identifying Development Weakness(es)
  • The Role of Development
  • The Limits of Development
• Recognizing Design Strengths
  • Useful & Usable
  • Appealing & Desirable
• Fusing
  • Voice of Reason
  • Voice of Guidance
  • Sharing the Limelight
• Conclusion

Identifying Development Weakness(es)

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.

The Role of Development

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.

The Limits of Development

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.

Recognizing Design Strengths

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.

Useful & Usable

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.

Appealing & Desirable

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.

Fusing

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.

Voice of Reason

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:

• UX Designer sketches a wireframe and identifies all areas of interaction and expected results, with UI Design filling in the expectation of how the elements will be styled.
• Developer reviews wireframe with UX to measure feasibility of all non-standard functionality, and to highlight available alternatives for consideration. If the Developer only maintains the frontend, then the following sub-steps occur:
  • Developer checks with database and business logic team(s) to see if the required data exists and\or can be stored, and is in a consumable format for the application.
  • Those teams determine the effort to present or store the new data and pass that along to UI Developer.
  • Developer estimates the effort required for new interactions and presents the findings (including any feedback from the database and business logic teams) to the Designers and Project Manager.
  • In case of any major impact to the timeline of the project, the Designers and Project Manager meet with the Project Owner to discuss the impact and viability of the available alternatives. The Project Owner can then decide what the budget or timeline will allow for, and if the alternatives are worth the trade-off.

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.

Voice of Guidance

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.

Sharing the Limelight

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.

Conclusion

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.