Last updated at Thu, 31 Aug 2017 14:16:38 GMT

In most organizations today, building widgets is a separate process from designing widgets. Designers sit over here. Developers sit over there. Designers come up with ‘ideas' and then throw them over the wall to the Developers sitting on the other side. The Developers build what they think the Designers wanted and then deliver that back for Design approval. Nine times out of ten, Design is surprised to see something that only loosely resembles their original idea.

image credit: Adham Dannaway

Why is that? Well, the goals of the Design team are different from the goals of the Development team. Designers are focused on shaping user experience and how something looks and feels while the Developers are focused on how something works. They aren't mutually exclusive, but they can easily become that way when the two groups are separated. Of course, this example is grossly over simplified, but if you're a designer or a developer I guarantee that you nodded your head at some point while reading that description. This conundrum is something we've all seen before.

What about UX Engineering?

What if the Developer sat right next to the Designer? What if they were both focused on how the widget looked and how the widget worked? What if the Developer was building the ideas the Designer was coming up with almost in real time!? Designers could see right away if the widget's double checkbox solution wasn't understood by the end user. Designers could pivot much earlier in the process and come up with improvements that the Developers could layer on top of the existing code. After several iterations, once both the Designer and the Developer were satisfied with the experience the widget offered, they could show it around for feedback. Heck, the widget is nearly complete at this point. They could even offer it directly to their customers for real-world experiences and real-world feedback.

image credit:

It's the act of building the experiences that validates the designs that birthed them. Once a design is ‘living' in it's intended environment, be that a browser, mobile app or desktop app, the decision of whether or not the design solved the problem at hand becomes evident. It's difficult, if not impossible, to judge that when the design is static. That's why we need to push to have designs built as far up in the development chain as possible. Integrating design and development and creating a UX Engineering group goes a long way towards solving these problems.

This is where we're headed at Rapid7. The UX organization has begun the push by bringing development expertise into our organization and the pay off's are clear. We're building prototypes and proof-of-concepts that are helping us thoroughly think through all sorts of topics; responsive grid layouts, responsive sizing breakpoints and adaptive tables just to name a few. It's through these ‘living' examples that we're able to see the repercussions of our decisions without effecting the flow of business. No time was lost attempting to build out the solution within our application. By validating our designs offline first, we bring even greater value to the company by increasing throughput and efficiency further down the line.

Design improves; Development improves; Business improves. It's a win-win for everyone.

Let us know how you feel about bringing Design and Development together in the comments below. We'd love to hear from you!