Guiding Principles for Connecting Design and Development Teams

I recently took part in a debate on the relevance of design documentation, and one question that came about was, ‘what do developers expect from design documentation?’ Do they expect to have everything specified straight from the start? The styles and exact measurements for each component, having all the use cases covered? From my experience, they definitely do. It’s great to work in an environment where the requirements are stable and the plan is clear and predictable. But the reality is, user needs change and without stability you have a volatile, unpredictable plan. Since requirements change everyday, software design and development plans do too.

Agile, through fast and incremental development, addresses the current context by pushing quick and continuous releases to meet these ever-changing requirements. In order to sustain this fast process, design delivery and documentation has to evolve in order to meet Agile development needs.

Design, although a distinct process, is interlinked with development throughout the product’s life cycle. As an application evolves, the design changes and adapts to new user needs. This results in the agile design process becoming less document-oriented, with a greater emphasis on smaller components and pieces of functionality. As well, the direct communication between designers and developers becomes key to delivering design specifications. By constantly improving on delivery and communication, designers can provide developers with enough design specifications to work with in every sprint, while maintaining a clear image of the desired outcome.

So how can we meet the fast pace of development sprints while making sure design quality stays high with each new release? By implementing these two fundamental principles in our process:

1. Create and Promote a Design Vision for the Product in Development

We all know the saying, “users are our top priority,” but when it’s time to build the solution, we often find user needs have to take a back seat to development constraints and framework limitations.

Since we cannot satisfy users completely, at least we can serve the business with their demands, right? So as soon as tech limitations kick in, the focus changes to “business needs are our top priority, and user needs are satisfied depending on existing constraints.”

In this situation, the long-term perspective of what needs to be achieved is lost. And what follows is a random selection of tasks from the backlog; tasks that require quick independent design decisions in order to be estimated and queued in the sprint.

A design vision helps in this scenario as the team decides which decisions should be followed through and which should be reassessed, based on the desired outcome.

This outcome, the mental picture of what the design will be like at some point in the future, is at the most basic level, the design vision itself.

When brainstorming what design success looks like, we need to make sure the vision is based on a deep understanding on what’s important to users.

Then we need to make sure we share this vision and promote it at all levels of the team. This will help everybody understand if any new additions or changes in the design will move the product in the right direction or not.

Once this mental check happens often enough, it will slowly transform into a team culture, where the question, “will this help us get closer to our vision?” will always arise when taking design decisions. This is how a team will see if the next steps will take them closer to achieving their end goal or in a totally different direction.

The complementary principle that supports this design vision in its implementation is:

2. Recognize when a Design is Actually Needed

Having a clear vision of what needs to be achieved doesn’t save you from market changes. Users won’t have the patience to wait for months while a company adapts to the new standards. Due to this fast iterative process, quick design decisions will need to be made.

So when the requirements are clear be sure to act quickly; design at a lower fidelity level, but meet the tight release schedules so you can test out the assumptions until it’s too late.

In constantly evolving industries we need to do just enough research to understand the requirements and then design rapidly, based on established design patterns at first.

We don’t need to reinvent the wheel every time, as after the release, testing can confirm or reject the concepts. After testing we’ll be able to make informed decisions on what needs to be refined and adjusted for the next release.

Refine Design Without Losing Sight of the Big Picture

Nowadays, design isn’t just a phase that ends before development starts. Design is interlinked with development and should be constantly refined throughout the process.

The two guiding principles I described above stand to drive the design process on a smoother path and they can help Agile teams be focused on outcomes rather than immediate requirements.

By focusing on the outcome, the bigger picture, team members will develop a sense of ownership and loyalty towards the product they’re building. By knowing what the desired outcome is, we’ll be happier working towards a higher goal. By knowing what the desired outcome is, we’ll be more flexible in adjusting and refining in the short term, to achieve long term success.