Tag: Challenges

24 Jun

Designing With Code: A Modern Approach To Design (Development Challenges)

by TBSCategories: News

Friction in cooperation between designers and developers is fueling an ever-evolving discussion as old as the industry itself. We came a long way to where we are today. Our tools have changed. Our processes and methodologies have changed. But the underlying problems often remained the same.

One of the recurring problems I often tend to see, regardless of the type and size of the team, is maintaining a reliable source of truth. Even hiring the best people and using proven industry-standard solutions often leaves us to a distaste that something definitely could have been done better. The infamous “final version” is often spread across technical documentation, design files, spreadsheets, and other places. Keeping them all in sync is usually a tedious and daunting task.

Note: This article has been written in collaboration with the UXPin team. Examples presented in this article have been created in the UXPin app. Some of the features are only available on paid plans. The full overview of UXPin’s pricing can be found here.

The Problem With Design Tools

Talking of maintaining a source of truth, the inefficiency of design tools is often being indicated as one of the most wearing pain points. Modern design tools are evolving and they are evolving fast with tremendous efforts. But when it comes to building the bridge between design and development, it’s not rare to get the impression that many of those efforts are based on flawed assumptions.

Most of the modern design tools are based on different models than the technologies used to implement the designs later on. They are built as graphic editors and behave as such. The way layouts are built and processed in design tools is ultimately different from whatever CSS, JavaScript and other programming languages have to offer. Building user interfaces using vector (or even raster) graphics is constant guesswork of how and if what you make should be turned into code later.

Designers often end up lamenting about their creations not being implemented as intended. Even the bravest efforts towards pixel-perfect designs don’t solve all the problems. In design tools, it is close to impossible to imagine and cover all the possible cases. Supporting different states, changing copy, various viewport sizes, screen resolutions and so on, simply provide too many changing variables to cover them all.

On top of that come along some technical constraints and limitations. Being a designer without prior development experience, it is immensely hard to take all the technical factors into account. Remember all the possible states of inputs. Understand the limitations of browser support. Predict the performance implications of your work. Design for accessibility, at least in a sense much broader than color contrast and font sizes. Being aware of these challenges, we accept some amount of guesswork as a necessary evil.

But developers often have to depend on guesswork, too. User interfaces mocked up with graphics editors rarely answer all of their questions. Is it the same component as the one we already have, or not? Should I treat it as a different state or as a separate entity? How should this design behave when X, Y, or Z? Can we make it a bit differently as it would be faster and cheaper? Ironically, asking whoever created the designs in the first place is not always helpful. Not rarely, they don’t know either.

And usually, this is not where the scope of growing frustration ends. Because then, there’s also everyone else. Managers, stakeholders, team leaders, salespeople. With their attention and mental capacity stretched thin among all the tools and places where various parts of the product live, they struggle more than anyone else to get a good grasp of it.

Navigating prototypes, understanding why certain features and states are missing from the designs, and distinguishing between what is missing, what is a work in progress, and what has been consciously excluded from the scope feels almost impossible. Quickly iterating on what was already done, visualizing your feedback, and presenting your own ideas feels hardly possible, too. Ironically, more and more sophisticated tools and processes are aimed at designers and developers to work better together; they set the bar even higher, and active participation in the processes for other people even harder.

The Solutions

Countless heads of our industry have worked on tackling those problems resulting in new paradigms, tools, and concepts. And indeed a lot has changed for the better. Let’s take a quick look and what are some of the most common approaches towards the outlined challenges.

Coding Designers

“Should designers code?” is a cliché question discussed a countless number of times through articles, conference talks, and all other media with new voices in the discussion popping up with stable regularity now and then. There is a common assumption that if designers “knew how to code” (let’s not even start to dwell on how to define “knowing how to code” in the first place), it would be easier for them to craft designs that take the technological constraints into account and are easier to implement.

Some would go even further and say they should be taking an active role in the implementation. At that stage, it’s easy to jump to conclusions that it wouldn’t be without sense to skip using the design tools altogether and just “design in code”.

Tempting as the idea may sound, it rarely proves itself in reality. All the best coding designers I know are still using design tools. And that’s definitely not due to a lack of technical skills. To explain the why is important to highlight a difference between ideation, sketching, and building the actual thing.

As long as there are many valid use cases for “designing in code”, such as utilizing predefined styles and components to quickly build a fully functional interface without bothering yourselves with design tools at all, the promise of unconstrained visual freedom is offered by design tools still stands of undeniable value. Many people find sketching new ideas in a format offered by design tools easier and more suited for the nature of a creative process. And that is not going to change anytime soon. Design tools are here to stay and to stay for good.

Design Systems

The great mission of design systems, one of the greatest buzzwords of the digital design world in the last years, has always been exactly that: to limit guesswork and repetition, improve efficiency and maintainability, and unify sources of truth. Corporate systems such as Fluent or Material Design have done a lot of legwork in advocacy for the idea and bringing momentum to the adoption of the concept across both big and small players. And indeed, design systems helped to change a lot for the better. A more structured approach to developing a defined collection of design principles, patterns, and components helped countless companies to build better, more maintainable products.

Some challenges had not been solved straight away though. Designing design systems in popular design tools hampered the efforts of many in achieving a single source of truth. Instead, a plethora of systems has been created that, even though unified, still exist in two separate, incompatible sources: a design source and a development source. Maintaining mutual parity between the two usually proves to be a painful chore, repeating all the most hated pain points that design systems were trying to solve in the first place.

Design And Code Integrations

To solve the maintainability headaches of design systems another wave of solutions has soon arrived. Concepts such as design tokens have started to gain traction. Some were meant for syncing the state of code with designs, such as open APIs that allow fetching certain values straight from the design files. Others were meant for syncing the designs with code, e.g. by generating components in design tools from code.

Few of these ideas ever gained widespread adoption. This is most probably due to the questionable advantage of possible benefits over the necessary entry costs of still highly imperfect solutions. Translating designs automatically into code still poses immense challenges for most professional use cases. Solutions allowing you to merge existing code with designs have also been severely limited.

For example, none of the solutions allowing you to import coded components into design tools, even if visually true to the source, would fully replicate the behavior of such components. None until now.

Merging Design And Code With UXPin

UXPin, being a mature and fully-featured design app, is not a new player on the design tools stage. But its recent advancements, such as Merge technology, are what can change the odds of how we think about design and development tools.

UXPin with Merge technology allows us to bring real, live components into design by preserving both their visuals and functionality — all without writing a single line of code. The components, even though embedded in design files, shall behave exactly as their real counterparts — because they are their real counterparts. This allows us not only to achieve seamless parity between code and design but also to keep the two in uninterrupted sync.

UXPin supports design libraries of React components stored in git repositories as well as a robust integration with Storybook that allows usage of components from almost any popular front-end framework. If you’d like to give it a shot yourself, you can request access to it on the UXPin website:

Merging live components with designs in UXPin takes surprisingly few steps. After finding the right component, you can place it on the design canvas with a click. It will behave like any other object within your designs. What will make it special is that, even though being an integral part of the designs, you can now use and customize it the same as you would in code.

UXPin gives you access to the component’s properties, lets you change its values and variables, and fill it with your own data. Once starting the prototype, the component shall behave exactly as expected, maintaining all the behaviors and interactions.

Using a component “as is” also means that it should behave according to the change of the context, such as the width of the viewport. In other words, such components are fully responsive and adaptable.

Note: If you would like to learn more about building truly responsive designs with UXPin, I strongly encourage you to check out this article.

Context may also mean theming. Whoever tried to build (and maintain!) a themeable design system in a design tool, or at least create a system that allows you to easily switch between a light and a dark theme, knows how tricky of a task it is and how imperfect the results usually are. None of the design tools is well optimized for theming out of the box and available plugins aimed at solving that issue are far from solving it fully.

As UXPin with Merge technology uses real, live components, you can also theme them as real, live components. Not only can you create as many themes as you need, but switching them can be as quick as choosing the right theme from a dropdown. (You can read more about theme switching with UXPin here.)

Advantages

UXPin with Merge technology allows a level of parity between design and code rarely seen before. Being true to the source in a design process brings impeccable advantages for all sides of the process. Designers can design with confidence knowing that what they make will not get misinterpreted or wrongly developed. Developers do not have to translate the designs into code and muddle through inexplicit edge cases and uncovered scenarios. On top of that, everyone can participate in the work and quickly prototype their ideas using live components without any knowledge about the underlying code at all. Achieving more democratic, participatory processes is much more within reach.

Merging your design with code might not only improve how designers cooperate with the other constituents of the team, but also refine their internal processes and practices. UXPin with Merge technology can be a game-changer for those focused on optimization of design efforts at scale, sometimes referred to as DesignOps.

Using the right source of truth makes it inexplicably easier to maintain consistency between the works produced by different people among the team, helps to keep them aligned, and solves the right problems together with a joint set of tools. No more “detached symbols” with a handful of unsolicited variations.

At the bottom line, what we get are enormous time savings. Designers save their time by using the components with confidence and their functionalities coming out of the box. They don’t have to update the design files as the components change, nor document their work and “wave hands” to explain their visions to the rest of the team. Developers save time by getting the components from designers in an instantly digestible manner that doesn’t require guesswork and extra tinkering.

People responsible for testing and QA save time on hunting inconsistencies between designs and code and figuring out if implantation happened as intended. Stakeholders and other team members save time through more efficient management and easier navigation of such teams. Less friction and seamless processes limit frustration among team members.

Disadvantages

Taking advantage of these benefits comes at some entry costs though. To efficiently use tools such as UXPin in your process, you need to have an existing design system or components library in place. Alternatively, you can base your work on one of the open-source systems which would always provide some level of limitation.

However, if you are committed to building a design system in the first place, utilizing UXPin with Merge technology in your process would come at little to no additional cost. With a well-built design system, adopting UXPin should not be a struggle, whilst the benefits of such a shift might prove drastically.

Summary

Widespread adoption of design systems addressed the issues of the media developers and designers work with. Currently, we can observe a shift towards more unified processes that not only transform the medium but also the way we create it. Using the right tools is crucial to that change. UXPin with Merge technology is a design tool that allows combining design with live code components and drastically narrows the gap between the domains design and development operate in.

Where Next?

Articles on Smashing Magazine — For Web Designers And Developers

24 Jun

Designing With Code: A Modern Approach To Design (Development Challenges)

by TBSCategories: News

Friction in cooperation between designers and developers is fueling an ever-evolving discussion as old as the industry itself. We came a long way to where we are today. Our tools have changed. Our processes and methodologies have changed. But the underlying problems often remained the same.

One of the recurring problems I often tend to see, regardless of the type and size of the team, is maintaining a reliable source of truth. Even hiring the best people and using proven industry-standard solutions often leaves us to a distaste that something definitely could have been done better. The infamous “final version” is often spread across technical documentation, design files, spreadsheets, and other places. Keeping them all in sync is usually a tedious and daunting task.

Note: This article has been written in collaboration with the UXPin team. Examples presented in this article have been created in the UXPin app. Some of the features are only available on paid plans. The full overview of UXPin’s pricing can be found here.

The Problem With Design Tools

Talking of maintaining a source of truth, the inefficiency of design tools is often being indicated as one of the most wearing pain points. Modern design tools are evolving and they are evolving fast with tremendous efforts. But when it comes to building the bridge between design and development, it’s not rare to get the impression that many of those efforts are based on flawed assumptions.

Most of the modern design tools are based on different models than the technologies used to implement the designs later on. They are built as graphic editors and behave as such. The way layouts are built and processed in design tools is ultimately different from whatever CSS, JavaScript and other programming languages have to offer. Building user interfaces using vector (or even raster) graphics is constant guesswork of how and if what you make should be turned into code later.

Designers often end up lamenting about their creations not being implemented as intended. Even the bravest efforts towards pixel-perfect designs don’t solve all the problems. In design tools, it is close to impossible to imagine and cover all the possible cases. Supporting different states, changing copy, various viewport sizes, screen resolutions and so on, simply provide too many changing variables to cover them all.

On top of that come along some technical constraints and limitations. Being a designer without prior development experience, it is immensely hard to take all the technical factors into account. Remember all the possible states of inputs. Understand the limitations of browser support. Predict the performance implications of your work. Design for accessibility, at least in a sense much broader than color contrast and font sizes. Being aware of these challenges, we accept some amount of guesswork as a necessary evil.

But developers often have to depend on guesswork, too. User interfaces mocked up with graphics editors rarely answer all of their questions. Is it the same component as the one we already have, or not? Should I treat it as a different state or as a separate entity? How should this design behave when X, Y, or Z? Can we make it a bit differently as it would be faster and cheaper? Ironically, asking whoever created the designs in the first place is not always helpful. Not rarely, they don’t know either.

And usually, this is not where the scope of growing frustration ends. Because then, there’s also everyone else. Managers, stakeholders, team leaders, salespeople. With their attention and mental capacity stretched thin among all the tools and places where various parts of the product live, they struggle more than anyone else to get a good grasp of it.

