Whether creating a web page, Android app, or iOS app, most traditional designers start their work by creating static images with tools like Adobe XD, Figma, or even Photoshop. The designs might look aesthetically pleasing but they are not even close to being ready to be converted into code.

After the designing phase, designers need to add interactions that will show developers and testers how UI elements correspond with one another, what affordances they need to account for, and any other animations that will be present in the end-result. Then, designers pass those prototypes to developers who turn designs into code, and the circle of back and forth commentaries begins.

It’s time to move beyond this tedious process by taking a code-based approach to design. Once you think about the waste of time of animating or annotating vector-based design to communicate interactions, it quickly becomes obvious that your design team needs a better way to create products that users will love. 

Bridge the gap between design and code once and for all with UXPin Merge. Bring your coded design system to UXPin’s design editor for hi-fi prototyping and quality usability testing. Discover UXPin Merge.

Reach a new level of prototyping

Design with interactive components coming from your team’s design system.

Discover UXPin Merge

What is design to code?

Design to code is the process of translating a design mockup or prototype to code that can be implemented by developers to create functional user interfaces. This process involves converting graphical elements, layout structures, interaction designs, and other visual components into HTML, CSS, and possibly JavaScript code that can be interpreted by web browsers or other platforms.

Design to code is a crucial step in the product development as it means going from a concept of a product to an end-result. It ensures that the visual and interactive aspects of a product or application are accurately represented in the final implementation. This process often involves collaboration between designers and developers to ensure that the design intent is preserved while addressing technical constraints and requirements.

Challenges of converting design to code

Design-to-code approach creates more steps than you need to create a popular digital product. The process of turning prototype to code probably affects this areas:

• Ideation and Product Development – Coming up with ideas to be turned into products or features.
• Design Conceptualization – Communicating ideas to the design team.
• Design Review and Feedback – Reviewing the work of the design team and giving some feedback.
• Tool Limitations – Designers struggling with the limited possibilities of adding advanced interactions in their design tool. 
• Communication – A lot of back-and-forth in the designer-dev communication, trying to smoothen some prototype inconsistencies.
• Iterative Refinement – Adding some tweaks until the product fulfills the original vision.

These steps can take weeks or months to complete. Even when you use a tool like Avocode and Anima to turn PSD, Figma, and others that turn designs into code, you still need relentless prototype and product testing to ensure that all interactions work as they were designed. 

You still need to deal with unnecessary steps because Avocode and Anima can only convert designs into code. They do not offer a designing environment that can use code to design a UI. 

Design to code wastes time and money

Not surprisingly, the serpentine process of passing work between product managers, designers, and developers quickly becomes expensive. In the United States, website developers with associate’s degrees can expect to earn about $35.46 per hour (€ 29.5). The longer development and prototyping take, the more it costs to bring the product to market.

Without code-based design, though, the process will always involve backtracking and repeating steps. It’s clear that the design to code handoff process wastes time and money.

Popular website designer Matthew Strom found that he could streamline his process by designing with code instead of starting with static images. While building a new homepage for WSJ. Magazine, he found that working with code was often more straightforward and rewarding than taking a vector-first approach. He discovered that the old process became sluggish as he created more images.

Thankfully, Strom knows enough code to build a complicated homepage without relying on design tools for every step. Unfortunately, few designers have the experience to create digital products from code.

Prototyping suffers with design to code

You can improve the design to development process slightly by encouraging your designers to learn basic code. Knowing the fundamentals of HTML and CSS gives designers a shared understanding that helps them anticipate the needs of developers.

It makes the process even better when designers know some front-end JavaScript and Ajax because it gives them insight into how much work it will take developers to turn their static designs into interactive components.

Some coding experience also helps designers understand the limitations of development. It can make a huge difference when graphic designers have a baseline understanding of what developers can and cannot do.

