Greetings to our ever-growing community: People of JUX community! Your active participation and dedication warms our hearts. It underscores that we're addressing a tangible pain many experience daily.
A recent discussion in one of our chats sparked some enlightening conversations. A product manager mentioned wanting to use our product to make "small, really minor adjustments, a tweak at the UI" and then measure the resulting change. Given our platform's unique ability to allow designers to tweak code, he thought this would be achievable.
This seemingly simple statement created quite a buzz in our chat. It made us reflect deeply on the holistic implications of such "minor" adjustments. And when you stop to consider the numerous parties involved throughout a product's lifecycle, you realize why. So, what does tweaking just one UI component really entail? Allow me to explain.
The Domino Component
Imagine the consequences of an unreadable input field or an unreadable button on your conversion rate if you have a broken input field. In most cases, these issues do not just affect the user experience; they can also have serious implications on the bottom line of a business as they can impact conversion rates. However, there is a long way to go and lots of ripples can be made along the way to get that issue fixed. PM’s Designers, Developers and other squad members must work together - and sometimes the decision to make the modification does not come so easily.
The Bigger Picture 🖼️ Impacts on a Much Broader Scale
When we realize a change to the UI is needed, even to a single component, it's like throwing a stone into a pond. The ripples it creates can be expansive.
Every persona creates a new ripple, bringing new thoughts and ideas to the table. These generate more and more ripples.
Here are several ripple-effect examples:
Designers
- User Interface Design - What changes will have to be made after changing this one component?
- Design Principles - Does this change the design guidelines? Should it? Is it general or specific?
- Design tokens - Don’t get me started… But 🤷♂️
- Prototypes - Really? Should we run this with our clients? But what if we are B2C? Should we still beta this with some users?
- Accessibility - Without it - the business just cannot work. We have to keep this in mind 🧠
Developers
- Code updates - Is it in a package? Are we maintaining this?
- Refactoring - How will the page change? Should he have a new kick-off?
- Front-end adjustments
- Design token synchronization - This again… and storybook
- Will our data change? Should we look at the analytics differently?
- Ensuring resource optimization - Does this involve DevOps?
- Q&A sessions
Shared ripples for both development and design
- Feedback loops - we have to review this again.
- Updating guidelines to reflect changes
Ripples for other parties in the organization
- Allocating additional hours for training
- Updating FAQ sections
- Revising user manuals
In a Component’s Nutshell
So, about that earlier discussion – it went on for a bit, but what we figured out is that what we do at JUX is really about minimizing the negative ripple effect. We're all about creating a design environment where changes don't set off a whole chain reaction of extra work and time for other teams. Through JUX, designers have access to a platform, a language, that ensures that the ripple of changing one component does not disrupt the flow, maintaining a smooth and pleasant experience without causing unnecessary stress or 'rocking the boat.'
A button state of mind (with ripples 🌊)