Navigating prototypes, understanding why certain features and states are missing from the designs, and distinguishing between what is missing, what is a work in progress, and what has been consciously excluded from the scope feels almost impossible. Quickly iterating on what was already done, visualizing your feedback, and presenting your own ideas feels hardly possible, too. Ironically, more and more sophisticated tools and processes are aimed at designers and developers to work better together; they set the bar even higher, and active participation in the processes for other people even harder.

The Solutions

Countless heads of our industry have worked on tackling those problems resulting in new paradigms, tools, and concepts. And indeed a lot has changed for the better. Let’s take a quick look and what are some of the most common approaches towards the outlined challenges.

Coding Designers

“Should designers code?” is a cliché question discussed a countless number of times through articles, conference talks, and all other media with new voices in the discussion popping up with stable regularity now and then. There is a common assumption that if designers “knew how to code” (let’s not even start to dwell on how to define “knowing how to code” in the first place), it would be easier for them to craft designs that take the technological constraints into account and are easier to implement.

Some would go even further and say they should be taking an active role in the implementation. At that stage, it’s easy to jump to conclusions that it wouldn’t be without sense to skip using the design tools altogether and just “design in code”.

Tempting as the idea may sound, it rarely proves itself in reality. All the best coding designers I know are still using design tools. And that’s definitely not due to a lack of technical skills. To explain the why is important to highlight a difference between ideation, sketching, and building the actual thing.

As long as there are many valid use cases for “designing in code”, such as utilizing predefined styles and components to quickly build a fully functional interface without bothering yourselves with design tools at all, the promise of unconstrained visual freedom is offered by design tools still stands of undeniable value. Many people find sketching new ideas in a format offered by design tools easier and more suited for the nature of a creative process. And that is not going to change anytime soon. Design tools are here to stay and to stay for good.

Design Systems

The great mission of design systems, one of the greatest buzzwords of the digital design world in the last years, has always been exactly that: to limit guesswork and repetition, improve efficiency and maintainability, and unify sources of truth. Corporate systems such as Fluent or Material Design have done a lot of legwork in advocacy for the idea and bringing momentum to the adoption of the concept across both big and small players. And indeed, design systems helped to change a lot for the better. A more structured approach to developing a defined collection of design principles, patterns, and components helped countless companies to build better, more maintainable products.

Some challenges had not been solved straight away though. Designing design systems in popular design tools hampered the efforts of many in achieving a single source of truth. Instead, a plethora of systems has been created that, even though unified, still exist in two separate, incompatible sources: a design source and a development source. Maintaining mutual parity between the two usually proves to be a painful chore, repeating all the most hated pain points that design systems were trying to solve in the first place.

Design And Code Integrations

To solve the maintainability headaches of design systems another wave of solutions has soon arrived. Concepts such as design tokens have started to gain traction. Some were meant for syncing the state of code with designs, such as open APIs that allow fetching certain values straight from the design files. Others were meant for syncing the designs with code, e.g. by generating components in design tools from code.

Few of these ideas ever gained widespread adoption. This is most probably due to the questionable advantage of possible benefits over the necessary entry costs of still highly imperfect solutions. Translating designs automatically into code still poses immense challenges for most professional use cases. Solutions allowing you to merge existing code with designs have also been severely limited.

For example, none of the solutions allowing you to import coded components into design tools, even if visually true to the source, would fully replicate the behavior of such components. None until now.

Merging Design And Code With UXPin

UXPin, being a mature and fully-featured design app, is not a new player on the design tools stage. But its recent advancements, such as Merge technology, are what can change the odds of how we think about design and development tools.

UXPin with Merge technology allows us to bring real, live components into design by preserving both their visuals and functionality — all without writing a single line of code. The components, even though embedded in design files, shall behave exactly as their real counterparts — because they are their real counterparts. This allows us not only to achieve seamless parity between code and design but also to keep the two in uninterrupted sync.

UXPin supports design libraries of React components stored in git repositories as well as a robust integration with Storybook that allows usage of components from almost any popular front-end framework. If you’d like to give it a shot yourself, you can request access to it on the UXPin website:

Merging live components with designs in UXPin takes surprisingly few steps. After finding the right component, you can place it on the design canvas with a click. It will behave like any other object within your designs. What will make it special is that, even though being an integral part of the designs, you can now use and customize it the same as you would in code.

UXPin gives you access to the component’s properties, lets you change its values and variables, and fill it with your own data. Once starting the prototype, the component shall behave exactly as expected, maintaining all the behaviors and interactions.

Using a component “as is” also means that it should behave according to the change of the context, such as the width of the viewport. In other words, such components are fully responsive and adaptable.

Note: If you would like to learn more about building truly responsive designs with UXPin, I strongly encourage you to check out this article.

Context may also mean theming. Whoever tried to build (and maintain!) a themeable design system in a design tool, or at least create a system that allows you to easily switch between a light and a dark theme, knows how tricky of a task it is and how imperfect the results usually are. None of the design tools is well optimized for theming out of the box and available plugins aimed at solving that issue are far from solving it fully.

As UXPin with Merge technology uses real, live components, you can also theme them as real, live components. Not only can you create as many themes as you need, but switching them can be as quick as choosing the right theme from a dropdown. (You can read more about theme switching with UXPin here.)

Advantages

UXPin with Merge technology allows a level of parity between design and code rarely seen before. Being true to the source in a design process brings impeccable advantages for all sides of the process. Designers can design with confidence knowing that what they make will not get misinterpreted or wrongly developed. Developers do not have to translate the designs into code and muddle through inexplicit edge cases and uncovered scenarios. On top of that, everyone can participate in the work and quickly prototype their ideas using live components without any knowledge about the underlying code at all. Achieving more democratic, participatory processes is much more within reach.

Merging your design with code might not only improve how designers cooperate with the other constituents of the team, but also refine their internal processes and practices. UXPin with Merge technology can be a game-changer for those focused on optimization of design efforts at scale, sometimes referred to as DesignOps.

Using the right source of truth makes it inexplicably easier to maintain consistency between the works produced by different people among the team, helps to keep them aligned, and solves the right problems together with a joint set of tools. No more “detached symbols” with a handful of unsolicited variations.

At the bottom line, what we get are enormous time savings. Designers save their time by using the components with confidence and their functionalities coming out of the box. They don’t have to update the design files as the components change, nor document their work and “wave hands” to explain their visions to the rest of the team. Developers save time by getting the components from designers in an instantly digestible manner that doesn’t require guesswork and extra tinkering.

People responsible for testing and QA save time on hunting inconsistencies between designs and code and figuring out if implantation happened as intended. Stakeholders and other team members save time through more efficient management and easier navigation of such teams. Less friction and seamless processes limit frustration among team members.

Disadvantages

Taking advantage of these benefits comes at some entry costs though. To efficiently use tools such as UXPin in your process, you need to have an existing design system or components library in place. Alternatively, you can base your work on one of the open-source systems which would always provide some level of limitation.

However, if you are committed to building a design system in the first place, utilizing UXPin with Merge technology in your process would come at little to no additional cost. With a well-built design system, adopting UXPin should not be a struggle, whilst the benefits of such a shift might prove drastically.

Summary

Widespread adoption of design systems addressed the issues of the media developers and designers work with. Currently, we can observe a shift towards more unified processes that not only transform the medium but also the way we create it. Using the right tools is crucial to that change. UXPin with Merge technology is a design tool that allows combining design with live code components and drastically narrows the gap between the domains design and development operate in.

Where Next?

Articles on Smashing Magazine — For Web Designers And Developers

23 Jun

Designing With Code: A Modern Approach To Design (Development Challenges)

by TBSCategories: News

Friction in cooperation between designers and developers is fueling an ever-evolving discussion as old as the industry itself. We came a long way to where we are today. Our tools have changed. Our processes and methodologies have changed. But the underlying problems often remained the same.

One of the recurring problems I often tend to see, regardless of the type and size of the team, is maintaining a reliable source of truth. Even hiring the best people and using proven industry-standard solutions often leaves us to a distaste that something definitely could have been done better. The infamous “final version” is often spread across technical documentation, design files, spreadsheets, and other places. Keeping them all in sync is usually a tedious and daunting task.

Note: This article has been written in collaboration with the UXPin team. Examples presented in this article have been created in the UXPin app. Some of the features are only available on paid plans. The full overview of UXPin’s pricing can be found here.

The Problem With Design Tools

Talking of maintaining a source of truth, the inefficiency of design tools is often being indicated as one of the most wearing pain points. Modern design tools are evolving and they are evolving fast with tremendous efforts. But when it comes to building the bridge between design and development, it’s not rare to get the impression that many of those efforts are based on flawed assumptions.

Most of the modern design tools are based on different models than the technologies used to implement the designs later on. They are built as graphic editors and behave as such. The way layouts are built and processed in design tools is ultimately different from whatever CSS, JavaScript and other programming languages have to offer. Building user interfaces using vector (or even raster) graphics is constant guesswork of how and if what you make should be turned into code later.

Designers often end up lamenting about their creations not being implemented as intended. Even the bravest efforts towards pixel-perfect designs don’t solve all the problems. In design tools, it is close to impossible to imagine and cover all the possible cases. Supporting different states, changing copy, various viewport sizes, screen resolutions and so on, simply provide too many changing variables to cover them all.

On top of that come along some technical constraints and limitations. Being a designer without prior development experience, it is immensely hard to take all the technical factors into account. Remember all the possible states of inputs. Understand the limitations of browser support. Predict the performance implications of your work. Design for accessibility, at least in a sense much broader than color contrast and font sizes. Being aware of these challenges, we accept some amount of guesswork as a necessary evil.

But developers often have to depend on guesswork, too. User interfaces mocked up with graphics editors rarely answer all of their questions. Is it the same component as the one we already have, or not? Should I treat it as a different state or as a separate entity? How should this design behave when X, Y, or Z? Can we make it a bit differently as it would be faster and cheaper? Ironically, asking whoever created the designs in the first place is not always helpful. Not rarely, they don’t know either.

And usually, this is not where the scope of growing frustration ends. Because then, there’s also everyone else. Managers, stakeholders, team leaders, salespeople. With their attention and mental capacity stretched thin among all the tools and places where various parts of the product live, they struggle more than anyone else to get a good grasp of it.

Navigating prototypes, understanding why certain features and states are missing from the designs, and distinguishing between what is missing, what is a work in progress, and what has been consciously excluded from the scope feels almost impossible. Quickly iterating on what was already done, visualizing your feedback, and presenting your own ideas feels hardly possible, too. Ironically, more and more sophisticated tools and processes are aimed at designers and developers to work better together; they set the bar even higher, and active participation in the processes for other people even harder.

The Solutions

Countless heads of our industry have worked on tackling those problems resulting in new paradigms, tools, and concepts. And indeed a lot has changed for the better. Let’s take a quick look and what are some of the most common approaches towards the outlined challenges.

Coding Designers

“Should designers code?” is a cliché question discussed a countless number of times through articles, conference talks, and all other media with new voices in the discussion popping up with stable regularity now and then. There is a common assumption that if designers “knew how to code” (let’s not even start to dwell on how to define “knowing how to code” in the first place), it would be easier for them to craft designs that take the technological constraints into account and are easier to implement.

Some would go even further and say they should be taking an active role in the implementation. At that stage, it’s easy to jump to conclusions that it wouldn’t be without sense to skip using the design tools altogether and just “design in code”.

Tempting as the idea may sound, it rarely proves itself in reality. All the best coding designers I know are still using design tools. And that’s definitely not due to a lack of technical skills. To explain the why is important to highlight a difference between ideation, sketching, and building the actual thing.

As long as there are many valid use cases for “designing in code”, such as utilizing predefined styles and components to quickly build a fully functional interface without bothering yourselves with design tools at all, the promise of unconstrained visual freedom is offered by design tools still stands of undeniable value. Many people find sketching new ideas in a format offered by design tools easier and more suited for the nature of a creative process. And that is not going to change anytime soon. Design tools are here to stay and to stay for good.

Design Systems

The great mission of design systems, one of the greatest buzzwords of the digital design world in the last years, has always been exactly that: to limit guesswork and repetition, improve efficiency and maintainability, and unify sources of truth. Corporate systems such as Fluent or Material Design have done a lot of legwork in advocacy for the idea and bringing momentum to the adoption of the concept across both big and small players. And indeed, design systems helped to change a lot for the better. A more structured approach to developing a defined collection of design principles, patterns, and components helped countless companies to build better, more maintainable products.

Some challenges had not been solved straight away though. Designing design systems in popular design tools hampered the efforts of many in achieving a single source of truth. Instead, a plethora of systems has been created that, even though unified, still exist in two separate, incompatible sources: a design source and a development source. Maintaining mutual parity between the two usually proves to be a painful chore, repeating all the most hated pain points that design systems were trying to solve in the first place.

Design And Code Integrations

To solve the maintainability headaches of design systems another wave of solutions has soon arrived. Concepts such as design tokens have started to gain traction. Some were meant for syncing the state of code with designs, such as open APIs that allow fetching certain values straight from the design files. Others were meant for syncing the designs with code, e.g. by generating components in design tools from code.

Few of these ideas ever gained widespread adoption. This is most probably due to the questionable advantage of possible benefits over the necessary entry costs of still highly imperfect solutions. Translating designs automatically into code still poses immense challenges for most professional use cases. Solutions allowing you to merge existing code with designs have also been severely limited.