However, the code-to-design approach doesn’t mean that a designer must know all of that. It’s enough to sync developers’ repo where they store UI code components with the design tool editor to empower designers to use the production-ready parts in their designs. Not only is it faster but also much more consistent with the design standards. Thanks to this, you can avoid all the reviewing and repetition stages in the whole product development process. 

Without a code-based approach to design, you end up with prototypes that don’t function as anticipated, which inevitably means you end up wasting even more resources. 

Make designing and prototyping easier with a design tool based on code generation

A tool that enables having your UI code components imported to a design library is much more efficient than the one that converts an image to code.

UXPin Merge bridges the gap between the process of translating prototype to code. Teams use the same UI elements throughout their processes, both to design a product and to develop it. Thus, there’s no misalignment, duplicated work, and misunderstandings. Teams can ship products faster and with ease. 

Improve workflow with code components

Instead of interpreting image-based designs and turning the ideas into code, developers just take the components that were used in a design from their library to build ready products. 

As the code-powered prototypes already behave like a final product, there’s no need for additional reviewing steps – the result of developers’ work will be pixel-perfect to the designers’ work. 

Recommended reading: You Can Become a Code-Based Designer Without Learning Code.

Test user interfaces and interactive design elements with fully functional prototypes

You need to meet the project manager’s specifications before you embark on turning a prototype into a product you can release.

UXPin Merge gives your team members an opportunity to test the functionality of interactive components before committing to a development process.

With UXPin Merge, though, it’s often difficult to tell the difference between the prototype and the finalized product. That’s how strong initial testing becomes when you build digital products with code and use real data to test interactions.

Request access to UXPin Merge for code-based designing and prototyping

You don’t have to continue the tedious process of building products from a design-first perspective. Shorten your go-to-market process, improve collaboration between departments, and take control of your designs with UXPin Merge. Now, you can test building UI with UXPin Merge by using built-in Merge libraries. Try UXPin Merge for free.

The post Want to Convert Design To Code? Here’s A Better Way appeared first on Studio by UXPin.

Storybook has become THE DevOps tool for developing and maintaining design systems. The platform’s excellent documentation, intuitive UI, built-in testing, and collaborative features make it the perfect tool for building and releasing components.

Understanding how Storybook works can help designers collaborate with front-end devs better and leverage the platform’s features to improve prototyping and testing.

One of Storybooks best features for design teams is its ability to sync a component library with UXPin using Merge technology. Merge creates a drag-and-drop design environment for assembling layouts fast. Discover UXPin Merge.

Design UI with code-backed components.

Use the same components in design as in development. Keep UI consistency at scale.

Try UXPin Merge

Why Devs use Storybook for Design Systems

These are a few reasons why Storybook is the preferred DevOps tool for managing design systems.

Developing and testing components in isolation

Storybook enables engineers to develop UI components in isolation. This development workflow is great for design systems and component-driven front-end frameworks like React–which many organizations use for their component libraries.

Before Storybook, engineers would use sandbox platforms like CodePen and CodeSandbox to build and test components in isolation. Storybook offers this sandbox-style development environment with an intuitive user interface for engineers and stakeholders to view, test, and approve UI elements. They can also combine components and build little prototype patterns for testing.

Quality Assurance

Developing in isolation also benefits design system quality assurance. Engineers can invite designers, product managers, and other stakeholders to test and submit feedback on new UI elements before release.

Documentation

Documentation is crucial for component libraries, but it’s often the last thing anyone wants to think about because it’s time-consuming.

Storybook’s DocsPage is a “zero-config default documentation” that automates basic doc creation. Product and engineering teams can expand this documentation to create usage and guideline information.

Single source of truth

Managing the codebase for cross-platform applications is challenging. Storybook provides a single source of truth for testing components and patterns for each platform from a centralized environment.

This centralized environment maximizes consistency, as engineers can view components and patterns side-by-side and collaborate with developers responsible for each platform–iOS, Web, Android, etc.

Accessibility

Storybook’s A11y Accessibility add-on enables engineers to automate accessibility testing. The add-on creates a new Accessibility tab for each element showing WCAG standards in three categories:

• Violations: accessibility issues to resolve
• Passed: standards met
• Incomplete: A checklist of accessibility to-dos

How Devs Work With a Design System in Storybook

Storybook’s docs outline a standard five-step design system workflow:

1. Build
2. Document
3. Review
4. Test
5. Distribute

Build

Once engineers have set up Storybook and connected to a GitHub repository, they begin developing each component and its variants. For example, a button might have several states, sizes, types, etc.

During the build process, engineers can install Storybook add-ons to automate workflows, integrate with other tools, or enhance the Storybook environment.

Document

Engineers can add comments to components during the build process to enrich the automatically generated documentation. This example from Storybook’s docs demonstrates how these comments appear in your Storybook UI.

This documentation is crucial for the next step, Review, because it shows stakeholders how front-end developers interpret designs and what each ‘prop’ represents.

Review

The component is now staged and ready to be promoted to the design system. Engineers can invite designers, product managers, and other stakeholders to review the element to ensure it meets interactive and aesthetic expectations.

Traditionally, engineers would have to create a staging environment or meet with stakeholders to present the component. With Storybook, it’s as easy as visiting a website, making the review process more accessible. Stakeholders can log in on their own time, interact with the component, read the docs, and leave feedback.

If there are any changes, engineers may iterate steps one to three until the new components meet all stakeholder’s expectations.

Test

Jest and Playwright power Storybook’s framework-agnostic testing. When engineers commit the component, Storybook tests its code to ensure there are no programming errors, including:

• Visual tests (visual regression tests): creates screenshots of every commit and compares them to catch UI inconsistencies.
• Accessibility tests: runs code against WCAG standards and reports any issues.
• Interaction tests: checks interactivity and states to ensure there are issues with links or functionality.
• Test coverage: examines code against industry standards, including conditions, logic branches, functions, and variables.
• Snapshot tests: identifies markup changes by comparing rendered code to the baseline.

Distribute

The final step is to update the design system package on GitHub. Once complete, it’ll automatically sync the changes to npm. Engineers can install the updated npm package to use the new component(s).

Syncing Design With Storybook Through UXPin Merge

If your design team works with UXPin Merge, these engineering changes will also be distributed to UXPin’s design editor and notify team members of the latest design system release.

UXPin’s Version Control allows designers to change to the latest release whenever they choose and switch to earlier versions of the design system.

What is UXPin Merge?

UXPin Merge is a technology that bridges (or Merges) the gap between design and development. Organizations can sync a design system hosted in a repository to UXPin’s design editor so designers can use the same component library as engineers to build fully functioning prototypes.

Merge components are fully interactive and include React props (or Args for Storybook) defined by the design system, including colors, typography, states, sizes, etc. These props appear in UXPin’s Properties Panel so designers can adjust components to meet prototyping requirements while maintaining absolute consistency and zero drift.

Enhanced testing and stakeholder feedback

Merge prototypes look and function like the final product because they use the same components. For example, a button in Storybook will render exactly the same in UXPin, including interactivity and styling. 

Usability participants and stakeholders can interact with these UI elements and Merge prototypes like they would the final product, giving design teams accurate, actionable testing insights.

“It’s been so helpful for us to have these high-fidelity prototypes built with UXPin. We build high-fidelity prototypes much quicker, and we get immediate feedback after the session. If there’s something we can fix immediately, we make that change before the next participant and get feedback much faster than before.” Erica Rider – UX Lead EPX at PayPal, talking about how UXPin Merge enhances user testing.

Scaling component libraries with UXPin Patterns

Design systems evolve as products grow and scale. The design system team is constantly making changes and promoting new UI elements and patterns.

UXPin Patterns enables design teams to create new patterns for the design system–as one-offs or as a best new practice. Designers can combine UI elements (atoms and molecules) from the design system to create new patterns or use UXPin’s npm integration to import components from open-source libraries if the current library doesn’t support their needs.

