menu

UXPin

Design, prototyping and design systems solution chosen by the best teams.

Channels
# All channels
view-forward
# General
view-forward
# Announcements
view-forward
# Feature requests
view-forward
# Help
view-forward
# Before you post
view-forward
# Learn
view-forward
Team

Component states in design system, anyone?

March 27, 2020 at 8:39pm
The UXPin community has a new home. This thread is preserved for historical purposes. The content of this conversation may be innaccurrate or out of date. Go to new community home →

Component states in design system, anyone?

March 27, 2020 at 8:39pm
Hi.
In my (highly distributed) team we are considering adopting UXpin and abandon our more or less bumpy handover process from design to development. One of the reasons for doing this is our need for a robust design system/style guide that both designers and developers can use actively. We are playing around in UXpin now, and along the quirks we bump into is one of component states not making it into the design style guide/system.
Has anyone any experience with a design system that does not define a component's appearance and behaviour in various states?
We were all enthusiastic about the statefulness in UXpin, and equally disappointed not seeing them as equally native parts of the design system derived from our experiments.
Anyone?

March 27, 2020 at 9:04pm
I want to see if I'm capturing this... You make a UXPin component that has multiple states and when you add it to a Design System it doesn't retain those states?
  • reply
  • like
Im not sure i understand the ask or challenge you’re experiencing. Could you either explain further or provide a detailed example?
  • reply
  • like
Were the states created before the component was added to the library? Or was the component edited in the Master edit mode and the changed were pushed to the library? Please share a further explanation, so we can understand it better and help you
Edited
like-fill
1
  • reply
  • like

March 28, 2020 at 8:28am
Hi. Yes, . and : Before I even looked into the Design system functionality, I had made a radio button with several states and toggle switch with a few states . However, when going into the design system, only the default (selected) state displays. See attached screenshot from design system.
Your responses makes it all seem a little more promising; do I have to do something special to make a component's states appear in the design system? Or isn't it possible?
Edited
  • reply
  • like
  • reply
  • like
And here is the radio button and its states.
  • reply
  • like
  • reply
  • like
Sorry, I am new to this. Here are the states for the toggle switch.
  • reply
  • like
Without having access to an actual prototype or an exported uxp file i can assume that you have several states that are based on multiple conditions - if x is true AND y is true then set state component to z.
Eg: onClick, if button state is ENABLED AND current state is OFF, then set state to ON (enabled), else set state to OFF (enabled).
To demo this as component this may be require conditional statements that would be dependent on additional elements that you wouldn’t include in a component - like a micro prototype within the component just to demonstrate the available states. Again, I’m basing this off assumptions since i only have to reference Ad oppose to a prototype example or an expired uxp file.
I would recommend trying the following. - make your component simpler by reducing it to an enabled- state component AND a disabled-state component or separate disabled ON and disabled OFF state components since a disabled toggle switch would not be clickable by a user in the real world.
  • this would help to reduce the complexity of the component interactions
  • use nextState interaction or setState interactions to specify an specific state.
eg: for enabled state component State: Off onClick set to nextState or onClick set to stateName(“on”)
eg: for disabled state component State: Off onClick set to nextState or onClick set to stateName(“on”)
These component interactions would always be at the component level. You can always add additional interactions to the component at canvas level.
You could then have conditional logic in your prototype that controls both the enabled and disabled state components by possible using the “toggle” interaction which toggles the display state of targeted elements. So when the “enabled” switch component is in the ON state, you also set the “disabled” toggle switch component to the ON state but always have it hidden until the condition is met to SHOW the “disabled” toggle component and hide the “enabeled” toggle switch component. Does this make sense?
You could include documentation for a component detail in your design system to indicate how it should be used in UXPin prototypes by team members and what development code libraries, functions, or variables to set should be used by developers when they are actually building a project.
I always caution teams that UXPin is NOT a development so dont approach it as such, especially if they are thinking like a developer when when building UXPin prototypes. UXPin wont be able to mimic a real-world development platform with code functions and complex conditional logic and such. Use UXPin to tell the story as close as possible knowing its limitations as a prototyping platform.
I hope this helps.
Edited
  • reply
  • like