For example, none of the solutions allowing you to import coded components into design tools, even if visually true to the source, would fully replicate the behavior of such components. None until now.

Merging Design And Code With UXPin

UXPin, being a mature and fully-featured design app, is not a new player on the design tools stage. But its recent advancements, such as Merge technology, are what can change the odds of how we think about design and development tools.

UXPin with Merge technology allows us to bring real, live components into design by preserving both their visuals and functionality — all without writing a single line of code. The components, even though embedded in design files, shall behave exactly as their real counterparts — because they are their real counterparts. This allows us not only to achieve seamless parity between code and design but also to keep the two in uninterrupted sync.

UXPin supports design libraries of React components stored in git repositories as well as a robust integration with Storybook that allows usage of components from almost any popular front-end framework. If you’d like to give it a shot yourself, you can request access to it on the UXPin website:

Merging live components with designs in UXPin takes surprisingly few steps. After finding the right component, you can place it on the design canvas with a click. It will behave like any other object within your designs. What will make it special is that, even though being an integral part of the designs, you can now use and customize it the same as you would in code.

UXPin gives you access to the component’s properties, lets you change its values and variables, and fill it with your own data. Once starting the prototype, the component shall behave exactly as expected, maintaining all the behaviors and interactions.

Using a component “as is” also means that it should behave according to the change of the context, such as the width of the viewport. In other words, such components are fully responsive and adaptable.

Note: If you would like to learn more about building truly responsive designs with UXPin, I strongly encourage you to check out this article.

Context may also mean theming. Whoever tried to build (and maintain!) a themeable design system in a design tool, or at least create a system that allows you to easily switch between a light and a dark theme, knows how tricky of a task it is and how imperfect the results usually are. None of the design tools is well optimized for theming out of the box and available plugins aimed at solving that issue are far from solving it fully.

As UXPin with Merge technology uses real, live components, you can also theme them as real, live components. Not only can you create as many themes as you need, but switching them can be as quick as choosing the right theme from a dropdown. (You can read more about theme switching with UXPin here.)

Advantages

UXPin with Merge technology allows a level of parity between design and code rarely seen before. Being true to the source in a design process brings impeccable advantages for all sides of the process. Designers can design with confidence knowing that what they make will not get misinterpreted or wrongly developed. Developers do not have to translate the designs into code and muddle through inexplicit edge cases and uncovered scenarios. On top of that, everyone can participate in the work and quickly prototype their ideas using live components without any knowledge about the underlying code at all. Achieving more democratic, participatory processes is much more within reach.

Merging your design with code might not only improve how designers cooperate with the other constituents of the team, but also refine their internal processes and practices. UXPin with Merge technology can be a game-changer for those focused on optimization of design efforts at scale, sometimes referred to as DesignOps.

Using the right source of truth makes it inexplicably easier to maintain consistency between the works produced by different people among the team, helps to keep them aligned, and solves the right problems together with a joint set of tools. No more “detached symbols” with a handful of unsolicited variations.

At the bottom line, what we get are enormous time savings. Designers save their time by using the components with confidence and their functionalities coming out of the box. They don’t have to update the design files as the components change, nor document their work and “wave hands” to explain their visions to the rest of the team. Developers save time by getting the components from designers in an instantly digestible manner that doesn’t require guesswork and extra tinkering.

People responsible for testing and QA save time on hunting inconsistencies between designs and code and figuring out if implantation happened as intended. Stakeholders and other team members save time through more efficient management and easier navigation of such teams. Less friction and seamless processes limit frustration among team members.

Disadvantages

Taking advantage of these benefits comes at some entry costs though. To efficiently use tools such as UXPin in your process, you need to have an existing design system or components library in place. Alternatively, you can base your work on one of the open-source systems which would always provide some level of limitation.

However, if you are committed to building a design system in the first place, utilizing UXPin with Merge technology in your process would come at little to no additional cost. With a well-built design system, adopting UXPin should not be a struggle, whilst the benefits of such a shift might prove drastically.

Summary

Widespread adoption of design systems addressed the issues of the media developers and designers work with. Currently, we can observe a shift towards more unified processes that not only transform the medium but also the way we create it. Using the right tools is crucial to that change. UXPin with Merge technology is a design tool that allows combining design with live code components and drastically narrows the gap between the domains design and development operate in.

Where Next?

Articles on Smashing Magazine — For Web Designers And Developers

23 Jun

Designing With Code: A Modern Approach To Design (Development Challenges)

by TBSCategories: News

Friction in cooperation between designers and developers is fueling an ever-evolving discussion as old as the industry itself. We came a long way to where we are today. Our tools have changed. Our processes and methodologies have changed. But the underlying problems often remained the same.

One of the recurring problems I often tend to see, regardless of the type and size of the team, is maintaining a reliable source of truth. Even hiring the best people and using proven industry-standard solutions often leaves us to a distaste that something definitely could have been done better. The infamous “final version” is often spread across technical documentation, design files, spreadsheets, and other places. Keeping them all in sync is usually a tedious and daunting task.

Note: This article has been written in collaboration with the UXPin team. Examples presented in this article have been created in the UXPin app. Some of the features are only available on paid plans. The full overview of UXPin’s pricing can be found here.

The Problem With Design Tools

Talking of maintaining a source of truth, the inefficiency of design tools is often being indicated as one of the most wearing pain points. Modern design tools are evolving and they are evolving fast with tremendous efforts. But when it comes to building the bridge between design and development, it’s not rare to get the impression that many of those efforts are based on flawed assumptions.

Most of the modern design tools are based on different models than the technologies used to implement the designs later on. They are built as graphic editors and behave as such. The way layouts are built and processed in design tools is ultimately different from whatever CSS, JavaScript and other programming languages have to offer. Building user interfaces using vector (or even raster) graphics is constant guesswork of how and if what you make should be turned into code later.

Designers often end up lamenting about their creations not being implemented as intended. Even the bravest efforts towards pixel-perfect designs don’t solve all the problems. In design tools, it is close to impossible to imagine and cover all the possible cases. Supporting different states, changing copy, various viewport sizes, screen resolutions and so on, simply provide too many changing variables to cover them all.

On top of that come along some technical constraints and limitations. Being a designer without prior development experience, it is immensely hard to take all the technical factors into account. Remember all the possible states of inputs. Understand the limitations of browser support. Predict the performance implications of your work. Design for accessibility, at least in a sense much broader than color contrast and font sizes. Being aware of these challenges, we accept some amount of guesswork as a necessary evil.

But developers often have to depend on guesswork, too. User interfaces mocked up with graphics editors rarely answer all of their questions. Is it the same component as the one we already have, or not? Should I treat it as a different state or as a separate entity? How should this design behave when X, Y, or Z? Can we make it a bit differently as it would be faster and cheaper? Ironically, asking whoever created the designs in the first place is not always helpful. Not rarely, they don’t know either.

And usually, this is not where the scope of growing frustration ends. Because then, there’s also everyone else. Managers, stakeholders, team leaders, salespeople. With their attention and mental capacity stretched thin among all the tools and places where various parts of the product live, they struggle more than anyone else to get a good grasp of it.

Navigating prototypes, understanding why certain features and states are missing from the designs, and distinguishing between what is missing, what is a work in progress, and what has been consciously excluded from the scope feels almost impossible. Quickly iterating on what was already done, visualizing your feedback, and presenting your own ideas feels hardly possible, too. Ironically, more and more sophisticated tools and processes are aimed at designers and developers to work better together; they set the bar even higher, and active participation in the processes for other people even harder.

The Solutions

Countless heads of our industry have worked on tackling those problems resulting in new paradigms, tools, and concepts. And indeed a lot has changed for the better. Let’s take a quick look and what are some of the most common approaches towards the outlined challenges.

Coding Designers

“Should designers code?” is a cliché question discussed a countless number of times through articles, conference talks, and all other media with new voices in the discussion popping up with stable regularity now and then. There is a common assumption that if designers “knew how to code” (let’s not even start to dwell on how to define “knowing how to code” in the first place), it would be easier for them to craft designs that take the technological constraints into account and are easier to implement.

Some would go even further and say they should be taking an active role in the implementation. At that stage, it’s easy to jump to conclusions that it wouldn’t be without sense to skip using the design tools altogether and just “design in code”.

Tempting as the idea may sound, it rarely proves itself in reality. All the best coding designers I know are still using design tools. And that’s definitely not due to a lack of technical skills. To explain the why is important to highlight a difference between ideation, sketching, and building the actual thing.

As long as there are many valid use cases for “designing in code”, such as utilizing predefined styles and components to quickly build a fully functional interface without bothering yourselves with design tools at all, the promise of unconstrained visual freedom is offered by design tools still stands of undeniable value. Many people find sketching new ideas in a format offered by design tools easier and more suited for the nature of a creative process. And that is not going to change anytime soon. Design tools are here to stay and to stay for good.

Design Systems

The great mission of design systems, one of the greatest buzzwords of the digital design world in the last years, has always been exactly that: to limit guesswork and repetition, improve efficiency and maintainability, and unify sources of truth. Corporate systems such as Fluent or Material Design have done a lot of legwork in advocacy for the idea and bringing momentum to the adoption of the concept across both big and small players. And indeed, design systems helped to change a lot for the better. A more structured approach to developing a defined collection of design principles, patterns, and components helped countless companies to build better, more maintainable products.

Some challenges had not been solved straight away though. Designing design systems in popular design tools hampered the efforts of many in achieving a single source of truth. Instead, a plethora of systems has been created that, even though unified, still exist in two separate, incompatible sources: a design source and a development source. Maintaining mutual parity between the two usually proves to be a painful chore, repeating all the most hated pain points that design systems were trying to solve in the first place.

Design And Code Integrations

To solve the maintainability headaches of design systems another wave of solutions has soon arrived. Concepts such as design tokens have started to gain traction. Some were meant for syncing the state of code with designs, such as open APIs that allow fetching certain values straight from the design files. Others were meant for syncing the designs with code, e.g. by generating components in design tools from code.

Few of these ideas ever gained widespread adoption. This is most probably due to the questionable advantage of possible benefits over the necessary entry costs of still highly imperfect solutions. Translating designs automatically into code still poses immense challenges for most professional use cases. Solutions allowing you to merge existing code with designs have also been severely limited.

For example, none of the solutions allowing you to import coded components into design tools, even if visually true to the source, would fully replicate the behavior of such components. None until now.

Merging Design And Code With UXPin

UXPin, being a mature and fully-featured design app, is not a new player on the design tools stage. But its recent advancements, such as Merge technology, are what can change the odds of how we think about design and development tools.

UXPin with Merge technology allows us to bring real, live components into design by preserving both their visuals and functionality — all without writing a single line of code. The components, even though embedded in design files, shall behave exactly as their real counterparts — because they are their real counterparts. This allows us not only to achieve seamless parity between code and design but also to keep the two in uninterrupted sync.

UXPin supports design libraries of React components stored in git repositories as well as a robust integration with Storybook that allows usage of components from almost any popular front-end framework. If you’d like to give it a shot yourself, you can request access to it on the UXPin website:

Merging live components with designs in UXPin takes surprisingly few steps. After finding the right component, you can place it on the design canvas with a click. It will behave like any other object within your designs. What will make it special is that, even though being an integral part of the designs, you can now use and customize it the same as you would in code.

UXPin gives you access to the component’s properties, lets you change its values and variables, and fill it with your own data. Once starting the prototype, the component shall behave exactly as expected, maintaining all the behaviors and interactions.

Using a component “as is” also means that it should behave according to the change of the context, such as the width of the viewport. In other words, such components are fully responsive and adaptable.

Note: If you would like to learn more about building truly responsive designs with UXPin, I strongly encourage you to check out this article.

Context may also mean theming. Whoever tried to build (and maintain!) a themeable design system in a design tool, or at least create a system that allows you to easily switch between a light and a dark theme, knows how tricky of a task it is and how imperfect the results usually are. None of the design tools is well optimized for theming out of the box and available plugins aimed at solving that issue are far from solving it fully.

As UXPin with Merge technology uses real, live components, you can also theme them as real, live components. Not only can you create as many themes as you need, but switching them can be as quick as choosing the right theme from a dropdown. (You can read more about theme switching with UXPin here.)

Advantages

UXPin with Merge technology allows a level of parity between design and code rarely seen before. Being true to the source in a design process brings impeccable advantages for all sides of the process. Designers can design with confidence knowing that what they make will not get misinterpreted or wrongly developed. Developers do not have to translate the designs into code and muddle through inexplicit edge cases and uncovered scenarios. On top of that, everyone can participate in the work and quickly prototype their ideas using live components without any knowledge about the underlying code at all. Achieving more democratic, participatory processes is much more within reach.

Merging your design with code might not only improve how designers cooperate with the other constituents of the team, but also refine their internal processes and practices. UXPin with Merge technology can be a game-changer for those focused on optimization of design efforts at scale, sometimes referred to as DesignOps.

