60 Developers, 5 Development Leads, 14 Product Owners, 3 Countries, 2 VP's, all needed to be on the same page
about the user experience for the product and have a resource for new teams as they are spun up.
1. Teams are siloed and blind to cross development.
2. User focus is non-existent.
3. Each team has it's own set of standards and interpretations.
4. No consensus on workflow, data presentation, or interaction sets.
1. Outline UX standards and usage guidelines to consolidate effort and draw teams together.
2. Develop atomic UX components that are reused across teams.
3. Prioritize the process, highlight critical data, remove cognitive overload.
4. Build resources for teams to reference to reduce meeting fatigue.
There are data objects that will be displayed in rows. Each object will have optional attributes that help the user understand more about this object. A split button to the right will allow for multiple actions. Icons will be used to illustrate state and type of data object.
The interaction model for the data row will allow for the row to be clickable and expand a child row to display a summary of detail pertaining to the object. The actions from the split button will open in a tray or "quick edit" fashion.
Content layers had to be defined to allow the team to understand where you put types of elements. If the team devs, and PO's knew how to layer a page, this would prevent modal fatigue and force simplification over adding unnecessary items.
Next, the team, and particularly the devs, needed to follow a path of combined thought as to how the user navigates through a workflow. To help them understand the process, thinking was aligned to Git Flow branching principles.
Each user component needed to be reusable. If a user accesses an allergy, regardless of context or location in the application, the allergy should be presented in the same fashion. This approach to components opens the door for simple deductive logic in use cases.
Consistency across the application will impact every aspect of the build process. Users will become quicker, developers will code faster, and PO's will be able to create stories with little guidance
Language inside user stories was a tell to the success that a common core for UX interactions was causing throughout the teams.
"Call the tray component when the user clicks..." or "Display the data row after..."
These allowed teams and developers to speak and understand one another effectively.
Teams began to own a component after they developed it for use. When it needed to be updated or revised they "owner" would spend time with the new team to help get the component up to par and remain its interoperability.
When a larger feature was in the planning stages, the team would discuss with all known parties that would have use for the components to ensure proper development.
This exchange brought to light many new ideas, concepts and results that lead to noticeable improvement in the product and team morale.
Developing Atomic UX as a methodology and implementing into teams has seriously impacted the production speed and caused cultural change organization wide. Team are thinking differently about application development on a foundational level. Components are being developed independant of "location".
Further, the organization is handing designers around to lead feature planning and roadmaps for releases. UX has been placed at the forefront of the application development on all levels; from UI, through the domain tier, and across performance standards.