March 28, 2020 at 3:44pm
Interesting, . I thought the design system was generated purely on visuals, and not interactions defined within the components? Having said that, the components in question are groups of elements, where the states are set on the group so that the whole component is stateful, and not just parts of it (for example label and the interactive input control). Does this affect state definitions in the design system? (I'll try it out a little myself…).
  • reply
  • like
Update: Sorry folks, it was me who didn't understand the UXpin design system. I found out that the states are actually there (in the design system), but fairly well hidden behind "inspect" and "layers" (or by clicking part of the component and then "stepping up" to the component). I didn't expect this, but rather a visual representation of the states side-by-side in the design system so it would be easy to see (and document) the different states of a component.
But that may be a feature request, then. Unless there are good reasons for not showing and documenting / describing the various states of a component?
Edited
  • reply
  • like
Good afternoon Here's a quick prototype I created to illustrate a on/off multi-state component that can also be set to disabled and enabled states.
  • reply
  • like
If you'd like to download the UXPin file to import and analyze, visit: https://danielchaparro.egnyte.com/fl/q5Ejwpvrik/Multi-Statewith_Enabled_and_Disabled_States
  • reply
  • like
'I thought the design system was generated purely on visuals, and not interactions' This is a common misconception.
The UXPin design system is very robust and can store interactive elements in addition to static visuals and color swatches from your project. Components can be anything that you want to use repeatedly throughout a project. A component is not a style guide where you would show various states of an object for team guidance. They can be static visuals and elements (text) as well as interactive with previews to allow others to see how the interactive component would work. Try to understand how components work and how to set them up for use in a design system. Again, don't look at UXPin as a development platform. Its not intended as that or designed to work that way - at the movement anyway. Its value is helping designers to visualize designs and create interactive prototypes to help clients and teams understand how a design would work.
Visit UXPin Docs site and read Design Systems https://www.uxpin.com/docs/design-systems/design-systems
Good luck with your project and let me know if you have any questions regarding my prototype.
The UXPin team here are fairly responsive and extremely helpful with questions and challenges the community has.
Edited
like-fill
1
  • reply
  • like

March 30, 2020 at 5:54am
'I thought the design system was generated purely on visuals, and not interactions' This is a common misconception.
The UXPin design system is very robust and can store interactive elements in addition to static visuals and color swatches from your project. Components can be anything that you want to use repeatedly throughout a project. A component is not a style guide where you would show various states of an object for team guidance. They can be static visuals and elements (text) as well as interactive with previews to allow others to see how the interactive component would work. Try to understand how components work and how to set them up for use in a design system. Again, don't look at UXPin as a development platform. Its not intended as that or designed to work that way - at the movement anyway. Its value is helping designers to visualize designs and create interactive prototypes to help clients and teams understand how a design would work.
Visit UXPin Docs site and read Design Systems https://www.uxpin.com/docs/design-systems/design-systems
Good luck with your project and let me know if you have any questions regarding my prototype.
The UXPin team here are fairly responsive and extremely helpful with questions and challenges the community has.
This is great. Just one comment on the switch interaction. It would be great if I can interact with switch by clicking/touching anywhere on the entire switch instead of that "circle" . But that was just a suggestion. This was really great and showcases how powerful the nested interactive states are and what possibilities it opens up!
  • reply
  • like

March 30, 2020 at 3:43pm
Thanks for highlighting issue with the switch in my prototype, but as I mentioned previously this was a quick Prototype to help assist and his team with challenges they were experiencing understanding how components and design systems work in UXPin. In my normal practice the entire switch is set to be clickable/tappable.
like-fill
1
  • reply
  • like
let the community here know if you still need help understanding how to create and use components and design systems UXPin.
  • reply
  • like
I should clarify a statement I made previously. A component is not a style guide where you would show various states of an object for team guidance. They can be static visuals and elements (text) as well as interactive with previews to allow others to see how the interactive component would work.
I should have clarified that… A component is not a style guide element where you would show various states of an object for team guidance. but rather a design system is where you would store static or interactive components that are repeatedly used in your projects to ensure visual and interaction consistency.
Difference Between a Design System and a Style Guide A style guide is the static documentation - the rules and guidelines, which describes how to use your design system which is more robust and includes everything that goes into ensuring your team uses tested and approved elements for use in your projects. https://www.uxpin.com/studio/blog/design-systems-vs-pattern-libraries-vs-style-guides-whats-difference/
If you follow or know about the Atomic Design approach, your design system is made up of the atoms, molecules, organisms, and templates which may be your components to create pages. For more about Atomic Design visit: https://atomicdesign.bradfrost.com https://atomicdesign.bradfrost.com/chapter-2/
Interactive components in the UXPin design system will automatically have an option to "preview" the interactive aspects of the component such as onHover, onClick, etc… triggers and any behaviors that are self-contained within the component such as color changes, animations, etc…
The preview of a component in your UXPin Design System will not show external triggers or behaviors that can be assigned when the component is added to and used in your project. For example having an onClick trigger to set the content of another object or component contained WITHIN your project. You can add additional interactions to your base component such as specifying the content of another element/component or project variable value as I've did in the prototype to show true (1) and false (0) state of the switches being disabled.
I hope this clarifies my previous comment. Apologies for any confusion it may have had.
Edited
  • reply
  • like

April 1, 2020 at 7:55am
Hi . I've read the UXPin article, as well as the downloadable PDF behind it. I don't know if I am the only one (that could very well be the case), but as a tool for designers in their work I had the impression that a design system documents and includes styles, assets and patterns/components (and even templates, when relevant) for use by designers as well as developers. With the intent of ensuring consistency in the GUIs based on the design system. It would be my humble opinion then, that a visual representation of anything that can appear in the GUI would be native to anything in the design system. How else can a designer or developer verify that the "thing" used in a GUI will look consistent across the board? Does (s)he solely have to trust the people who put things into the design system? What if a component doesn't have a state, because it wasn't required until project X suddenly needs it; how would project X know that before the developer cries out?
Edited
  • reply
  • like
Regarding prototyping, I don't find it that hard; I've been doing fairly advanced interactions in Axure for ten years. I do find that UXPin has some way to go before reaching Axure's level in the interactions arena (multiple actions for a trigger is perhaps the most obvious, but repeaters and styleable native HTML input controls are other examples). But UXPin outperforms Axure in other areas, particularly documentation and, ehm, well, Design System.
  • reply
  • like
In short, what is included in your design system should have already gone through a vetting process with your governing team. This is how everyone knows how the system and the its components work.
Maybe you could share a link to your design system or screencast, pic etc…so that the community can understand how youve structured your design system.
UXPin’s design system will automatically generate an interactive preview of components that users can interact with to see how the component works, another method to ensure and verify that your designers and developers understand how the parts of the components. So this should answer your question as to how can anyone using your design system will be assured that the component or element will look consistent throughout your design.
When and if a component needs to be updated because new scenarios require it to be updated then you would go through the same proposal and vetting process for any updates to existing components or additions to your design system. You could either update the existing component or add a new component to your design system.
So to answer your question: “What if a component doesn't have a state, because it wasn't required until project X suddenly needs it; how would project X know that before the developer cries out?” I would ask… Wouldn't the design/dev team perform a review of the project requirements to determine which design system components, ui patterns, and templates would be used before any development is started?
You need to have a communication process in place that allows the team to respond to any needs to update the design system, not react to plugging a gap in the system when you're already in development.
And if it was determined that there was a gap - a deficiency in your design system, then you would go through the process of proposing either an update or new addition to your design system. This is how you could respond, not react, to continual updates to your design system.
You do have the ability to modify auto-generated pages and author new pages in your design system to explain how assets and components should be used with supporting images and small prototypes showing specific states of components if the need exists to do so. That’s totally dependent on the proficiency of your team or client. Remember that UXPin's design system is simply a tool and resource to aggregate and communicate how design assets and components should be used in a project. It doesn’t replace the continuing process and requirement of team leads and leaders communicating what the design system is, why and how it should be used, and what is new or updated in it. The design system is a continually evolving resource that needs to be designed to communicate as effectively as possible to its audience.
Edited
  • reply
  • like
Here are two screen recordings that demonstrate how I've structured a design system for a client. Unfortunately I can't provide access to the design system, but these two snippets should give you an idea of how I use UXPin's design systems or when I have to create my own for specific client projects.
Edited
  • reply
  • like
  • reply
  • like
  • reply
  • like
Show more messages