Using the right source of truth makes it inexplicably easier to maintain consistency between the works produced by different people among the team, helps to keep them aligned, and solves the right problems together with a joint set of tools. No more “detached symbols” with a handful of unsolicited variations.

At the bottom line, what we get are enormous time savings. Designers save their time by using the components with confidence and their functionalities coming out of the box. They don’t have to update the design files as the components change, nor document their work and “wave hands” to explain their visions to the rest of the team. Developers save time by getting the components from designers in an instantly digestible manner that doesn’t require guesswork and extra tinkering.

People responsible for testing and QA save time on hunting inconsistencies between designs and code and figuring out if implantation happened as intended. Stakeholders and other team members save time through more efficient management and easier navigation of such teams. Less friction and seamless processes limit frustration among team members.

Disadvantages

Taking advantage of these benefits comes at some entry costs though. To efficiently use tools such as UXPin in your process, you need to have an existing design system or components library in place. Alternatively, you can base your work on one of the open-source systems which would always provide some level of limitation.

However, if you are committed to building a design system in the first place, utilizing UXPin with Merge technology in your process would come at little to no additional cost. With a well-built design system, adopting UXPin should not be a struggle, whilst the benefits of such a shift might prove drastically.

Summary

Widespread adoption of design systems addressed the issues of the media developers and designers work with. Currently, we can observe a shift towards more unified processes that not only transform the medium but also the way we create it. Using the right tools is crucial to that change. UXPin with Merge technology is a design tool that allows combining design with live code components and drastically narrows the gap between the domains design and development operate in.

Where Next?

Articles on Smashing Magazine — For Web Designers And Developers

22 Jun

Designing With Code: A Modern Approach To Design (Development Challenges)

by TBSCategories: News

Friction in cooperation between designers and developers is fueling an ever-evolving discussion as old as the industry itself. We came a long way to where we are today. Our tools have changed. Our processes and methodologies have changed. But the underlying problems often remained the same.

One of the recurring problems I often tend to see, regardless of the type and size of the team, is maintaining a reliable source of truth. Even hiring the best people and using proven industry-standard solutions often leaves us to a distaste that something definitely could have been done better. The infamous “final version” is often spread across technical documentation, design files, spreadsheets, and other places. Keeping them all in sync is usually a tedious and daunting task.

Note: This article has been written in collaboration with the UXPin team. Examples presented in this article have been created in the UXPin app. Some of the features are only available on paid plans. The full overview of UXPin’s pricing can be found here.

The Problem With Design Tools

Talking of maintaining a source of truth, the inefficiency of design tools is often being indicated as one of the most wearing pain points. Modern design tools are evolving and they are evolving fast with tremendous efforts. But when it comes to building the bridge between design and development, it’s not rare to get the impression that many of those efforts are based on flawed assumptions.

Most of the modern design tools are based on different models than the technologies used to implement the designs later on. They are built as graphic editors and behave as such. The way layouts are built and processed in design tools is ultimately different from whatever CSS, JavaScript and other programming languages have to offer. Building user interfaces using vector (or even raster) graphics is constant guesswork of how and if what you make should be turned into code later.

Designers often end up lamenting about their creations not being implemented as intended. Even the bravest efforts towards pixel-perfect designs don’t solve all the problems. In design tools, it is close to impossible to imagine and cover all the possible cases. Supporting different states, changing copy, various viewport sizes, screen resolutions and so on, simply provide too many changing variables to cover them all.

On top of that come along some technical constraints and limitations. Being a designer without prior development experience, it is immensely hard to take all the technical factors into account. Remember all the possible states of inputs. Understand the limitations of browser support. Predict the performance implications of your work. Design for accessibility, at least in a sense much broader than color contrast and font sizes. Being aware of these challenges, we accept some amount of guesswork as a necessary evil.

But developers often have to depend on guesswork, too. User interfaces mocked up with graphics editors rarely answer all of their questions. Is it the same component as the one we already have, or not? Should I treat it as a different state or as a separate entity? How should this design behave when X, Y, or Z? Can we make it a bit differently as it would be faster and cheaper? Ironically, asking whoever created the designs in the first place is not always helpful. Not rarely, they don’t know either.

And usually, this is not where the scope of growing frustration ends. Because then, there’s also everyone else. Managers, stakeholders, team leaders, salespeople. With their attention and mental capacity stretched thin among all the tools and places where various parts of the product live, they struggle more than anyone else to get a good grasp of it.

Navigating prototypes, understanding why certain features and states are missing from the designs, and distinguishing between what is missing, what is a work in progress, and what has been consciously excluded from the scope feels almost impossible. Quickly iterating on what was already done, visualizing your feedback, and presenting your own ideas feels hardly possible, too. Ironically, more and more sophisticated tools and processes are aimed at designers and developers to work better together; they set the bar even higher, and active participation in the processes for other people even harder.

The Solutions

Countless heads of our industry have worked on tackling those problems resulting in new paradigms, tools, and concepts. And indeed a lot has changed for the better. Let’s take a quick look and what are some of the most common approaches towards the outlined challenges.

Coding Designers

“Should designers code?” is a cliché question discussed a countless number of times through articles, conference talks, and all other media with new voices in the discussion popping up with stable regularity now and then. There is a common assumption that if designers “knew how to code” (let’s not even start to dwell on how to define “knowing how to code” in the first place), it would be easier for them to craft designs that take the technological constraints into account and are easier to implement.

Some would go even further and say they should be taking an active role in the implementation. At that stage, it’s easy to jump to conclusions that it wouldn’t be without sense to skip using the design tools altogether and just “design in code”.

Tempting as the idea may sound, it rarely proves itself in reality. All the best coding designers I know are still using design tools. And that’s definitely not due to a lack of technical skills. To explain the why is important to highlight a difference between ideation, sketching, and building the actual thing.

As long as there are many valid use cases for “designing in code”, such as utilizing predefined styles and components to quickly build a fully functional interface without bothering yourselves with design tools at all, the promise of unconstrained visual freedom is offered by design tools still stands of undeniable value. Many people find sketching new ideas in a format offered by design tools easier and more suited for the nature of a creative process. And that is not going to change anytime soon. Design tools are here to stay and to stay for good.

Design Systems

The great mission of design systems, one of the greatest buzzwords of the digital design world in the last years, has always been exactly that: to limit guesswork and repetition, improve efficiency and maintainability, and unify sources of truth. Corporate systems such as Fluent or Material Design have done a lot of legwork in advocacy for the idea and bringing momentum to the adoption of the concept across both big and small players. And indeed, design systems helped to change a lot for the better. A more structured approach to developing a defined collection of design principles, patterns, and components helped countless companies to build better, more maintainable products.

Some challenges had not been solved straight away though. Designing design systems in popular design tools hampered the efforts of many in achieving a single source of truth. Instead, a plethora of systems has been created that, even though unified, still exist in two separate, incompatible sources: a design source and a development source. Maintaining mutual parity between the two usually proves to be a painful chore, repeating all the most hated pain points that design systems were trying to solve in the first place.

Design And Code Integrations

To solve the maintainability headaches of design systems another wave of solutions has soon arrived. Concepts such as design tokens have started to gain traction. Some were meant for syncing the state of code with designs, such as open APIs that allow fetching certain values straight from the design files. Others were meant for syncing the designs with code, e.g. by generating components in design tools from code.

Few of these ideas ever gained widespread adoption. This is most probably due to the questionable advantage of possible benefits over the necessary entry costs of still highly imperfect solutions. Translating designs automatically into code still poses immense challenges for most professional use cases. Solutions allowing you to merge existing code with designs have also been severely limited.

For example, none of the solutions allowing you to import coded components into design tools, even if visually true to the source, would fully replicate the behavior of such components. None until now.

Merging Design And Code With UXPin

UXPin, being a mature and fully-featured design app, is not a new player on the design tools stage. But its recent advancements, such as Merge technology, are what can change the odds of how we think about design and development tools.

UXPin with Merge technology allows us to bring real, live components into design by preserving both their visuals and functionality — all without writing a single line of code. The components, even though embedded in design files, shall behave exactly as their real counterparts — because they are their real counterparts. This allows us not only to achieve seamless parity between code and design but also to keep the two in uninterrupted sync.

UXPin supports design libraries of React components stored in git repositories as well as a robust integration with Storybook that allows usage of components from almost any popular front-end framework. If you’d like to give it a shot yourself, you can request access to it on the UXPin website:

Merging live components with designs in UXPin takes surprisingly few steps. After finding the right component, you can place it on the design canvas with a click. It will behave like any other object within your designs. What will make it special is that, even though being an integral part of the designs, you can now use and customize it the same as you would in code.

UXPin gives you access to the component’s properties, lets you change its values and variables, and fill it with your own data. Once starting the prototype, the component shall behave exactly as expected, maintaining all the behaviors and interactions.

Using a component “as is” also means that it should behave according to the change of the context, such as the width of the viewport. In other words, such components are fully responsive and adaptable.

Note: If you would like to learn more about building truly responsive designs with UXPin, I strongly encourage you to check out this article.

Context may also mean theming. Whoever tried to build (and maintain!) a themeable design system in a design tool, or at least create a system that allows you to easily switch between a light and a dark theme, knows how tricky of a task it is and how imperfect the results usually are. None of the design tools is well optimized for theming out of the box and available plugins aimed at solving that issue are far from solving it fully.

As UXPin with Merge technology uses real, live components, you can also theme them as real, live components. Not only can you create as many themes as you need, but switching them can be as quick as choosing the right theme from a dropdown. (You can read more about theme switching with UXPin here.)

Advantages

UXPin with Merge technology allows a level of parity between design and code rarely seen before. Being true to the source in a design process brings impeccable advantages for all sides of the process. Designers can design with confidence knowing that what they make will not get misinterpreted or wrongly developed. Developers do not have to translate the designs into code and muddle through inexplicit edge cases and uncovered scenarios. On top of that, everyone can participate in the work and quickly prototype their ideas using live components without any knowledge about the underlying code at all. Achieving more democratic, participatory processes is much more within reach.

Merging your design with code might not only improve how designers cooperate with the other constituents of the team, but also refine their internal processes and practices. UXPin with Merge technology can be a game-changer for those focused on optimization of design efforts at scale, sometimes referred to as DesignOps.

Using the right source of truth makes it inexplicably easier to maintain consistency between the works produced by different people among the team, helps to keep them aligned, and solves the right problems together with a joint set of tools. No more “detached symbols” with a handful of unsolicited variations.

At the bottom line, what we get are enormous time savings. Designers save their time by using the components with confidence and their functionalities coming out of the box. They don’t have to update the design files as the components change, nor document their work and “wave hands” to explain their visions to the rest of the team. Developers save time by getting the components from designers in an instantly digestible manner that doesn’t require guesswork and extra tinkering.

People responsible for testing and QA save time on hunting inconsistencies between designs and code and figuring out if implantation happened as intended. Stakeholders and other team members save time through more efficient management and easier navigation of such teams. Less friction and seamless processes limit frustration among team members.

Disadvantages

Taking advantage of these benefits comes at some entry costs though. To efficiently use tools such as UXPin in your process, you need to have an existing design system or components library in place. Alternatively, you can base your work on one of the open-source systems which would always provide some level of limitation.

However, if you are committed to building a design system in the first place, utilizing UXPin with Merge technology in your process would come at little to no additional cost. With a well-built design system, adopting UXPin should not be a struggle, whilst the benefits of such a shift might prove drastically.

Summary

Widespread adoption of design systems addressed the issues of the media developers and designers work with. Currently, we can observe a shift towards more unified processes that not only transform the medium but also the way we create it. Using the right tools is crucial to that change. UXPin with Merge technology is a design tool that allows combining design with live code components and drastically narrows the gap between the domains design and development operate in.

Where Next?

Articles on Smashing Magazine — For Web Designers And Developers

22 Jun

Designing With Code: A Modern Approach To Design (Development Challenges)

by TBSCategories: News

Friction in cooperation between designers and developers is fueling an ever-evolving discussion as old as the industry itself. We came a long way to where we are today. Our tools have changed. Our processes and methodologies have changed. But the underlying problems often remained the same.

One of the recurring problems I often tend to see, regardless of the type and size of the team, is maintaining a reliable source of truth. Even hiring the best people and using proven industry-standard solutions often leaves us to a distaste that something definitely could have been done better. The infamous “final version” is often spread across technical documentation, design files, spreadsheets, and other places. Keeping them all in sync is usually a tedious and daunting task.

Note: This article has been written in collaboration with the UXPin team. Examples presented in this article have been created in the UXPin app. Some of the features are only available on paid plans. The full overview of UXPin’s pricing can be found here.

The Problem With Design Tools

Talking of maintaining a source of truth, the inefficiency of design tools is often being indicated as one of the most wearing pain points. Modern design tools are evolving and they are evolving fast with tremendous efforts. But when it comes to building the bridge between design and development, it’s not rare to get the impression that many of those efforts are based on flawed assumptions.

Most of the modern design tools are based on different models than the technologies used to implement the designs later on. They are built as graphic editors and behave as such. The way layouts are built and processed in design tools is ultimately different from whatever CSS, JavaScript and other programming languages have to offer. Building user interfaces using vector (or even raster) graphics is constant guesswork of how and if what you make should be turned into code later.

