How we maintain our front-end and design relationships

The line between design and front-end is often one of compromise. The impact of those compromises comes back to how well a designer and the person implementing the design communicate. At Pixel Fusion, we make this line as thin as possible in order to deliver the best version of a product within timelines and budgets.

In a typical product design workflow, a designer might receive a brief, create a design, get it signed off by stakeholders and be finished before an engineer even gets to see it. This can create friction where the engineer simply doesn’t have the resources to implement the design. The designer would then have to come in again and refactor the design, take it back to stakeholders, get it signed off. This process could repeat again and again before a real-world product is possible. This leads to projects getting pushed out by weeks as the design is constantly changed based on what’s possible.

Instead of this, we have a few techniques that help us streamline the process. Before we even get to the design stage, we often have a discovery stage that includes both designers and developers. This is known more commonly as dual-track agile. This way we can identify risks that might appear in the implementation phase and mitigate them earlier.

An example of this was when we had to integrate a payment flow inside an app: Before we started designing it, we chose which payment provider we were going to use based roughly on our expectations. Then we looked at the details of that provider and answered questions such as, “Can we keep a payment open and add items to it?”. We took those learnings and limitations back to the designer and were able to come up with a real-world solution the first time.

Another important thing to consider is that designs can come with bugs as well. We don’t treat the designs as gospel, and if a developer sees a way to simplify a piece of functionality they have the freedom to make that change – with the original designer’s oversight of course. Design is always iterative, and the ablilty to make changes at any stage of delivery helps us on this journey.

We had a modal designed and were busy implementing it when we noticed it had a different style of typography on one page from the next. Instead of blindly implementing this as per the design, the developer put the question to the designer whether this variation offered enough value to justify the increased development time. It turned out this was a simple oversight in the design, and we saved time by simply asking the question.

Creating world-class products is a challenge. There will always be limitations and compromises, but the impacts of those can be lessened by the strategies we use to deliver the best possible version of the product.