Designers can save and share these patterns across the organization, so teams can continue prototyping while they wait for the DS team to follow governance procedures to develop and release the new component–following the five-step Storybook development process outlined above.

Stage four design system maturity with UXPin Merge

Iress achieved stage three design system maturity in 2017. For the next few years, the design system team searched for a design tool to take them to the next and final maturity level–Stage Four – Fully Integrated:

• Design in (no) code
• No design drift
• Consistent design
• Seamless (no) handoff

Merge solves these four design system challenges by default.

• Designers use ready-made components with styling and interactive properties–no designing from scratch. Drag and drop UI elements to design new products.
• No code development. Engineers install a package and copy prototypes that use the exact same UI library. UXPin renders JSX for each component, so engineers copy/paste to apply styling and interactivity.
• Drift is nonexistent when everyone uses the same component library (design and engineering teams) with the same constraints.
• Using the same components with built-in constraints ensures ultimate consistency across design teams.
• With Merge, there’s a seamless handoff because designers and engineers use the same single source of truth. Designers don’t have to explain UIs or provide endless documentation explaining their prototypes–they already look and function like the final product.

UXPin reduces the four stages of design system maturity to just two.

1. Design your library using UXPin’s design editor.
2. Convert designs to code components, add them to a repository, and sync back to UXPin using Merge. Iterate to scale.

Take your product development to the next level by Merging the two best design and engineering tools for design systems. Request access to UXPin Merge.

The post How Storybook Helps Developers With Design Systems? appeared first on Studio by UXPin.

If you are close or are finishing up your design after a series of iterations, then you are probably anticipating the next step—the design handoff. There are many ways to unsuccessfully pass along your designs to the development team.

To help ease your mind and make this process easier, we have compiled a list that will help you thoroughly prepare for a design handoff. All so you can avoid any misunderstandings between you and the developers.

Design prototypes with a single source of truth between design and engineering. Bring interactive components to UXPin and reduce the friction during the design handover. Visit our UXPin Merge page.

Reach a new level of prototyping

Design with interactive components coming from your team’s design system.

Discover UXPin Merge

6 Designer’s Tasks for Smooth Design Handoff

Standardize naming conventions

Using appropriate and coherent terms will ensure that there is no confusion between you and the developer. For example, instead of naming stages of your product with “Latest” or “Newest,” it is best to keep it simple and use, for example, “v1,” “v2,” “v3,” and so on. 

This will make it easy to see the various versions of your design from the original to the latest and will help the developer navigate your design process. You’ll also want to familiarize yourself with developer handoff terms. A good resource for this is the BEM notation guide.

Read more about terminology in our Content Design System Guide.

Build interactive prototypes

Even the most beautiful prototype fails to communicate what developers need to build if it’s static. That’s why adding interactivity to your design is so crucial. You can do that by using advanced prototyping features like States, Variables, and Expressions.

There’s also another way. You can bring coded components to design and build prototypes that are fully interactive by default. Read more about it in our previous article: What is component-driven prototyping?

Annotate and explain your design decisions

Since you will be handing off multiple digital assets and designs to the developer, it is important to build a habit of annotating them. This will give the developer context of what each asset is. You should also explain each design and why you created it in the way you did.

Using a design handoff tool like UXPin will make this annotation process a lot easier. It will allow you to collaborate on your designs in real time and create contextual documentation.

You can add detailed descriptions of each element in your design which will help clarify the function each of them offers. There is also an option to include accessibility guidance for greater clarity.

Create templates or checklists for the future

For the most part, every design handoff process will involve similar structure. So, to make it easier for future design handoffs, it is best to create a template or a checklist that will help you make the process more efficient. This will ensure uniformity and a seamless transition from designer to developer.

It will also save you a lot of time because you will already have a good process to follow and won’t have to reinvent the wheel every time you have a design handoff.

Prepare specification

Specifications help developers understand CSS properties, be it heights, widths, spacing, font sizes, etc. Design tools usually automate this process. UXPin, for example, have a built-in Spec Mode that helps developers select UI elements to view specifications.