Designers often end up lamenting about their creations not being implemented as intended. Even the bravest efforts towards pixel-perfect designs don’t solve all the problems. In design tools, it is close to impossible to imagine and cover all the possible cases. Supporting different states, changing copy, various viewport sizes, screen resolutions and so on, simply provide too many changing variables to cover them all.

On top of that come along some technical constraints and limitations. Being a designer without prior development experience, it is immensely hard to take all the technical factors into account. Remember all the possible states of inputs. Understand the limitations of browser support. Predict the performance implications of your work. Design for accessibility, at least in a sense much broader than color contrast and font sizes. Being aware of these challenges, we accept some amount of guesswork as a necessary evil.

But developers often have to depend on guesswork, too. User interfaces mocked up with graphics editors rarely answer all of their questions. Is it the same component as the one we already have, or not? Should I treat it as a different state or as a separate entity? How should this design behave when X, Y, or Z? Can we make it a bit differently as it would be faster and cheaper? Ironically, asking whoever created the designs in the first place is not always helpful. Not rarely, they don’t know either.

And usually, this is not where the scope of growing frustration ends. Because then, there’s also everyone else. Managers, stakeholders, team leaders, salespeople. With their attention and mental capacity stretched thin among all the tools and places where various parts of the product live, they struggle more than anyone else to get a good grasp of it.

Navigating prototypes, understanding why certain features and states are missing from the designs, and distinguishing between what is missing, what is a work in progress, and what has been consciously excluded from the scope feels almost impossible. Quickly iterating on what was already done, visualizing your feedback, and presenting your own ideas feels hardly possible, too. Ironically, more and more sophisticated tools and processes are aimed at designers and developers to work better together; they set the bar even higher, and active participation in the processes for other people even harder.

The Solutions

Countless heads of our industry have worked on tackling those problems resulting in new paradigms, tools, and concepts. And indeed a lot has changed for the better. Let’s take a quick look and what are some of the most common approaches towards the outlined challenges.

Coding Designers

“Should designers code?” is a cliché question discussed a countless number of times through articles, conference talks, and all other media with new voices in the discussion popping up with stable regularity now and then. There is a common assumption that if designers “knew how to code” (let’s not even start to dwell on how to define “knowing how to code” in the first place), it would be easier for them to craft designs that take the technological constraints into account and are easier to implement.

Some would go even further and say they should be taking an active role in the implementation. At that stage, it’s easy to jump to conclusions that it wouldn’t be without sense to skip using the design tools altogether and just “design in code”.

Tempting as the idea may sound, it rarely proves itself in reality. All the best coding designers I know are still using design tools. And that’s definitely not due to a lack of technical skills. To explain the why is important to highlight a difference between ideation, sketching, and building the actual thing.

As long as there are many valid use cases for “designing in code”, such as utilizing predefined styles and components to quickly build a fully functional interface without bothering yourselves with design tools at all, the promise of unconstrained visual freedom is offered by design tools still stands of undeniable value. Many people find sketching new ideas in a format offered by design tools easier and more suited for the nature of a creative process. And that is not going to change anytime soon. Design tools are here to stay and to stay for good.

Design Systems

The great mission of design systems, one of the greatest buzzwords of the digital design world in the last years, has always been exactly that: to limit guesswork and repetition, improve efficiency and maintainability, and unify sources of truth. Corporate systems such as Fluent or Material Design have done a lot of legwork in advocacy for the idea and bringing momentum to the adoption of the concept across both big and small players. And indeed, design systems helped to change a lot for the better. A more structured approach to developing a defined collection of design principles, patterns, and components helped countless companies to build better, more maintainable products.

Some challenges had not been solved straight away though. Designing design systems in popular design tools hampered the efforts of many in achieving a single source of truth. Instead, a plethora of systems has been created that, even though unified, still exist in two separate, incompatible sources: a design source and a development source. Maintaining mutual parity between the two usually proves to be a painful chore, repeating all the most hated pain points that design systems were trying to solve in the first place.

Design And Code Integrations

To solve the maintainability headaches of design systems another wave of solutions has soon arrived. Concepts such as design tokens have started to gain traction. Some were meant for syncing the state of code with designs, such as open APIs that allow fetching certain values straight from the design files. Others were meant for syncing the designs with code, e.g. by generating components in design tools from code.

Few of these ideas ever gained widespread adoption. This is most probably due to the questionable advantage of possible benefits over the necessary entry costs of still highly imperfect solutions. Translating designs automatically into code still poses immense challenges for most professional use cases. Solutions allowing you to merge existing code with designs have also been severely limited.

For example, none of the solutions allowing you to import coded components into design tools, even if visually true to the source, would fully replicate the behavior of such components. None until now.

Merging Design And Code With UXPin

UXPin, being a mature and fully-featured design app, is not a new player on the design tools stage. But its recent advancements, such as Merge technology, are what can change the odds of how we think about design and development tools.

UXPin with Merge technology allows us to bring real, live components into design by preserving both their visuals and functionality — all without writing a single line of code. The components, even though embedded in design files, shall behave exactly as their real counterparts — because they are their real counterparts. This allows us not only to achieve seamless parity between code and design but also to keep the two in uninterrupted sync.

UXPin supports design libraries of React components stored in git repositories as well as a robust integration with Storybook that allows usage of components from almost any popular front-end framework. If you’d like to give it a shot yourself, you can request access to it on the UXPin website:

Merging live components with designs in UXPin takes surprisingly few steps. After finding the right component, you can place it on the design canvas with a click. It will behave like any other object within your designs. What will make it special is that, even though being an integral part of the designs, you can now use and customize it the same as you would in code.

UXPin gives you access to the component’s properties, lets you change its values and variables, and fill it with your own data. Once starting the prototype, the component shall behave exactly as expected, maintaining all the behaviors and interactions.

Using a component “as is” also means that it should behave according to the change of the context, such as the width of the viewport. In other words, such components are fully responsive and adaptable.

Note: If you would like to learn more about building truly responsive designs with UXPin, I strongly encourage you to check out this article.

Context may also mean theming. Whoever tried to build (and maintain!) a themeable design system in a design tool, or at least create a system that allows you to easily switch between a light and a dark theme, knows how tricky of a task it is and how imperfect the results usually are. None of the design tools is well optimized for theming out of the box and available plugins aimed at solving that issue are far from solving it fully.

As UXPin with Merge technology uses real, live components, you can also theme them as real, live components. Not only can you create as many themes as you need, but switching them can be as quick as choosing the right theme from a dropdown. (You can read more about theme switching with UXPin here.)

Advantages

UXPin with Merge technology allows a level of parity between design and code rarely seen before. Being true to the source in a design process brings impeccable advantages for all sides of the process. Designers can design with confidence knowing that what they make will not get misinterpreted or wrongly developed. Developers do not have to translate the designs into code and muddle through inexplicit edge cases and uncovered scenarios. On top of that, everyone can participate in the work and quickly prototype their ideas using live components without any knowledge about the underlying code at all. Achieving more democratic, participatory processes is much more within reach.

Merging your design with code might not only improve how designers cooperate with the other constituents of the team, but also refine their internal processes and practices. UXPin with Merge technology can be a game-changer for those focused on optimization of design efforts at scale, sometimes referred to as DesignOps.

Using the right source of truth makes it inexplicably easier to maintain consistency between the works produced by different people among the team, helps to keep them aligned, and solves the right problems together with a joint set of tools. No more “detached symbols” with a handful of unsolicited variations.

At the bottom line, what we get are enormous time savings. Designers save their time by using the components with confidence and their functionalities coming out of the box. They don’t have to update the design files as the components change, nor document their work and “wave hands” to explain their visions to the rest of the team. Developers save time by getting the components from designers in an instantly digestible manner that doesn’t require guesswork and extra tinkering.

People responsible for testing and QA save time on hunting inconsistencies between designs and code and figuring out if implantation happened as intended. Stakeholders and other team members save time through more efficient management and easier navigation of such teams. Less friction and seamless processes limit frustration among team members.

Disadvantages

Taking advantage of these benefits comes at some entry costs though. To efficiently use tools such as UXPin in your process, you need to have an existing design system or components library in place. Alternatively, you can base your work on one of the open-source systems which would always provide some level of limitation.

However, if you are committed to building a design system in the first place, utilizing UXPin with Merge technology in your process would come at little to no additional cost. With a well-built design system, adopting UXPin should not be a struggle, whilst the benefits of such a shift might prove drastically.

Summary

Widespread adoption of design systems addressed the issues of the media developers and designers work with. Currently, we can observe a shift towards more unified processes that not only transform the medium but also the way we create it. Using the right tools is crucial to that change. UXPin with Merge technology is a design tool that allows combining design with live code components and drastically narrows the gap between the domains design and development operate in.

Where Next?

Articles on Smashing Magazine — For Web Designers And Developers

22 Jun

Designing With Code: A Modern Approach To Design (Development Challenges)

by TBSCategories: News

Friction in cooperation between designers and developers is fueling an ever-evolving discussion as old as the industry itself. We came a long way to where we are today. Our tools have changed. Our processes and methodologies have changed. But the underlying problems often remained the same.

One of the recurring problems I often tend to see, regardless of the type and size of the team, is maintaining a reliable source of truth. Even hiring the best people and using proven industry-standard solutions often leaves us to a distaste that something definitely could have been done better. The infamous “final version” is often spread across technical documentation, design files, spreadsheets, and other places. Keeping them all in sync is usually a tedious and daunting task.

Note: This article has been written in collaboration with the UXPin team. Examples presented in this article have been created in the UXPin app. Some of the features are only available on paid plans. The full overview of UXPin’s pricing can be found here.

The Problem With Design Tools

Talking of maintaining a source of truth, the inefficiency of design tools is often being indicated as one of the most wearing pain points. Modern design tools are evolving and they are evolving fast with tremendous efforts. But when it comes to building the bridge between design and development, it’s not rare to get the impression that many of those efforts are based on flawed assumptions.

Most of the modern design tools are based on different models than the technologies used to implement the designs later on. They are built as graphic editors and behave as such. The way layouts are built and processed in design tools is ultimately different from whatever CSS, JavaScript and other programming languages have to offer. Building user interfaces using vector (or even raster) graphics is constant guesswork of how and if what you make should be turned into code later.

Designers often end up lamenting about their creations not being implemented as intended. Even the bravest efforts towards pixel-perfect designs don’t solve all the problems. In design tools, it is close to impossible to imagine and cover all the possible cases. Supporting different states, changing copy, various viewport sizes, screen resolutions and so on, simply provide too many changing variables to cover them all.

On top of that come along some technical constraints and limitations. Being a designer without prior development experience, it is immensely hard to take all the technical factors into account. Remember all the possible states of inputs. Understand the limitations of browser support. Predict the performance implications of your work. Design for accessibility, at least in a sense much broader than color contrast and font sizes. Being aware of these challenges, we accept some amount of guesswork as a necessary evil.

But developers often have to depend on guesswork, too. User interfaces mocked up with graphics editors rarely answer all of their questions. Is it the same component as the one we already have, or not? Should I treat it as a different state or as a separate entity? How should this design behave when X, Y, or Z? Can we make it a bit differently as it would be faster and cheaper? Ironically, asking whoever created the designs in the first place is not always helpful. Not rarely, they don’t know either.

And usually, this is not where the scope of growing frustration ends. Because then, there’s also everyone else. Managers, stakeholders, team leaders, salespeople. With their attention and mental capacity stretched thin among all the tools and places where various parts of the product live, they struggle more than anyone else to get a good grasp of it.

Navigating prototypes, understanding why certain features and states are missing from the designs, and distinguishing between what is missing, what is a work in progress, and what has been consciously excluded from the scope feels almost impossible. Quickly iterating on what was already done, visualizing your feedback, and presenting your own ideas feels hardly possible, too. Ironically, more and more sophisticated tools and processes are aimed at designers and developers to work better together; they set the bar even higher, and active participation in the processes for other people even harder.

The Solutions

Countless heads of our industry have worked on tackling those problems resulting in new paradigms, tools, and concepts. And indeed a lot has changed for the better. Let’s take a quick look and what are some of the most common approaches towards the outlined challenges.

Coding Designers

“Should designers code?” is a cliché question discussed a countless number of times through articles, conference talks, and all other media with new voices in the discussion popping up with stable regularity now and then. There is a common assumption that if designers “knew how to code” (let’s not even start to dwell on how to define “knowing how to code” in the first place), it would be easier for them to craft designs that take the technological constraints into account and are easier to implement.

Some would go even further and say they should be taking an active role in the implementation. At that stage, it’s easy to jump to conclusions that it wouldn’t be without sense to skip using the design tools altogether and just “design in code”.

Tempting as the idea may sound, it rarely proves itself in reality. All the best coding designers I know are still using design tools. And that’s definitely not due to a lack of technical skills. To explain the why is important to highlight a difference between ideation, sketching, and building the actual thing.

As long as there are many valid use cases for “designing in code”, such as utilizing predefined styles and components to quickly build a fully functional interface without bothering yourselves with design tools at all, the promise of unconstrained visual freedom is offered by design tools still stands of undeniable value. Many people find sketching new ideas in a format offered by design tools easier and more suited for the nature of a creative process. And that is not going to change anytime soon. Design tools are here to stay and to stay for good.

