Since the dawn of the digital product design, there’s been a big issue. Designers have been forced to work with software completely separated from the product development process.
Siloed from the rest of the organization, designers draw pictures with their raster graphics or vector design tools. Whether they work in Gimp, Photoshop, Fireworks or Sketch, the process looks identical: The designer renders her intent as a set of static images and sends them to the engineers. Showing different states of the interface with static artboards is very tedious. Thus, designers don’t detail everything. Now, the engineers must build the whole user interface from a set of incomplete, static images. All the interactive states need to be ironed out in an often lengthy back and forth communication.
The results? Tests with users are painfully basic as static designs don’t represent the experience accurately. The process is full of inefficiencies that lead to frustrated teams and unsuccessful products.
Fortunately, there’s a better way to design now. The code–based design tooling paradigm is rapidly replacing image–based design tools. Instead of drawing static representations of designs in a raster or vector design tool, designers can render their design intent directly in code… without knowing how to code. The new set of tools (notably UXPin!) provides a new workflow that:
– establishes a single source of truth for both designers and engineers
– empowers designers with the full power of code without any coding expertise
– connects them both in one collaborative, creative process.
It’s a workflow revolution, if you may. Speaking of, sign up for our upcoming webinar on the 25th of October to learn more about code-based design.
What’s wrong with image-based design?
As you know, there are two paradigms of design tooling: image–based and code–based design tools.
The image–based paradigm is an old design tool approach used for many decades (most notably – Photoshop originally launched in 1988). The idea is that when designers draw something, they build raster or vector graphics. This approach allows for the most flexibility. Everything can be effectively drawn this way – from icons to advanced illustrations with the most beautiful level of details. However, it often breaks in professional digital product development. Here’s why:
- Lack of interoperability: These graphics are never used to build the actual interface of a product, except illustrations, icons and photographs. Designers working on interface design in image–based design tools work outside of the constraints set up in code and therefore, unknowingly, can create things that are difficult and expensive to code.
- Lack of accuracy: While they can create wonderfully detailed designs, image–based tools also lead to the most inaccurate results during the development process. They use completely different methods for rendering the result of the designers’ work. Therefore, text, gradients and colors chosen by a designer in their image–based tool looks different in code when an engineer applies the same specs. This causes massive misalignment between the teams. Check out this example. And this hilarious tweet that nails it.
- Static designs: Image–based design tool workflow focuses on building static artboards for every state of the interface and then linking them together. This approach breaks in professional projects. Even simple patterns (e.g. a dropdown) quickly become unmanageable in the static workflow. Why? Due to a large amount of artboards and lack of ability to save interactive components for reusability. Moreover, these tools allow only very basic interactions without the ability to set states of elements, variables for content, conditional logic, etc.
- Weak design–engineering collaboration: These tools are completely separate from the engineering processes and cannot be merged efficiently. The disconnect is in the very nature of the output of both worlds. While developers work in technologies actually experienced by users as the final product, users of image–based design tools introduce additional layers of abstraction which remain far off from the final user experience. Lack of real interactions, reusable interactive components, or the ability to import components from code keeps engineers and designers disconnected and frustrated with one another.
What’s so special about code-based design?
Glad you asked. With code–based design tools, when a user draws something, the tool creates relevant html/css/js and engages the browser, rendering the engine to show the result visually. It offers the most realistic fidelity (the same technologies are used by designers and developers), the most powerful interactions and the closest collaboration with engineers. There are many benefits for all parties involved, but today, let’s focus solely on designers:
Benefits for designers
- The most realistic fidelity: Unlike image–based tools, the code–based approach provides 100% match between the intent of a designer and a code–able result. That’s because code–based tools use the same technology as those used in web development to render all of the design project! If you can make it in UXPin, you can definitely make it code!
- The same constraints for designers and developers: With image–based tools, designers can create things that are difficult, even impossible to recreate in code. On the other hand, code–based tools allow for the exact same constraints for designers and developers (limits of the code!). This ensures they can truly stay synced.
- Interactive components instead of artboards: Code-based design tools use the most advanced interactions on the components level, instead of link artboards. This approach mimics development and empowers designers to create highly reusable interactive design systems.
- The most powerful, realistic interactions: Objects can move on the screen, interact with each other and create complex patterns. Just like in code, but without a need to know how to code. This is crucial for the collaboration with engineers (to actually experience the product before coding the final version) and for tests with users. Elements that are natural in the code–based paradigm, like real text inputs or checkboxes, don’t exist in image–based tools!
- The strongest collaboration between designers and engineers: The code–based paradigm enables a completely new, revolutionary approach to the design and engineering collaboration.
And that’s just the designers’ side of things. Stay tuned for another article about the benefits of code-based design for both your company’s engineers and your entire organization.
Craving more? Attend our live webinar ‘Code-Based Design: The Workflow Revolution on October 25th. We’ll even show you new technology that will revolutionize code-based design forever.