UXPin also automatically generates starter CSS that developers can copy. And when you’re designing prototypes with interactive components, your devs can copy the code behind those components into their workflow. Read more about how UXPin Merge technology simplifies design handoff.

Improve cross-team communication 

Smooth communication is important for any project – and the design handoff process is no exception. That’s why it’s important to bring the developer into the design process at an early stage. This way, you’ll have more time to introduce and explain all of your designs and ideas. 

This will be beneficial not only for the development team but also for you as a designer. Namely, you’ll be able to take advantage of their technical expertise by asking them for feedback during the design process.

By keeping an open dialogue, you can discuss with them which design components are working well and what needs improving. You’ll also be able to understand how you can implement positive changes to your design.

To summarize, good communication will:

• Give the developers context and background knowledge of the design
• Create a faster and more efficient design handoff process
• Keep the developer on the same page, which will ultimately result in faster and more accurate development of the design
• Avoid misunderstandings related to the design handoff.

As you can see, involving developers early in the design handoff is one of the best things you can do in the product development process. We discuss it in more detail in the next section.

Involve developers early in design

Oftentimes, design teams make the mistake of separating their work from the developer’s work. As a result, there can be a lot of confusion during and after the design handoff. This can lead to faulty development and more time that you’ll have to spend clearing up any misunderstandings.

So, in order to create a streamlined process, versus a fragmented one, you’ll want to include the development team early on. To accomplish this, there are three main steps you should follow:

• Seek insight from developers—During the design process, it is always important to at least have some idea of how your design will translate to an actual website or app. So, in order to make design handoff smoother, it is important to seek insight and advice from developers early on.
• Include developers in talks with stakeholders—Ultimately, the stakeholder is not looking for a well-designed prototype but for a good product. So, by including developers in conference calls or talks early in the design process, you can ensure that both the design team and development team have a sense of clarity. Hence, they’ll have a good understanding of what the end result should look like.
• Sharing design ideas with developers—It is a lot easier to correct any potential problems with a design while they are still in the “ideation phase” instead of the prototyping phase. So, before carrying out any major design ideas, it is best to check in with developers to see if what you want to build is feasible.

Improve Design Handoff with UXPin

All in all, communication is key. Instead of seeing the design and development teams as separate, it is best to see them as one. So, involving the development team in the design process and making sure everyone is on the same page will help create a seamless design handoff.

In practice, using a tool like UXPin will allow you to create prototypes with components that come from your design system. This will make it very clear to developers how each component is meant to function and create a seamless transition process. 

Bring components from Git repo, Storybook, npm to UXPin and streamline your design handoff process. Learn more about it.

The post What Designers Can Do to Ensure a Smooth Design Handoff appeared first on Studio by UXPin.

Design handoffs are a tense time. Designers and engineers speak separate languages and work within different constraints, making communication and collaboration challenging.

The first step to bridging this gap is defining what engineers need for development. Communicating these needs at the start of the design process will help designers prepare accordingly and streamline the design handoff process.

We’ve included a list of what engineers need from designers at handoff, what they don’t need, and how to optimize your handovers using sophisticated tools.

One of such tools is UXPin Merge. It enables you to design prototypes with a single source of truth between design and engineering, that is interactive components. Designers can bring their app’s UI elements to UXPin, and share them with devs for easier design handover. Create seamless design handoffs with the world’s most advanced design tool. Visit our UXPin Merge page.

Reach a new level of prototyping

Design with interactive components coming from your team’s design system.

Discover UXPin Merge

A Design Handoff From a Developer’s Perspective

We’ve talked a lot about designer/developer collaboration and creating better design handoff processes. The key takeaway is designers and engineers must start handoffs early in the design process.

Engineers must provide a list to designers of the files, documentation, assets, and specs they need to develop the final product. The teams must also decide on a file structure and naming convention to make everything easy to locate.

Defining technical and developer needs at the start of a project enables design teams to set up tools, workflows, and infrastructure (files, project management software, etc.) to support a streamlined handoff process.