Design Systems

The great mission of design systems, one of the greatest buzzwords of the digital design world in the last years, has always been exactly that: to limit guesswork and repetition, improve efficiency and maintainability, and unify sources of truth. Corporate systems such as Fluent or Material Design have done a lot of legwork in advocacy for the idea and bringing momentum to the adoption of the concept across both big and small players. And indeed, design systems helped to change a lot for the better. A more structured approach to developing a defined collection of design principles, patterns, and components helped countless companies to build better, more maintainable products.

Some challenges had not been solved straight away though. Designing design systems in popular design tools hampered the efforts of many in achieving a single source of truth. Instead, a plethora of systems has been created that, even though unified, still exist in two separate, incompatible sources: a design source and a development source. Maintaining mutual parity between the two usually proves to be a painful chore, repeating all the most hated pain points that design systems were trying to solve in the first place.

Design And Code Integrations

To solve the maintainability headaches of design systems another wave of solutions has soon arrived. Concepts such as design tokens have started to gain traction. Some were meant for syncing the state of code with designs, such as open APIs that allow fetching certain values straight from the design files. Others were meant for syncing the designs with code, e.g. by generating components in design tools from code.

Few of these ideas ever gained widespread adoption. This is most probably due to the questionable advantage of possible benefits over the necessary entry costs of still highly imperfect solutions. Translating designs automatically into code still poses immense challenges for most professional use cases. Solutions allowing you to merge existing code with designs have also been severely limited.

For example, none of the solutions allowing you to import coded components into design tools, even if visually true to the source, would fully replicate the behavior of such components. None until now.

Merging Design And Code With UXPin

UXPin, being a mature and fully-featured design app, is not a new player on the design tools stage. But its recent advancements, such as Merge technology, are what can change the odds of how we think about design and development tools.

UXPin with Merge technology allows us to bring real, live components into design by preserving both their visuals and functionality — all without writing a single line of code. The components, even though embedded in design files, shall behave exactly as their real counterparts &mdah; because they are their real counterparts. This allows us not only to achieve seamless parity between code and design but also to keep the two in uninterrupted sync.

UXPin supports design libraries of React components stored in git repositories as well as a robust integration with Storybook that allows usage of components from almost any popular front-end framework. If you’d like to give it a shot yourself, you can request access to it on the UXPin website:

Merging live components with designs in UXPin takes surprisingly few steps. After finding the right component, you can place it on the design canvas with a click. It will behave like any other object within your designs. What will make it special is that, even though being an integral part of the designs, you can now use and customize it the same as you would in code.

UXPin gives you access to the component’s properties, lets you change its values and variables, and fill it with your own data. Once starting the prototype, the component shall behave exactly as expected, maintaining all the behaviors and interactions.

Using a component “as is” also means that it should behave according to the change of the context, such as the width of the viewport. In other words, such components are fully responsive and adaptable.

Note: If you would like to learn more about building truly responsive designs with UXPin, I strongly encourage you to check out this article.

Context may also mean theming. Whoever tried to build (and maintain!) a themeable design system in a design tool, or at least create a system that allows you to easily switch between a light and a dark theme, knows how tricky of a task it is and how imperfect the results usually are. None of the design tools is well optimized for theming out of the box and available plugins aimed at solving that issue are far from solving it fully.

As UXPin with Merge technology uses real, live components, you can also theme them as real, live components. Not only can you create as many themes as you need, but switching them can be as quick as choosing the right theme from a dropdown. (You can read more about theme switching with UXPin here.)

Advantages

UXPin with Merge technology allows a level of parity between design and code rarely seen before. Being true to the source in a design process brings impeccable advantages for all sides of the process. Designers can design with confidence knowing that what they make will not get misinterpreted or wrongly developed. Developers do not have to translate the designs into code and muddle through inexplicit edge cases and uncovered scenarios. On top of that, everyone can participate in the work and quickly prototype their ideas using live components without any knowledge about the underlying code at all. Achieving more democratic, participatory processes is much more within reach.

Merging your design with code might not only improve how designers cooperate with the other constituents of the team, but also refine their internal processes and practices. UXPin with Merge technology can be a game-changer for those focused on optimization of design efforts at scale, sometimes referred to as DesignOps.

Using the right source of truth makes it inexplicably easier to maintain consistency between the works produced by different people among the team, helps to keep them aligned, and solves the right problems together with a joint set of tools. No more “detached symbols” with a handful of unsolicited variations.

At the bottom line, what we get are enormous time savings. Designers save their time by using the components with confidence and their functionalities coming out of the box. They don’t have to update the design files as the components change, nor document their work and “wave hands” to explain their visions to the rest of the team. Developers save time by getting the components from designers in an instantly digestible manner that doesn’t require guesswork and extra tinkering.

People responsible for testing and QA save time on hunting inconsistencies between designs and code and figuring out if implantation happened as intended. Stakeholders and other team members save time through more efficient management and easier navigation of such teams. Less friction and seamless processes limit frustration among team members.

Disadvantages

Taking advantage of these benefits comes at some entry costs though. To efficiently use tools such as UXPin in your process, you need to have an existing design system or components library in place. Alternatively, you can base your work on one of the open-source systems which would always provide some level of limitation.

However, if you are committed to building a design system in the first place, utilizing UXPin with Merge technology in your process would come at little to no additional cost. With a well-built design system, adopting UXPin should not be a struggle, whilst the benefits of such a shift might prove drastically.

Summary

Widespread adoption of design systems addressed the issues of the media developers and designers work with. Currently, we can observe a shift towards more unified processes that not only transform the medium but also the way we create it. Using the right tools is crucial to that change. UXPin with Merge technology is a design tool that allows combining design with live code components and drastically narrows the gap between the domains design and development operate in.

Where Next?

Articles on Smashing Magazine — For Web Designers And Developers

10 Dec

How To Overcome Data Onboarding Challenges For Software Products

by TBSCategories: News

Companies willing to pay good money for a new piece of software are most likely not starting from scratch. They’re running an established business, with well-built and documented processes. So, they have tons of data to carry over.

As a result, the decision to bring a new app into the fold is not one they take lightly. Internal processes need to change. Getting the team to adopt the new solution can take time. Integrating it with existing systems and external tools can be a problem. Oh yeah, and there’s the matter of compliance to worry about, too.

This means there’s a lot of pressure on new software to provide a top-notch experience from the get-go. Fail to provide companies with a simple and intuitive way to onboard their data and you can expect high rates of customer churn as a result.

If you’re designing a product that needs data from customers in order to be of any value, here’s what you need to know about building out your data onboarding process.

How Data Onboarding Correlates With User Satisfaction

Business software is essentially just an empty box waiting to be filled with its users’ data. Without the ability to flawlessly onboard users’ data, the software essentially becomes useless.

Let’s look at what happens when you get the data onboarding process right.

End User Benefits

If you can nail the data onboarding piece, expect your end users to reap the following benefits:

  • They’ll be more confident in their decision.
    With complete and accurate data transferred into your software, users actually see how valuable it is soon after signing up. This leaves little room for second-guessing their decision, which leads to greater satisfaction overall with the product, and ultimately more money for your business.
  • You’ll get greater team buy-in.
    A positive data onboarding experience lets customers use your product faster, reducing the time needed for them to get value. So, really, data onboarding sets the stage for how your customers and their team will view the rest of your app.
  • They’ll experience more success with the software.
    Since users won’t have to stress about data formatting and cleanup or troubleshooting error-ridden import processes, they can get more out of the product and its features.

Software Developer Benefits

The software provider (you and/or your client) benefits, too:

  • Improve user satisfaction.
    Your end users don’t need to be technical wizards to figure out how to onboard data into your product. When you make light work of this, you reduce churn, attract more users and retain more loyal users over the long-term.
  • Spend less time on customer service.
    You can stop worrying about having to support a faulty data onboarding process as well as taking over tasks like data formatting and validation for your users. Instead, put your time and energy towards building better relationships with customers instead of putting out fires all the time.
    Kelly Abbott, Co-Founder and CTO of Tablecloth, can attest to this:

    “We have cut the amount of time we spend wrangling with files by 95%. We basically had all hands working to solve those problems at times.”

  • Have greater confidence in your product.
    When you have a data onboarding solution that’s flexible and powerful, you don’t have to restrict what data your users can or can’t import. It’s no longer a limitation.
    As Abbott explains:

    “It has made us more contemplative about the data we are asking clients for. We no longer have to avoid asking for data that may require too much time to fix. Flatfile eliminates that problem and has improved our willingness to experiment with different types of data we can incorporate into our analyses. The more time we spend tinkering with different data types, the more likely we are going to uncover the insight that produces additional value in the marketplace. That is indispensable for a startup like us.”

  • Save money.
    Although you’ll have to spend money on a third-party data onboarding solution, you’ll save your company the time and money otherwise spent trying to manage a custom-built data importer, onboarding process and client relationships. (Tablecloth, for instance, saved tens of thousands of dollars when they adopted Flatfile.)

The Challenges Of Data Onboarding For Software Products

Let’s have a look at the common challenges in data onboarding and how Flatfile Concierge removes them:

Challenge #1: There’s A Lot Of Data To Aggregate

When signing up for new business software, users probably expect to do a little work upfront, like filling in basic account information, configuring settings and adding users. The last thing you want to do is surprise them with a data importer that’s going to cause more work for them.

Let’s say, for example, you’ve built a CRM.

Unless the software targets startups and other new businesses, users are going to have a ton of external data to bring along. For instance:

  • Contact info for clients, prospects, vendors, partners and team members;
  • Existing customer data like account and sales history;
  • Prospect data like communication history;
  • Sales pipeline details;
  • Team and individual goals and metrics.

Unless your CRM directly integrates with every one of your users’ previous CRMs, how are they going to move this data over? Copy and paste? CSV templates?

Concierge allows companies to import ‘data model’ templates based on spreadsheet columns for easy setup. Customers would then import data that automatically matches this model with no code needed. (Image source: Flatfile)

Plus, you have to think about all of the other sources a CRM pulls info in from. Payment gateways. Spreadsheets that live on a sales team’s drive. Signed contracts that have been emailed or faxed to your company. There’s a lot of data coming from different places and people.

The Fix

There are a number of things Flatfile Concierge does to fix this problem.

For starters, it allows data to be imported from a variety of file types:

  • CSV,
  • TSV,
  • XLS,
  • XML,
  • And more.

With this kind of flexibility, your users won’t have to worry about transferring data to one specific file type and then cleaning up errors that occur during the transfer. Flatfile Concierge can handle various file types, of varying data types, and easily validate it all.

Another thing to think about is how your software is going to track and organize each imported file and its corresponding data.

What Flatfile allows your users to do is create collaborative workspaces to place data in. When a team member adds new data to the workspace, a record is captured containing the:

  • Date of upload,
  • File name,
  • User who submitted the data,
  • Number of rows added,
  • Version history,
  • Upload errors.

Flatfile Concierge animation demonstrating notifications for when spreadsheets are imported. (Image source: Flatfile)

This will keep things organized while also keeping everyone accountable to the data they contribute. And with this information readily available from a centralized dashboard, there’ll be no secret as to what’s been uploaded, by whom and when. Import errors can also be fixed collaboratively, without the need to re-upload spreadsheet data.

Challenge #2: Data Is Imported In A Variety Of States

When you give your software users the ability to transfer their data into your product, there’s not a lot you or the software team can do in terms of formatting or cleaning up end users’ data beforehand. Nor should you have to. Your job is to ensure customers see the value in the software; not to struggle with importing data.

You could give them a spreadsheet template, but that would require them to spend time reformatting all their data. You could point them to the knowledgebase, but, again, that assumes that your end users will be willing to do that extra work.

In reality, your users are going to be in a hurry to get inside the new software and get to work. They’re not going to stop to deal with this. That’s the software’s job.

However, many data onboarding solutions don’t handle messy spreadsheets very well. Not only do they have a hard time recognizing what some of the data is (often because the data model doesn’t match their own), but then the application refuses to accept certain spreadsheet columns.

Even if it’s the end user’s fault for not properly organizing or labeling their data or teaching their team how to do so (or just not knowing what to do in the first place), who do you think they’re going to blame in the end when their data won’t import?

The Fix

Flatfile Concierge’s importer is AI-powered, which means that your software (and data importer) really can do the work for your end users.

Using advanced validation logic, the data importer can figure out what the data is and where it goes.

While Flatfile will automatically match columns and corresponding data to your software’s actual data fields, users get a chance to confirm that’s the case before allowing it into the system:

Before this happens, you can do a little work on the backend to ensure that Flatfile knows what to do with your users’ data:

  • Create target data models so Flatfile can navigate complex spreadsheet formats and datatypes your users will likely try to import.
  • Create a template with validation rules so Flatfile’s AI knows exactly how to map everything out.
  • Validate imported data against other databases to help the importer contextualize, validate and clean up the data over time.

Once you’ve done that upfront work, the rest is easy.

