Frontend + Design = Prototype Magic. Pros of Blurring Responsibilities

The topic of whether designers should or should not learn to code isn’t actually anything new. The pursuit of creating the web of tomorrow has led to the blurring of lines between front-end and back-end development where the front-end developer has started to become too general. Ever since the popularisation of the AngularJS framework, JavaScript’s browser-side responsibility has grown furiously. Right now we have so many different and powerful frameworks that it’s hard to pick which one to learn next; we have React, Blaze (for Meteor), Ember.js, Aurelia, and Angular 2.0 waiting just around the corner, just to name a few. And don't forget Vue.js, which is actually my personal pick of the year.

So Why Should We Learn to Design if the JavaScript World Has So Much to Offer?

To answer this question, we need to dive into the world of UI/UX design. Often mistaken as only creative work, designing is not just creating a fancy-pants-user-interface, but rather involves a deep understanding of the client’s and end user’s real needs, and thus the application’s true flow. Creating the UI requires knowledge of how the user will interact with the interface that we provide them. Right now, as more and more JavaScript gets into the browser, the UI has become much more interactive. This gives the designer so much more creative space it’s crazy!

There remains one drawback, however — these solutions are still prone to bad user experience. Problems that often lie in the smallest details, micro-interactions, are very hard to solve using classic designing tools like Sketch or Photoshop. Even with popular online prototyping tools like UXPin or Atomic (which are great design tools altogether), it is hard or almost impossible to actually test-drive more sophisticated ideas. Usually, they only provide us with limited and simple animated mockups with little to no logic; the interactions are often limited to basics like clicks, touch events or swipes.

Additionally, the time and energy needed to create more complicated flows and interactions grows exponentially. If one wants to be very precise over all the possible cases, this gets even worse, up to the point I consider to be counterproductive.

The Prototyping Designer

This is where a prototype designer steps in. This role was covered in a great talk called Like a Pro(totyper): Lean Prototyping for UX Designers by Heather Daggett given at push.conference last year (2015). I find it really inspiring and highly encourage you to watch it! She presented the possibilities that are open to designers the moment that they learn to code (in her company’s case it is HTML+CSS combined with AngularJS and Dynamics.js). Those possibilities are huge! If you are a UX/UI designer, you should consider trying to prototype in code as well. Framer.js might also be handy if you don’t want to go all in.

Sadly for me, this is still not the ideal solution.

The reason? Heather states that the way prototyping designers write the code is totally different than how front-end developers would. This is not production-ready code and this is nothing to blame the designer for — it is the front-end developer’s responsibility to write quality code. They have the required experience and knowledge. This sadly leads to potential duplication of work, which in turn increases the total costs of development. For some companies this might not be a problem, but it’s rarely the case.

What if front-end developers could solve those design problems? I think you already know where this is going. :)

The design oriented front-end developer

Many designers already agree that the most powerful way to design interactions is to actually code them. Why shouldn’t we — the front-end developers — make use of it? We already have all the tools we need! We are the ones responsible for bringing life to designs. This is so much more than just HTML+CSS. Why not embrace the design knowledge, harness the power of JavaScript and make good use of it?

This does’t mean you have to jump in and become a prototype developer right now. Depending on your understanding of the design process, your problem solving skills and the project flow in your company, the place to start can be different.

If you don’t feel competent enough to solve design problems just yet, start with improving your design thinking. Work closer with the designers, help them with your knowledge, be curious and ask questions. Learn from them and let them learn from you. Read more about user interactions and user experience in general. Think about how you can improve the user experience with the technical knowledge that you have already. Remember that User Experience isn’t just what one can see on the screen, but is rather everything that happens in-between. Hence, you don’t have to be a prototype developer to make a difference! In the end this will make for a better application.

However, if you have this certain set of design skills and already work closely with the design team...

The Prototype Developer

Let’s first answer the question: Why should front-end developers do the prototyping and not the designers?

I believe there are some strong arguments in favour of design-oriented front-end developers. First of all, code is our world, this is what we do for a living. We know this stuff - we know the possibilities and the limitations of current technologies. Hence, we can code more demanding prototypes much faster than designers.

Additionally while doing this, we can already estimate the future performance of certain solutions across different platforms and probably even talk with backend developers about certain approaches. There is also quite a high probability that most of the code could be used in production later on, after some polishing of course.

After all, the working prototype is done by a skilled front-end developer who understands when to take shortcuts, while sticking to good practices and keeping the proper code architecture wherever possible. All this gets even easier if we utilise the component-based, view-layer-oriented frameworks of today like Vue.js or React, where the interface logic can be easily separated from the business logic. Creating working prototypes has become faster than ever before.

The Summary

Keep in mind that introducing prototype development in your company might not be easy. As with everything new, you have to prove that it is actually worth the time and money.

To help you with that, here are some of the pros & cons of prototype development:

• Code used in prototypes can serve as a basis for production ready code (the amount of it depends on the shortcuts taken)

  • Example: The mocked data is bound to simple JavaScript objects just for the prototype needs. Switch those objects to some store pattern (like Redux, Vuex, Flux), add some tweaks, refactor and you’re probably ready to connect to an API.

• When the development of the production code starts, you already have the idea of all the different data flows. This means it’s very easy to incorporate the TDD (test-driven development) approach.

  • Example: Your prototype already has the correct component structure, the interactions are clear. It’s very easy to write the required tests before starting to write production-ready code.

• Coded prototypes can be used for usability tests

  • Example: A/B tests for necessary, long and complex forms, where it is important to work with real data.

• You can skip a part of or even the whole static design phase, depending on the developer’s design skills and the application characteristics

  • Example: The designer creates the design language of the project (1–3 example views of the application and some guidelines). The prototype developer can create most the other views afterwards. In need, he will just ask the designer for suggestions.

There are some cons, however:

• Designing views in code usually takes more time than doing the same in i.e. Sketch, especially when starting from scratch.
• Designs done in code tend to be less flexible than graphic designs, especially at the beginning of the project when the design language might change radically.
• Prototypes require more detailed wireframes to work.

How does prototyping look in your company? What more can front-end developers do to improve the user experience?