What do Developers Need From Designers?

Create a design system (even if your product doesn’t use one)

Many engineers build components in isolation and pull them into project files for front-end development–especially with component-based front-end frameworks like React. Creating a design system or style guide for your projects will help facilitate this workflow, making it easy to develop the final product.

Most design tools require additional plugins or extensions, but UXPin offers its Design Systems feature standard with every plan. UXPin has four categories for Design Systems:

• Colors
• Typography
• Assets
• Components

Designers can also include written design system documentation, so everything is in one place. If an existing product already uses elements from your design system, find the correct file names and inform engineers to prevent duplicate work.

Organized components

Beyond creating a design system, designers must organize components so that it’s easier to code them systematically. This example from Material Design arranges UI elements by type.

Designers could also categorize components using atomic design principles:

• Atoms: foundational elements
• Molecules: UI components 
• Organisms: Larger components and patterns

File structure and naming convention

Engineers work with repositories where file structure and naming conventions are essential for successful workflows and collaboration. Mirroring these practices for design projects reduces the “language barrier” between designers and engineers.

Documentation

Designers must create written documentation to support annotations on mockups and prototypes. The written documentation is a story to provide context to interactions, interfaces, and user flows–what happens when a user clicks “element X”? What are the success/error/warning messages? What happens if a user isn’t logged in?

Information architecture

Prototypes and mockups aren’t enough to develop websites and digital products. Engineers need to see how everything goes together and where user flows start and end through information architecture.

Wireframes or flowcharts are the best methods for presenting information architecture. Designers can share these with engineers using Miro or a free tool like Google Jamboard. Alternatively, UXPin provides a User Flows Design Library to build flowcharts for your information architecture.

Engineers can use this information architecture to organize file structures and prepare each screen before they start development.

Mockups and Prototypes

Engineers use mockups to develop each user interface and prototypes to create navigational points, interactions, and animations. The higher the fidelity and interactivity of prototypes, the easier it is for engineers to interpret and replicate them with less documentation and explanation.

While most design tools create beautiful mockups, they lack features for interactive prototyping. UXPin is powered by code, giving designers tools and features to build fully interactive prototypes that look and feel like the final product.

Some key UXPin prototyping features include:

• States: Apply multiple states to a single element, each with different properties, interactions, and animations. Designers can use States to create simple interactivity like button states or complex components like accordions, multi-level navigation, and more.
• Interactions: UXPin offers an extensive list of triggers, actions, and animations to replicate code-like interactivity. Conditional Interactions allow designers to create dynamic experiences based on user actions, giving engineers an accurate reference for development.
• Variables: UXPin features fully functioning forms designers can use to capture user inputs and use that data elsewhere in the prototype. Variables help engineers understand how the product’s inputs must work, including vital error messages to help users complete tasks.
• Expressions: Javascript-like functions to create complex interactivity like form validation or fully functioning shopping carts. Engineers can use these Expressions as a foundation for writing the product’s Javascript functions.

Specifications

Specifications give engineers detailed information about an interface’s CSS properties like spacing, font sizes, heights, widths, etc. Design tools usually have plugins or extensions to automate this process.

UXPin’s built-in Spec Mode allows developers to select UI elements to view specifications, including automatically generated starter CSS they can copy/paste.

Checklist

A design handoff checklist itemizes everything designers give to engineers. This checklist is one of the most important documents because it ensures designers remember to hand everything over and engineers confirm that they receive everything.

What Developers Don’t Need

What developers don’t need for design handoffs is just as important as what they do! As you can see above, there are many artifacts, and documentation engineers must reference to develop the final product. Too much information can confuse and delay development while engineers sift through unnecessary documentation.

Engineers don’t need access to your UX research artifacts like user personas, journey maps, competitive analysis, etc. High-level overviews, reports, and summaries are sufficient to outline the problems your designs solve.

Pick Developer-Friendly Design Handoff Tool