The bulk of the work will be done by Flatfile Concierge when it transforms imported data into something clean and useful. In fact, about 95% of imported columns will automatically map to your software thanks to Flatfile’s machine learning and fuzzy matching system.

The end user will have the opportunity to review the parts of their data that contain errors. If they find any, they can repair the errors inside Flatfile, rather than have to fix it in a spreadsheet and re-import.

Challenge #3: Getting And Tracking Data From Multiple Users

When there are a lot of cooks in the kitchen, there are a number of things that can go wrong.

Data can sometimes live on team members’ computers, or worse, sent over email, which can be a huge security concern for sensitive data. This can happen if users aren’t given access to the software platform or find the data importer too intimidating to use.

On the flip side of that, with the wrong data onboarding process, it could become like a free-for-all where people add whatever the heck they like to the company’s data. While the data does get imported, there’s no review framework so the company’s database is filled with errors and duplicate entries.

Your end users need to be able to maintain order, control and security when dealing with something as serious as company data — especially if you want your software to be usable.

The Fix

Flatfile Concierge has designed the data onboarding process to be a collaborative one.

As you can see, company admins can invite specific collaborators (i.e. customers) to add data to their workspaces. But this isn’t a blanket invitation to import data.

Admins have the ability to create an approval process. They get to:

  • Ask for specific data sets from team members.
  • Control which workspaces they’re allowed to import data to.
  • Review all data submissions before flowing the approved data into the platform.

Admins can also import data on the customer’s behalf. Flatfile Concierge ensures that data onboarding is never a dead-end for customers.

Not only does this ensure that the right data ends up in the software, but the controlled flow means the data will end up being cleaner and more accurate, too. All of this, while providing a seamless data onboarding experience for users.

Challenge #4: Data Security Is Always A Concern

When it comes to web and app development, user privacy and security are top priority. If our customers and visitors don’t trust that their information is safe from prying eyes (and isn’t being sold off to advertisers), they’re going to stop using our solutions in the first place.

The same thing happens with software — though it’s not just the company’s personal data they have to worry about securing.

Often, when companies import data into software (like the CRM example), they’re importing their customers’ private and sensitive data. Allow that to be compromised and you can kiss your software goodbye.

So, yes, the software itself needs to be secured. That’s a given. But so, too, does your data onboarding process. It’s a huge point of vulnerability if left unchecked.

The Fix

The first thing Flatfile Concierge does is to encourage users to move away from sharing sensitive data over email, FTP, and other unsecured platforms by providing a user-friendly data onboarding solution.

The second thing it does is provide an authenticated and compliant workspace for users to import, validate, and post their data to your software.

Here’s how Flatfile Concierge secures its workspaces:

  • Each collaborator enters the data importer through an authenticated invitation.
  • Data is encrypted in transit and stored in an encrypted Amazon S3 bucket.
  • The data onboarding platform is 100% GDPR compliant.
  • Flatfile is HIPAA and SOC2 compliant and can adjust for other compliance requirements as needed.

In addition, once data is successfully migrated into your application, it’s deleted from Flatfile. This way, you only have to worry about securing your data within your software and not on previous platforms it’s touched.

Wrapping Up

With an insufficient or error-prone data onboarding process, you, the software provider and its end users are going to spend too much time manually cleaning and validating spreadsheets. This won’t just happen during the initial user signup either. If the data importer isn’t up to the task, you’re all going to be throwing away a ton of time and resources every time data needs to be uploaded or transferred into the platform from existing customers.

Of course, this all assumes that your importer can even get user data into the software. (Sadly, this happens with too many custom-built solutions.)

Needless to say: Your data onboarding process must be flawless for your team and customers. It’s the only way to keep user churn rates low and user satisfaction high.

Data onboarding is a really complex process to handle. Save yourself the trouble in trying to develop your own data onboarding solution and the time trying to troubleshoot the problems with it. With an AI-powered data importer like Flatfile Concierge, everything’s taken care of for you.

Articles on Smashing Magazine — For Web Designers And Developers

09 Dec

How To Overcome Data Onboarding Challenges For Software Products

by TBSCategories: News

Companies willing to pay good money for a new piece of software are most likely not starting from scratch. They’re running an established business, with well-built and documented processes. So, they have tons of data to carry over.

As a result, the decision to bring a new app into the fold is not one they take lightly. Internal processes need to change. Getting the team to adopt the new solution can take time. Integrating it with existing systems and external tools can be a problem. Oh yeah, and there’s the matter of compliance to worry about, too.

This means there’s a lot of pressure on new software to provide a top-notch experience from the get-go. Fail to provide companies with a simple and intuitive way to onboard their data and you can expect high rates of customer churn as a result.

If you’re designing a product that needs data from customers in order to be of any value, here’s what you need to know about building out your data onboarding process.

How Data Onboarding Correlates With User Satisfaction

Business software is essentially just an empty box waiting to be filled with its users’ data. Without the ability to flawlessly onboard users’ data, the software essentially becomes useless.

Let’s look at what happens when you get the data onboarding process right.

End User Benefits

If you can nail the data onboarding piece, expect your end users to reap the following benefits:

  • They’ll be more confident in their decision.
    With complete and accurate data transferred into your software, users actually see how valuable it is soon after signing up. This leaves little room for second-guessing their decision, which leads to greater satisfaction overall with the product, and ultimately more money for your business.
  • You’ll get greater team buy-in.
    A positive data onboarding experience lets customers use your product faster, reducing the time needed for them to get value. So, really, data onboarding sets the stage for how your customers and their team will view the rest of your app.
  • They’ll experience more success with the software.
    Since users won’t have to stress about data formatting and cleanup or troubleshooting error-ridden import processes, they can get more out of the product and its features.

Software Developer Benefits

The software provider (you and/or your client) benefits, too:

  • Improve user satisfaction.
    Your end users don’t need to be technical wizards to figure out how to onboard data into your product. When you make light work of this, you reduce churn, attract more users and retain more loyal users over the long-term.
  • Spend less time on customer service.
    You can stop worrying about having to support a faulty data onboarding process as well as taking over tasks like data formatting and validation for your users. Instead, put your time and energy towards building better relationships with customers instead of putting out fires all the time.
    Kelly Abbott, Co-Founder and CTO of Tablecloth, can attest to this:

    “We have cut the amount of time we spend wrangling with files by 95%. We basically had all hands working to solve those problems at times.”

  • Have greater confidence in your product.
    When you have a data onboarding solution that’s flexible and powerful, you don’t have to restrict what data your users can or can’t import. It’s no longer a limitation.
    As Abbott explains:

    “It has made us more contemplative about the data we are asking clients for. We no longer have to avoid asking for data that may require too much time to fix. Flatfile eliminates that problem and has improved our willingness to experiment with different types of data we can incorporate into our analyses. The more time we spend tinkering with different data types, the more likely we are going to uncover the insight that produces additional value in the marketplace. That is indispensable for a startup like us.”

  • Save money.
    Although you’ll have to spend money on a third-party data onboarding solution, you’ll save your company the time and money otherwise spent trying to manage a custom-built data importer, onboarding process and client relationships. (Tablecloth, for instance, saved tens of thousands of dollars when they adopted Flatfile.)

The Challenges Of Data Onboarding For Software Products

Let’s have a look at the common challenges in data onboarding and how Flatfile Concierge removes them:

Challenge #1: There’s A Lot Of Data To Aggregate

When signing up for new business software, users probably expect to do a little work upfront, like filling in basic account information, configuring settings and adding users. The last thing you want to do is surprise them with a data importer that’s going to cause more work for them.

Let’s say, for example, you’ve built a CRM.

Unless the software targets startups and other new businesses, users are going to have a ton of external data to bring along. For instance:

  • Contact info for clients, prospects, vendors, partners and team members;
  • Existing customer data like account and sales history;
  • Prospect data like communication history;
  • Sales pipeline details;
  • Team and individual goals and metrics.

Unless your CRM directly integrates with every one of your users’ previous CRMs, how are they going to move this data over? Copy and paste? CSV templates?

Concierge allows companies to import ‘data model’ templates based on spreadsheet columns for easy setup. Customers would then import data that automatically matches this model with no code needed. (Image source: Flatfile)

Plus, you have to think about all of the other sources a CRM pulls info in from. Payment gateways. Spreadsheets that live on a sales team’s drive. Signed contracts that have been emailed or faxed to your company. There’s a lot of data coming from different places and people.

The Fix

There are a number of things Flatfile Concierge does to fix this problem.

For starters, it allows data to be imported from a variety of file types:

  • CSV,
  • TSV,
  • XLS,
  • XML,
  • And more.

With this kind of flexibility, your users won’t have to worry about transferring data to one specific file type and then cleaning up errors that occur during the transfer. Flatfile Concierge can handle various file types, of varying data types, and easily validate it all.

Another thing to think about is how your software is going to track and organize each imported file and its corresponding data.

What Flatfile allows your users to do is create collaborative workspaces to place data in. When a team member adds new data to the workspace, a record is captured containing the:

  • Date of upload,
  • File name,
  • User who submitted the data,
  • Number of rows added,
  • Version history,
  • Upload errors.

Flatfile Concierge animation demonstrating notifications for when spreadsheets are imported. (Image source: Flatfile)

This will keep things organized while also keeping everyone accountable to the data they contribute. And with this information readily available from a centralized dashboard, there’ll be no secret as to what’s been uploaded, by whom and when. Import errors can also be fixed collaboratively, without the need to re-upload spreadsheet data.

Challenge #2: Data Is Imported In A Variety Of States

When you give your software users the ability to transfer their data into your product, there’s not a lot you or the software team can do in terms of formatting or cleaning up end users’ data beforehand. Nor should you have to. Your job is to ensure customers see the value in the software; not to struggle with importing data.

You could give them a spreadsheet template, but that would require them to spend time reformatting all their data. You could point them to the knowledgebase, but, again, that assumes that your end users will be willing to do that extra work.

In reality, your users are going to be in a hurry to get inside the new software and get to work. They’re not going to stop to deal with this. That’s the software’s job.

However, many data onboarding solutions don’t handle messy spreadsheets very well. Not only do they have a hard time recognizing what some of the data is (often because the data model doesn’t match their own), but then the application refuses to accept certain spreadsheet columns.

Even if it’s the end user’s fault for not properly organizing or labeling their data or teaching their team how to do so (or just not knowing what to do in the first place), who do you think they’re going to blame in the end when their data won’t import?

The Fix

Flatfile Concierge’s importer is AI-powered, which means that your software (and data importer) really can do the work for your end users.

Using advanced validation logic, the data importer can figure out what the data is and where it goes.

While Flatfile will automatically match columns and corresponding data to your software’s actual data fields, users get a chance to confirm that’s the case before allowing it into the system:

Before this happens, you can do a little work on the backend to ensure that Flatfile knows what to do with your users’ data:

  • Create target data models so Flatfile can navigate complex spreadsheet formats and datatypes your users will likely try to import.
  • Create a template with validation rules so Flatfile’s AI knows exactly how to map everything out.
  • Validate imported data against other databases to help the importer contextualize, validate and clean up the data over time.

Once you’ve done that upfront work, the rest is easy.

The bulk of the work will be done by Flatfile Concierge when it transforms imported data into something clean and useful. In fact, about 95% of imported columns will automatically map to your software thanks to Flatfile’s machine learning and fuzzy matching system.

The end user will have the opportunity to review the parts of their data that contain errors. If they find any, they can repair the errors inside Flatfile, rather than have to fix it in a spreadsheet and re-import.

Challenge #3: Getting And Tracking Data From Multiple Users

When there are a lot of cooks in the kitchen, there are a number of things that can go wrong.

Data can sometimes live on team members’ computers, or worse, sent over email, which can be a huge security concern for sensitive data. This can happen if users aren’t given access to the software platform or find the data importer too intimidating to use.

On the flip side of that, with the wrong data onboarding process, it could become like a free-for-all where people add whatever the heck they like to the company’s data. While the data does get imported, there’s no review framework so the company’s database is filled with errors and duplicate entries.

Your end users need to be able to maintain order, control and security when dealing with something as serious as company data — especially if you want your software to be usable.

The Fix

Flatfile Concierge has designed the data onboarding process to be a collaborative one.

As you can see, company admins can invite specific collaborators (i.e. customers) to add data to their workspaces. But this isn’t a blanket invitation to import data.

Admins have the ability to create an approval process. They get to:

  • Ask for specific data sets from team members.
  • Control which workspaces they’re allowed to import data to.
  • Review all data submissions before flowing the approved data into the platform.

Admins can also import data on the customer’s behalf. Flatfile Concierge ensures that data onboarding is never a dead-end for customers.

Not only does this ensure that the right data ends up in the software, but the controlled flow means the data will end up being cleaner and more accurate, too. All of this, while providing a seamless data onboarding experience for users.

Challenge #4: Data Security Is Always A Concern

When it comes to web and app development, user privacy and security are top priority. If our customers and visitors don’t trust that their information is safe from prying eyes (and isn’t being sold off to advertisers), they’re going to stop using our solutions in the first place.

The same thing happens with software — though it’s not just the company’s personal data they have to worry about securing.

