Developing a Feel for Complexity in Features

Ryan Hinojosa

Sep 15, 2017 • 3 min read

Design is all about understanding other’s perspectives and using that knowledge to come up with a solution for a given problem. We may focus on the user, spending time immersed in their environment to better understand their problems and motivations. We may also keep business objectives in mind, crafting solutions to improve outcomes. But in practice, I’ve noticed that often in software projects, a development’s perspective isn’t brought into the process until much later.

This is unfortunate because development constraints can have a large impact on the end-user experience. We can design solutions that may work well in a prototype with limited or mocked data, but crumble in real-world scenarios when it comes to performance. We can also create solutions that may take a very high level of developer effort, forcing us to make trade-offs on other necessary features or initiatives.

I would like to argue that designers should better understand development’s perspective not to replace their voice in the room, but to increase collaboration between the different disciplines. We can treat development as another persona for research so that we can understand their problems and challenges just as well as we understand our users. This understanding can help designers predict potential landmines in designs ahead of time and better understand potential tradeoffs among different solutions.

Involve Developers Upfront in Product Discovery

Developers should be part of the design and user research process from the very beginning. What’s worked well for us in the past is to have 1 or 2 development representatives involved in research sessions or early design concept reviews. Depending on the nature of the design work, either front-end or back-end or both should be involved.

Naturally, time spent doing this type of upfront consulting work is less time spent doing actual development work so you’ll have to consider this tradeoff on current priorities. Be mindful with how much time and effort you'll require. Make sure that any reserved time for these developer engagements are reflected in sprint commitments so that you’re not overburdening your colleagues with work.

Even though this requires some upfront time, getting developers involved early has been easily justified by our agile teams because of the overall improvement in product decisions and decreased time-to-market by being smart about our approach.

Learn (Some) Code

Depending on your role and the size of your team, you probably don’t need to be able to write production-ready code. But having at least some experience with writing both front and back-end code will it make it much easier to communicate with developers. You’ll have more empathy for the challenges developers go through when implementing a design.

Use a couple of hours here and there to pick up a new and valuable skill. Consider it as user research for the developer persona. Becoming a developer requires a large and sustained investment in time. But becoming a “tinkerer” can be done with the occasional afternoon project.

Actively Participate in Estimation Sessions

As part of the backlog grooming process, developers give a general sense of the level of effort for each item and if it's necessary to break down a feature into smaller stories. These sessions help product management prioritize upcoming work on the backlog.

At Atlassian and other companies, it’s common for these sessions to use a method called Planning Poker. First, the story is briefly discussed, and then each participant assigns their own level of complexity in secret, and then finally everybody’s results are revealed at once. If estimates are in consensus, then that estimate is added to the ticket. If they’re off, outliers (both low and high) will explain why they chose their score to establish a new consensus.

One approach that’s been effective for me, is to actively participate in estimation sessions. Yes, you’ll often be completely wrong at the beginning, but by having at least a little skin in the game, your estimates will start to come into line more and more frequently.

Developers are Stakeholders

Designers need to recognize developers as major stakeholders in our design projects. If we spend time better understanding and considering their perspective, we can improve the end-result of many of our software projects. By developing your own feel for complexity, these discussions can become more collaborative and productive.