Chasing The Ultimate Handoff | ENCTR App With QuestAI

Developer design handoffs are always tricky. There’s a lot that goes into both designing and developing a full featured web application from both design and development. If you’re not careful, some of that design goodness gets lost in translation, and that can lead to frustration and delays.

The ENCTR team was well aware of these issues, and we’ve put a lot of effort into finding solutions and a process that works for us. This is important as a smooth process means less friction translating designs into functional features, and that means more features faster for our users. 

‍

The Issue

The core of the issue stems from the difficulty in turning a static design into a functioning web application. Designers have a serious eye for details, but us developers not so much. 5px and 6px looks roughly the same to me, but to a designer it’s like drawing a huge neon line through their design.

These little inconsistencies build up and ultimately lead to an app that doesn’t look consistent. There are certainly tools to help with this, but many of the existing solutions are slow and clunky to use. 

Design changes are another big issue that are always a headache for developers. Having a designer come to you with new updates everyday can be a huge pain. This pulls us out of our flow and eats up time that could be spent developing features. This is doubly problematic in early stage applications like ENCTR that are constantly changing and being iterated on. It’s impossible to keep up with daily design changes while also trying to build out new features and fix bugs.

There’s also an issue of dev time, building out HTML/CSS is often necessary but not the best use of our time. This is typically fairly low effort in terms of complexity, but nonetheless can be time consuming and needs to get done. Anything that can help us bootstrap some of this boilerplate code is a huge win, and helps us develop faster. 

There are lots of solutions that offer code writing capabilities, (anyone remember dreamweaver?), but these often generate markup that is frankly a mess. This leads to future code that is prone to bugs, hard to maintain, and ultimately slows down long term development. In my opinion, these short term gains are not worth the long term technical debt. 

‍‍

Enter Quest

Overcoming these issues is a big ask, but the team at Enctr has turned to a quest to help us combat them. While no system is going to be 100% perfect, Quest.ai has come pretty close, and it promises to let us develop UI features faster than ever.

Essentially, quest works by both generating UI markup while also respecting the fact that code and design need to iterate quickly. To facilitate this, Quest provides us with 2 UI files, one for presentation and one for functionality.

This allows both design and development to work at the same time without stepping on each other's toes. The presentation file is touched by design only, so they’re able to update and tweak their design without us developers needing to change our code. We simply drop their new design file into our codebase and away we go.

As developers, we get a special ‘hooks’ file that allows us to add all that good functionality. The design defines a button that has some event when it’s clicked, and we spec out that event in our own file. This separates design and development to some degree, which helps facilitate a rapidly changing application.

This is an interesting approach, and one that I personally really like. We can work semi-independently on our own responsibilities, and come together to define the areas where design and functionality interact. 

The code quality Quest outputs is also fairly good. You’re not getting huge blocks of unintelligible markup, but a series of react components. It also integrates well with MUI, our UI framework, so we can reuse things like colors and spacing to ensure consistency across components.

Check out QuestAI here: https://www.quest.ai/

There’s certainly a learning curve, but so far the team has high hopes. We’ve been using Quest for a few weeks, and already have seen some of the benefits in action, and have saved a lot of dev time. This page goes into more detail about Quest to React

‍

Moving Forward

As mentioned above, no system is perfect, and Quest is no exception. There’s certainly still some kinks to work out, but nothing that seems insurmountable.

One point of friction is a sort of inverse thinking that designers need to bring in. Quest necessarily has you spec out things like props and interactions in the design so that it can properly generate the markup to handle them. This means that designers using Quest need to think more fully about all the interactions that a component needs, otherwise developers need to spend time reaching into the design to add them.

I also have a small gripe about the lack of Typescript support. Honestly, I’m not even sure how they would handle that, especially with complex types, but I do miss the safety I get. Luckily, Quest is primarily focused on presentation, so it’s not a huge deal, and we can still integrate TypeScript into our hooks where the bulk of our logic lives. 

There’s been a number of other small issues, but nothing that strikes out as a deal breaker. Quest is a fairly new platform, so some growing pains are to be expected. The brightside is that the Quest team has been super responsive to our issues, and since we’ve started using the system have actually had some of them fixed and new features added. This responsiveness from their end is a huge plus, and gives us confidence that they care about their users and want to support them the best they can. We’ve used Quest so far to build out most of the beta screens and have so far really enjoyed using the system. It’s saved us a lot of dev time, and has helped ease a lot of the friction between handoffs from design to developers. We’re excited to continue using the system, and looking forward to it saving us time and helping us provide more value to our users in less time.