Developers will utilize open-source components as a base start and means to save development time and effort on the feature they are trying to build. These components would typically be found in a public code repository that is shared on the web. As a designer it is your responsibility to ensure the component is robust and aligns with your experience principles and meets user’s needs to fulfill a task.
Mission
To ensure that open-source components comply with your user experience and functional requirements, implement an evaluation process that validates their viability.
Step 1
Design your desired UI
Don’t let a component inhibit your creativity or limit your desired experience. Design your ideal UI first, prioritize your functions, micro-interactions, and workflows, then scale down based on the component's capabilities.
If you take a component-first approach to defining your UX, you will compromise usability and fall short of an optimal user experience.
Make sure the manifestation of using an open-source is derived from your designs and only used as a basis for development foundation and not as a UI alternative.
Step 2
Evaluate multiple component options
Along with your PM and devs, evaluate the various component options, if any, that would best serve your feature requirement needs.
Determine if each component’s capabilities can match your desired workflows, micro-interactions, functions, and UI customizations.
Development should run a POC to see if the components are safe, secure, and have robust code to back it.
Step 3
Choose the best option
Choose the one that works best from a UX and development standpoint: low cost, low efforts, low maintenance, high gains, and scalability.
The purpose of the component is to save your team the time to develop it.
It should also have a long lifespan and longevity so it isn’t ideally throw away work.
Ensure the component will not contribute to design debt, which leads to tech debt, defeating the purpose of utilizing a component in the first place.
Step 4
Evaluate the design heuristics
Do a thorough heuristics evaluation on the component.
Check to see if the component is optimized for ADA compliancy: it supports accessibility functions like alt-text, screen reader translations, etc.
Check to see if the component provides the necessary design interactions: button states, usability, etc.
Step 5
Customize the component
Customize the component to your company or product’s brand style.
Ensure the component is aligned with your design system language: colors, button style, text styles, and overall look and feel.
The component must appear as integrated, uniform, and seamless in your system, and not appear as a sore thumb or as an apparent plugin that is differentiated from the rest of the system.
Step 6
Design for edge cases and error cases
Ensure you account for all the possible edge cases and error cases that may occur in the user workflow utilizing the component.
Ensure the component can handle these cases through affordances and feedback: state changes, messaging, and visual cues.
Design error handling solutions within the component that is consistent with the rest of your system.
Step 7
Evaluate responsiveness
Ensure the component is extensible and scalable across different contexts in your system and is responsive for various screen sizes.
Test against various devices, browser window sizes, and different scenarios in which the component may be used (full screen vs contained views).
Evaluate the layout, size, text readability, tap targets, and micro-interactions in various screen sizes and workflow contexts.
Step 8
Implement and test
Test the component with users.
Testing should be executed through various phases of your evaluation process for usability and viability. This should be done in concept testing to beta testing.
At this phase in the process, you are ensuring the component is implemented and integrated into your system correctly, and satisfies your UI objectives and user goals.
Case study
A component for rule building in conversational design flows
This component is used for building complex rules that determine variable pathways dependent on the user's status, state, condition, or attributes. This is generally used for "if this, then that" conditional logic building for bots.
Here was the original concept we mocked up based on technical, workflow, and user requirements.
These were the basic features we needed to support for rule building: multiple condition creation, entity selection, operator selection, and a value text field for free-form text input. The example shown here reflects this scenario: the bot will show a response based on if the user is on a specific website and is not from California.
Here is an open-source react component that a developer had insisted we leveraged for our product.
We evaluated the functionality, mapped its features to our user and workflow requirements, and tested with users. The component offered a lot more functionality and controls than we needed, but was fully customizable allowing us to hide, replace, and position features appropriately.
After further analysis and customization, here is what the implementation looked like.
We customized the component with our branded product visual language, using our design system components, icons, and text styles, making it appear and function fully integrated as part of our tool. Utilizing the open-source component reduce our time and effort to develop. It was boot strapped with capabilities like responsiveness, adaptability, consistency, and reuse.
Outcomes and KPIs
Adapting a fully customizable open-source component into our systems saved our product team a substantial amount of development and design time and efforts. Without the component, we would have been required to build from the ground up. The previous scope for basic functional requirements of an original component would have taken a total of 15 days (3 full sprints) for development. Leveraging an existing open-source component only required a total of 5 days (only 1 sprint) to test, validate, integrate, and customize. This is a 67% decrease in development time. The component offered advanced features that we would have required long term. These additional features would have taken an additional 1-2 more sprints to develop. Features we got for free and the scalability of the component that can be used in other tools, wouldn't require more development and design time.
Summary
Evaluate your open-source components with an extensive review process.
Do your due diligence before it’s too late and you're stuck with a component that doesn't satisfy your product needs and user goals.
Work with the developers to ensure there is an understanding on product requirements and a joint evaluation of the component.
Align the component with your product look and feel.
About the author
Sean Lazo is a Principal UX Designer at [24]7.ai who leads the inception, assembly, and design of [24]7.ai Conversations, an industry-leading omni-channel AI chatbot SAAS platform. His passions are DesignOps, detailed design, research, and human relations.
ความคิดเห็น