Often, when companies import data into software (like the CRM example), they’re importing their customers’ private and sensitive data. Allow that to be compromised and you can kiss your software goodbye.

So, yes, the software itself needs to be secured. That’s a given. But so, too, does your data onboarding process. It’s a huge point of vulnerability if left unchecked.

The Fix

The first thing Flatfile Concierge does is to encourage users to move away from sharing sensitive data over email, FTP, and other unsecured platforms by providing a user-friendly data onboarding solution.

The second thing it does is provide an authenticated and compliant workspace for users to import, validate, and post their data to your software.

Here’s how Flatfile Concierge secures its workspaces:

  • Each collaborator enters the data importer through an authenticated invitation.
  • Data is encrypted in transit and stored in an encrypted Amazon S3 bucket.
  • The data onboarding platform is 100% GDPR compliant.
  • Flatfile is HIPAA and SOC2 compliant and can adjust for other compliance requirements as needed.

In addition, once data is successfully migrated into your application, it’s deleted from Flatfile. This way, you only have to worry about securing your data within your software and not on previous platforms it’s touched.

Wrapping Up

With an insufficient or error-prone data onboarding process, you, the software provider and its end users are going to spend too much time manually cleaning and validating spreadsheets. This won’t just happen during the initial user signup either. If the data importer isn’t up to the task, you’re all going to be throwing away a ton of time and resources every time data needs to be uploaded or transferred into the platform from existing customers.

Of course, this all assumes that your importer can even get user data into the software. (Sadly, this happens with too many custom-built solutions.)

Needless to say: Your data onboarding process must be flawless for your team and customers. It’s the only way to keep user churn rates low and user satisfaction high.

Data onboarding is a really complex process to handle. Save yourself the trouble in trying to develop your own data onboarding solution and the time trying to troubleshoot the problems with it. With an AI-powered data importer like Flatfile Concierge, everything’s taken care of for you.

Articles on Smashing Magazine — For Web Designers And Developers

09 Dec

How To Overcome Data Onboarding Challenges For Software Products

by TBSCategories: News

Companies willing to pay good money for a new piece of software are most likely not starting from scratch. They’re running an established business, with well-built and documented processes. So, they have tons of data to carry over.

As a result, the decision to bring a new app into the fold is not one they take lightly. Internal processes need to change. Getting the team to adopt the new solution can take time. Integrating it with existing systems and external tools can be a problem. Oh yeah, and there’s the matter of compliance to worry about, too.

This means there’s a lot of pressure on new software to provide a top-notch experience from the get-go. Fail to provide companies with a simple and intuitive way to onboard their data and you can expect high rates of customer churn as a result.

If you’re designing a product that needs data from customers in order to be of any value, here’s what you need to know about building out your data onboarding process.

How Data Onboarding Correlates With User Satisfaction

Business software is essentially just an empty box waiting to be filled with its users’ data. Without the ability to flawlessly onboard users’ data, the software essentially becomes useless.

Let’s look at what happens when you get the data onboarding process right.

End User Benefits

If you can nail the data onboarding piece, expect your end users to reap the following benefits:

  • They’ll be more confident in their decision.
    With complete and accurate data transferred into your software, users actually see how valuable it is soon after signing up. This leaves little room for second-guessing their decision, which leads to greater satisfaction overall with the product, and ultimately more money for your business.
  • You’ll get greater team buy-in.
    A positive data onboarding experience lets customers use your product faster, reducing the time needed for them to get value. So, really, data onboarding sets the stage for how your customers and their team will view the rest of your app.
  • They’ll experience more success with the software.
    Since users won’t have to stress about data formatting and cleanup or troubleshooting error-ridden import processes, they can get more out of the product and its features.

Software Developer Benefits

The software provider (you and/or your client) benefits, too:

  • Improve user satisfaction.
    Your end users don’t need to be technical wizards to figure out how to onboard data into your product. When you make light work of this, you reduce churn, attract more users and retain more loyal users over the long-term.
  • Spend less time on customer service.
    You can stop worrying about having to support a faulty data onboarding process as well as taking over tasks like data formatting and validation for your users. Instead, put your time and energy towards building better relationships with customers instead of putting out fires all the time.
    Kelly Abbott, Co-Founder and CTO of Tablecloth, can attest to this:

    “We have cut the amount of time we spend wrangling with files by 95%. We basically had all hands working to solve those problems at times.”

  • Have greater confidence in your product.
    When you have a data onboarding solution that’s flexible and powerful, you don’t have to restrict what data your users can or can’t import. It’s no longer a limitation.
    As Abbott explains:

    “It has made us more contemplative about the data we are asking clients for. We no longer have to avoid asking for data that may require too much time to fix. Flatfile eliminates that problem and has improved our willingness to experiment with different types of data we can incorporate into our analyses. The more time we spend tinkering with different data types, the more likely we are going to uncover the insight that produces additional value in the marketplace. That is indispensable for a startup like us.”

  • Save money.
    Although you’ll have to spend money on a third-party data onboarding solution, you’ll save your company the time and money otherwise spent trying to manage a custom-built data importer, onboarding process and client relationships. (Tablecloth, for instance, saved tens of thousands of dollars when they adopted Flatfile.)

The Challenges Of Data Onboarding For Software Products

Let’s have a look at the common challenges in data onboarding and how Flatfile Concierge removes them:

Challenge #1: There’s A Lot Of Data To Aggregate

When signing up for new business software, users probably expect to do a little work upfront, like filling in basic account information, configuring settings and adding users. The last thing you want to do is surprise them with a data importer that’s going to cause more work for them.

Let’s say, for example, you’ve built a CRM.

Unless the software targets startups and other new businesses, users are going to have a ton of external data to bring along. For instance:

  • Contact info for clients, prospects, vendors, partners and team members;
  • Existing customer data like account and sales history;
  • Prospect data like communication history;
  • Sales pipeline details;
  • Team and individual goals and metrics.

Unless your CRM directly integrates with every one of your users’ previous CRMs, how are they going to move this data over? Copy and paste? CSV templates?

Concierge allows companies to import ‘data model’ templates based on spreadsheet columns for easy setup. Customers would then import data that automatically matches this model with no code needed. (Image source: Flatfile)

Plus, you have to think about all of the other sources a CRM pulls info in from. Payment gateways. Spreadsheets that live on a sales team’s drive. Signed contracts that have been emailed or faxed to your company. There’s a lot of data coming from different places and people.

The Fix

There are a number of things Flatfile Concierge does to fix this problem.

For starters, it allows data to be imported from a variety of file types:

  • CSV,
  • TSV,
  • XLS,
  • XML,
  • And more.

With this kind of flexibility, your users won’t have to worry about transferring data to one specific file type and then cleaning up errors that occur during the transfer. Flatfile Concierge can handle various file types, of varying data types, and easily validate it all.

Another thing to think about is how your software is going to track and organize each imported file and its corresponding data.

What Flatfile allows your users to do is create collaborative workspaces to place data in. When a team member adds new data to the workspace, a record is captured containing the:

  • Date of upload,
  • File name,
  • User who submitted the data,
  • Number of rows added,
  • Version history,
  • Upload errors.

Flatfile Concierge animation demonstrating notifications for when spreadsheets are imported. (Image source: Flatfile)

This will keep things organized while also keeping everyone accountable to the data they contribute. And with this information readily available from a centralized dashboard, there’ll be no secret as to what’s been uploaded, by whom and when. Import errors can also be fixed collaboratively, without the need to re-upload spreadsheet data.

Challenge #2: Data Is Imported In A Variety Of States

When you give your software users the ability to transfer their data into your product, there’s not a lot you or the software team can do in terms of formatting or cleaning up end users’ data beforehand. Nor should you have to. Your job is to ensure customers see the value in the software; not to struggle with importing data.

You could give them a spreadsheet template, but that would require them to spend time reformatting all their data. You could point them to the knowledgebase, but, again, that assumes that your end users will be willing to do that extra work.

In reality, your users are going to be in a hurry to get inside the new software and get to work. They’re not going to stop to deal with this. That’s the software’s job.

However, many data onboarding solutions don’t handle messy spreadsheets very well. Not only do they have a hard time recognizing what some of the data is (often because the data model doesn’t match their own), but then the application refuses to accept certain spreadsheet columns.

Even if it’s the end user’s fault for not properly organizing or labeling their data or teaching their team how to do so (or just not knowing what to do in the first place), who do you think they’re going to blame in the end when their data won’t import?

The Fix

Flatfile Concierge’s importer is AI-powered, which means that your software (and data importer) really can do the work for your end users.

Using advanced validation logic, the data importer can figure out what the data is and where it goes.

While Flatfile will automatically match columns and corresponding data to your software’s actual data fields, users get a chance to confirm that’s the case before allowing it into the system:

Before this happens, you can do a little work on the backend to ensure that Flatfile knows what to do with your users’ data:

  • Create target data models so Flatfile can navigate complex spreadsheet formats and datatypes your users will likely try to import.
  • Create a template with validation rules so Flatfile’s AI knows exactly how to map everything out.
  • Validate imported data against other databases to help the importer contextualize, validate and clean up the data over time.

Once you’ve done that upfront work, the rest is easy.

The bulk of the work will be done by Flatfile Concierge when it transforms imported data into something clean and useful. In fact, about 95% of imported columns will automatically map to your software thanks to Flatfile’s machine learning and fuzzy matching system.

The end user will have the opportunity to review the parts of their data that contain errors. If they find any, they can repair the errors inside Flatfile, rather than have to fix it in a spreadsheet and re-import.

Challenge #3: Getting And Tracking Data From Multiple Users

When there are a lot of cooks in the kitchen, there are a number of things that can go wrong.

Data can sometimes live on team members’ computers, or worse, sent over email, which can be a huge security concern for sensitive data. This can happen if users aren’t given access to the software platform or find the data importer too intimidating to use.

On the flip side of that, with the wrong data onboarding process, it could become like a free-for-all where people add whatever the heck they like to the company’s data. While the data does get imported, there’s no review framework so the company’s database is filled with errors and duplicate entries.

Your end users need to be able to maintain order, control and security when dealing with something as serious as company data — especially if you want your software to be usable.

The Fix

Flatfile Concierge has designed the data onboarding process to be a collaborative one.

As you can see, company admins can invite specific collaborators (i.e. customers) to add data to their workspaces. But this isn’t a blanket invitation to import data.

Admins have the ability to create an approval process. They get to:

  • Ask for specific data sets from team members.
  • Control which workspaces they’re allowed to import data to.
  • Review all data submissions before flowing the approved data into the platform.

Admins can also import data on the customer’s behalf. Flatfile Concierge ensures that data onboarding is never a dead-end for customers.

Not only does this ensure that the right data ends up in the software, but the controlled flow means the data will end up being cleaner and more accurate, too. All of this, while providing a seamless data onboarding experience for users.

Challenge #4: Data Security Is Always A Concern

When it comes to web and app development, user privacy and security are top priority. If our customers and visitors don’t trust that their information is safe from prying eyes (and isn’t being sold off to advertisers), they’re going to stop using our solutions in the first place.

The same thing happens with software — though it’s not just the company’s personal data they have to worry about securing.

Often, when companies import data into software (like the CRM example), they’re importing their customers’ private and sensitive data. Allow that to be compromised and you can kiss your software goodbye.

So, yes, the software itself needs to be secured. That’s a given. But so, too, does your data onboarding process. It’s a huge point of vulnerability if left unchecked.

The Fix

The first thing Flatfile Concierge does is to encourage users to move away from sharing sensitive data over email, FTP, and other unsecured platforms by providing a user-friendly data onboarding solution.

The second thing it does is provide an authenticated and compliant workspace for users to import, validate, and post their data to your software.

Here’s how Flatfile Concierge secures its workspaces:

  • Each collaborator enters the data importer through an authenticated invitation.
  • Data is encrypted in transit and stored in an encrypted Amazon S3 bucket.
  • The data onboarding platform is 100% GDPR compliant.
  • Flatfile is HIPAA and SOC2 compliant and can adjust for other compliance requirements as needed.

In addition, once data is successfully migrated into your application, it’s deleted from Flatfile. This way, you only have to worry about securing your data within your software and not on previous platforms it’s touched.

Wrapping Up

With an insufficient or error-prone data onboarding process, you, the software provider and its end users are going to spend too much time manually cleaning and validating spreadsheets. This won’t just happen during the initial user signup either. If the data importer isn’t up to the task, you’re all going to be throwing away a ton of time and resources every time data needs to be uploaded or transferred into the platform from existing customers.

Of course, this all assumes that your importer can even get user data into the software. (Sadly, this happens with too many custom-built solutions.)

Needless to say: Your data onboarding process must be flawless for your team and customers. It’s the only way to keep user churn rates low and user satisfaction high.

Data onboarding is a really complex process to handle. Save yourself the trouble in trying to develop your own data onboarding solution and the time trying to troubleshoot the problems with it. With an AI-powered data importer like Flatfile Concierge, everything’s taken care of for you.

Articles on Smashing Magazine — For Web Designers And Developers

Newer postsOlder posts
×

Powered by WhatsApp Chat

WhatsApp Chat is free, download and try it now here!

× Chat with Us