Designers who use image-based design tools like Figma and Sketch must rely on additional tools and plugins for design handoffs. These extras increase design costs and create room for error.

Even with these extra tools, designers still battle with fidelity and functionality, limiting prototyping scope. Sometimes, they use videos and GIFs to demonstrate interactions, which need additional context and clarification for engineering teams and stakeholders.

UXPin is an end-to-end design tool with everything designers need from concept to final design handoff. Designers can build prototypes that accurately replicate the final product experience, leaving no ambiguity regarding features, navigation, interactions, and animations.

Engineers can view prototypes, mockups, documentation, specs, and components and download assets from one interface. Teams can collaborate during handoffs via UXPin’s Comments and even assign comments to direct questions to specific team members.

UXPin also integrates with Slack and Jira so product development teams and stakeholders can stay up-to-date with design handoffs and project status.

Using one tool for ideation, wireframing, mockups, prototyping, testing, user flows, design systems, documentation, and design handoffs creates a productive environment for designers as they don’t have to switch between platforms. UXPin’s high-quality prototypes mean designers spend less time explaining features and interactivity, creating a smoother transition from design to code.

Seamless (NO) Handover With UXPin Merge

Where UXPin makes design handoffs easier, UXPin’s Merge technology facilitates a seamless (no) handover process where there is no designing or writing front-end code! Designers drag and drop, while engineers copy/paste.

UXPin Merge syncs a design system (private or open source) hosted in a repo to UXPin’s design editor, giving designers the same component library engineers use to develop the final product. This single source of truth means designers and engineers speak the same languages and work within the same constraints.

Any changes to the component library’s repository automatically sync to UXPin, notifying design teams of the update. Merge’s Version Control allows designers to choose when to switch to the latest version, and they can change to early versions of the design system at any time.

Merge components are fully interactive and include properties defined by the design system, including states, colors, sizing, etc. Designers can adjust these properties via the Properties Panel, which UXPin renders as JSX for engineers to copy at design handoffs.

Nick Elliott, Design System Product Owner and Regional Head of Product Design at Iress, noted that Merge has a huge potential for streamlining the company’s handoff process:

“The engineer no longer needs to start from scratch and already knows what components and settings to use. It will help us avoid the ‘design drift’ we so often see. Things like spacing and typography should all be aligned, as it is all driven from one place.”

Ready to make painful design handoffs a thing of the past? Switch to UXPin Merge create a seamless (no) handover product development process. Visit our Merge page for more details and how to request access.

The post Design Handoff Basics – What Do Developers Need from Designers? appeared first on Studio by UXPin.

Is design handoff stresses you out? It won’t anymore. Let’s see the exact tasks you need to do to make design handoff better. Let’s explore!

Design handoff doesn’t need to be point of friction between designers and engineers. Use UXPin Merge and bridge the gap between those teams by using a single source of truth. UXPin Merge allows you to bring reusable UI components from devs’ component library to the design editor and make them accessible to designers. Learn more about UXPin Merge.

Reach a new level of prototyping

Design with interactive components coming from your team’s design system.

Discover UXPin Merge

47-Point Design Handoff Checklist

We’ve created this simple 47-point checklist as a guide for your next design handoff. If you want to learn more about the process itself, head on to our previous article: Create a Better Design Handoff.

During Design

Discovery:

• Invite developers to attend user interviews when possible. 
• Circulate bulleted summary of user interview insights with developers.  
• Conduct a 30-minute to 1-hour stakeholder interview with at least one developer. Use Kim Goodwin’s excellent questions.  
• Create and quickly review lean personas with developers.  
• Get developer input and alignment on technical restraints for the design brief.

Planning:

• Ensure developers (or at least the development lead) attends the kickoff.
• Conduct user story mapping with developers to plan epics and sprints. 
• Estimate build time for user stories with developers using tactics like planning poker. 
• Plan 1-2 design sprints ahead of the development process. 
• Check which framework the designs must use (Bootstrap, Foundation, custom, etc.). Adapt grids and elements accordingly.  
• Verify browser support with developers.  
• After each standup meeting, quickly review the backlog with developers.

