What is built is what is real. A design is simply an idea until it can get into the hands of your users. How do you get it built? Who will do it, and what might cause it to change along the way?

Who builds it?

Who will build it is usually predetermined by the project and skills on the team…but not always. If you have some leeway (or interest) to determine who will build it, here’s a few things to consider.

The simplest, most direct arrangement is being able to build it yourself. When you can build it directly there are no meetings, no emails, no delay between what you observe and your ability to act upon it. Even so, there is a cost to choosing to DIY. You may get better results by working with a development partner.

A UI-focused developer – someone dedicated to working on the front end of what your users will see – is a great partner to have. They will be focused on the details of the interface while being attuned to thinking about scalable solutions. They can spot the opportunities for efficiency and reuse that can be the backbone for design patterns.

Sometimes you may find yourself working with engineers that build the whole thing. This can be good for optimizing performance and digging into the capabilities of both the features and the environment they’re in. If there are deep integration points with hardware or graphics, this may be the only way to go. However…this can also be tricky when it comes to getting the UI to the level you seek as each person’s experience (and interest) can vary greatly.

Making sure it can actually get done

No matter who will be building it, there are a few common culprits that can delay or block the UI you want from getting built.

Functional fixes, flow fixes, and cosmetic fixes will all be “bugs” or “enhancements” to prioritize…and they will tend to get prioritized in that order. This is especially true when a team is driven by building additional features. Getting the right thing built takes vigilance in prioritization throughout, from planning through resourcing and validation.

Engineers may be asked for — and held to — schedules that haven’t necessarily accommodating time for finessing the UI. Knowing in advance that there may need to be iteration based on user feedback helps. You can also be an advocate for making that time for them with their manager or the program/project manager. Depending on the project, it may make more sense to do this as pieces are built, or as a sweep after all of the major parts are together.

Sometimes implementation can get delayed if it is an unfamiliar kind of interaction to build. Finding areas in your product (or others) that do something similar can be a good starting point for investigation for how to do it. It’s also worth checking in to understand where the challenges lie. There may be tradeoffs in implementation you can discuss together, and those kinds of discussions are good opportunities to talk about the underlying design logic or aesthetic goals.

Everyone wants a good product, but the idea of what “good” means can vary across a team. Understanding the challenges the people who build your product face – even if you’re the one building it – pave the way to achieving an outcome you can be proud of.