The Days of Old
Pixel perfect mockups or designs (created in Photoshop). Those designs handed off to a developer to be carefully examined and converted to semantic code to build a functional website, an app, or a digital product. Each measurement scrutinized and questioned in order to match up the static visual during the conversion process.
The developer had to recreate what the designer created from the ground up. What a waste of time and billable hours to the client. The static design comps lacked the definition and specifications for user interactions as well; often leaving the developer to do guesswork. The pixels, raster-format, made it difficult for graphics to be extracted and re-scaled for hi-dpi / retina ready screens without the quality suffering.
Fortunately, we have moved on from these practices but are still faced with challenges regarding the pain points of today.
How to Mitigate Handoff Pain Points
Frequently there is a disconnect during the handoff process and communication breakdowns. For the handoff process to be more successful the designer and developer need to be interested and respectful of each other’s craft so they can speak the same language. The two come from very different backgrounds; different disciplines where . . .
The designer is concerned with the creative and:
- visual design, user interface (UI) & layout, e.g. – the ‘look & feel’
- consistent design pattern & styles for unity
- color palette, contrast, shapes, textures, typography and graphical assets
- user experience (UX) / customer journey & flow, which includes user interactions
- the text, copy, messaging or content working harmoniously with visuals
- content organization, hierarchy, information architecture
- accessibility
- think: frontend
The developer / programmer with logic and:
- functionality
- server-side coding / programming and database
- usability, load time
- QA (quality assurance) / testing and debugging
- security aspects
- keeping abreast of new languages and technologies and adapting quickly
- think: backend
Wireframing, Layouts, Page Schematics, Mockups, Prototypes, Screens
Call it what you want, as my heading above suggests. Nowadays we have simple vector-based UI (user interface) applications where we can design and simulate the UX (user experience). The designer can experiment with creating low fidelity prototypes, rapidly, to get user feedback and stakeholder buy-in early on in the process. The designer can further push and polish for a high-fidelity effect if needed. Popular wireframing and prototyping software examples are Figma, Sketch, XD, Balsamiq, Axure, Avocode, etc.
These applications bring us a step closer to a final working digital product. Most still fall short in that they do not auto-write the code for the handoff process, leaving us right where we started in this blog post: the developer having to translate the design to code from the ground up. Complex and time consuming. For those apps that do auto-write code, the developer can reference each component or symbol on the artboard.
Where else do these applications fall short? The designer will still need to manually create responsive layouts for the three key breakpoints (desktop, tablet, smartphone).
I still take issue with such resources as they are not a one-stop solution and they do not necessarily globally reflect what needs to occur in the live development space. A lot of reconstruction, cleanup and code-writing will still be required. To have to communicate details by way of directions to a developer is a pitfall.
What Else Can We Do?
As a designer, you can push this process further by coming to grips with a frontend framework in which to translate your designs responsively (responsive web design). Bootstrap is the definitive choice and has been for years. It would behoove you to learn HTML, CSS and some JavaScript in order to get comfortable using Bootstrap and working with media queries for the various viewports (different screen sizes that target desktop, tablet and mobile phone).
By doing so you’ll have completed a large chunk of your project ‘solo’, sans a developer – depending on the size, scope and technical requirements of the project. You become the frontend designer / developer. How cool is that?
This single line of code makes any site responsive:
<meta name="viewport" content="width=device-width, initial-scale=1">Yep, that’s all it takes!
You’ll have a better understanding of limitations, constraints and the level of effort involved. Recreating elements that may have taken approximately 45 minutes to achieve in static design layout may take 2 hours to code out in a dynamic, responsive environment. As a result, this may change your design thinking at the start of the project.
How Low Can You Go?
In this case, “low” relative to the frontend development stack. I’m talking about React (JavaScript) or Flutter (Dart). Some developers view the designer learning such languages as a boon.
According to Scott Tompkins, Principal Software Engineer, “For a premium frontend web developer this is the expectation. A reasonable comfort level with technology, React and Angular . . . aspiring designers who want to bring value to a software development team: get comfortable with React.”
Web developer Stephan Snoek states, “With regards to the design handoff and the overall development process we have moved towards a component based approach and are using things like Storybook. It is not realistic to expect the designs or even the initial prototypes to correctly depict the final result. Content evolves up until the last moment and even after launch, of course, as we want to end up with websites that can adapt to the ever-changing business needs.
With the evolving content and functional needs comes a need for flexibility as often elements get moved around or need to be combined in ways that may have not been foreseen during the design phase.
So, this is why we try to translate these design elements into reusable and flexible components that can then easily be used in any configuration or layout the client may need.
The ability to design and build in this way also opens doors to better automated testing as components can be tested in isolation and outside of the actual implementation which makes it easier to test edge cases for example.”
I have heard over and over that the designer does not want to become the programmer / developer.
“If this area does not make you happy, go down / continue down the path of UX / UI. A whole realm that is its own field . . . The transition between the ugly backend of technology that nobody wants to concern themselves with, and something that’s approachable to a human is something of immeasurable value”, Scott also commented.
In the dev phase the designer ultimately wants design precision: control over tweaking the layout / positioning, typography, the styling and the interactions / transitions of placed elements – all in the name of creating the perfect user experience – one that will ultimately convert.
Have You Heard About the No Code Revolution?
Another alternative? Introducing: the ‘no code’ revolution. Have you heard of it?
Designers are seriously excited about this opportunity: visual page builders. Visual page builders have evolved and come a long way and everyone’s jumping on the bandwagon. You may have heard of a few: Webflow, Elementor, Divi, Visual Composer, Beaver Builder, etc.
Imagine, designing with visual tools that include components and symbols for the web along with all the interactions – directly in the web space, responsively. Like, on the server. No code knowledge required. A purely visual experience similar to working in native graphic design apps.
This might be every designer’s dream to bridge the gap and nail down the handoff process once and for all.
The design process is expedited, and the code written is semantic and compliant (depending on the builder!). Again, let me just reiterate it automatically writes the code and that code is accessible to the developer.
The product to handoff to the developer for fine tuning, or extensive backend related work is complete and production ready. Virtually, a finished product that you can constantly view and check in the browser and on various screens / devices and tweak till your heart’s content.
On a Positive, Constructive Note
The no code revolution has opened doors for many visionaries, entrepreneurs, startups (think MVP) and people with ideas that just want to push content out themselves – without having to have in-depth conversations and pay hefty fees to a designer or a developer. Your local bagel shop . . . that hairstylist round the corner . . . you get the point.
It makes the web belong to everyone to author and shape. Isn’t that the way it’s supposed to be?
Utilizing page building tools for proof of concepts can be quite good for overcoming challenges in getting stakeholder buy-in for investment heavy projects. Once management is convinced, the correct resources can be poured into the full build.
Beware / Caveats
On a grander scale there are obvious limitations and professional drawbacks with this model of reliance on visual page builders. The role of the developer is not doomed by any means whatsoever!
Recognize that ‘no code’ solutions may not be applicable in all circumstances. Robust, enterprise-level web services come at a premium price. Those services, features, workflows, task handlers, builds, are most often not part of the working palette of visual page builder tools.
Code Bloat
Unfortunately, many of the visual page builder tools cause code bloat which leads to poor loading performance on the web. This is especially true if someone using such tools has no code experience to consolidate and write the most common global style rules and variables up front from which to refer back to and apply sitewide. (Styling is a practice that’s imperative to a company’s or product’s branding.)
A bad case of “classitis” and “divitis” is served up and guaranteed to slow page loading speed. The page structure may also be compromised. There’s a lack of standardization and optimization.
The same component dragged onto the page multiple times writes that chunk of code – multiple times, under a different class. Though admittedly, more experienced page builders create libraries or reusable blocks to eliminate code redundancies. You can read about the DRY (Don’t Repeat Yourself) principle.
Accessibility
Accessibility issues may also be at play, and if your site is not ADA compliant you may endure legal fees.
Wrap Up
We need a creative workflow to reduce unnecessary steps, save time and create better products.
In an effort to improve communication, much of what I am suggesting is a shared goal amongst designers and developers alike. I hope you’ll take a moment to re-examine your process and try one of the suggested methods above if you have not yet done so.
There is plenty more work to be done. How is your team collaborating to bridge the design handoff process?