Prototyping:

• Walkthrough user flows and lo-fi prototypes for developer feedback on feasibility.  
• Start designing extreme viewports (smallest and largest) to accurately “bracket” your content. Consider how your design will respond to screen sizes slightly smaller or larger than your assumptions. 
• Incorporate rough content (not Lorem Ipsum) into the prototype within the first two iterations. 
• Invite developers to attend at least one user testing session.  
• Prototypes account for all interaction states, error states, and transitions between states.  
• Prototypes account for data extremes (e.g., short and long last names, phone number formats, non-US postcodes). 
• Circulate all user test recordings with a bulleted summary of insights to developers.  
• Collect feedback and approval from developers at each iteration of the prototype.

UI Design:

• With each iteration, rename your design file (v.1, v.2, etc.). Do not rename “Latest” or “Newest.” Upload every new version into a shared repository.    
• Create as many reusable patterns as possible (menus, links, buttons, panels, etc.) so developers have a component-based system.  
• Make UI decisions that create consistency for the user experience and codebase.  
• Get developer buy-in on image formats and sizes.  
• Create designs in all significant breakpoints on a grid system with guides/overlays. 
• To preserve typographic integrity, use whole font values and leading values (e.g., 15 instead of 15.75).
• Use web-safe fonts when possible. Don’t use more than one custom font.  
• Check that you own the rights for all photography and typography.  
• Hold a 30-minute to an hour review of final approved mockups alongside the prototype: walkthrough project goals, user stories, interactions, states, and failure states.

During Handoff

Visual Hygiene:

• Delete all unused layers. Don’t just hide them since that may confuse developers.  
• Delete all unused guides.  
• Group and name layers appropriately based on UI modules (navigation, footer, etc.)  
• Follow a common naming convention with developers (e.g., a “widget” is not the same as a “module”). Consider using BEM notation.  
• Instead of naming artboards with “FINAL” or “LATEST,” follow a standard versioning protocol (v.1, v.2, etc.). 
• For easier navigation, collapse all layers before sending off designs.

Assets:

• Create subfolders within your main project containing all relevant icons, fonts, images.  
• Include SVGs wherever possible. For raster files, include versions at 2x.

Documentation:

• Annotate prototypes with use cases, failure states, and interaction nuances. 
• Annotate the full code snippet (or classes in frameworks) next to every element.  
• Use an inspection tool to auto-generate visual specs (color codes, dimensions, font sizes, margins, padding, etc.). Avoid redlining as much as possible. 
• Ensure all documentation stays updated to reflect the final system as it evolves. Developers will refer to the documentation to understand the depth and breadth of the system, using the final prototype as a reference for acceptable behaviors.

After Design Handoff

Accuracy of Build:

• Designers perform an “implementation audit” of each build during the QA process against the final prototype. 
• Designers attend sprint demos along with PMs.  
• Acceptance testing includes UX criteria based on the final prototype.

Design System:

• Describe accessibility requirements and any implications on the development process. For example, Salesforce Lightning: “Our forms offer proper use of <fieldset> and <legend> tags as well as appropriate labeling for input controls.”  
• Include code snippets for all UI components (menus, buttons, etc.) along with specific descriptions of use cases.  
• Include links to downloadable UI kits, color swatches, and code repositories (e.g., Github).

Achieve Better Design Handoff with UXPin Merge

What if you could use a tool that makes it impossible for design drift to occur? Bring interactive, fully-functional UI components to UXPin and improve your design handoff instantly. That’s exactly what our Merge technology offers.

Make your designers and developers share a single source of truth between design and code, so they can be on the same page and avoid all the errors of poorly executed design handoff. Bring UI components stored in a Git repository or Storybook. Streamline design handoff with Merge. See how UXPin Merge works. 

The post Design Handoff Checklist – 47 Points that Will Guide You Through the Process appeared first on Studio by UXPin.