In ticket grooming sessions, we often are posed with the question: "how long will it take to [task]?" In that moment, we subconsciously jump to thoughts of: feeling pressured to complete quickly, the final output, and solution assumptions. PM's typically want to accelerate tasks and complete multiple things quickly within a sprint. Most often, tasks are framed to emphasize output as opposed to outcomes or process. When it comes to scoping your tasks, take a step back and ask: what is the design outcomes that we are trying to achieve and what process do I need to take? Socialize this out loud to the pod so they understand your efforts.
To effectively communicate the rationale of your scoping estimations, articulate your process on completing the task with your team. Reframing the ask, outlining the challenges and dependencies, and defining your process will validate your scoping estimations, leave wiggle room for flexibility, and relieve time pressure.
Updating specs is a lot more quicker these days with mirrored symbol capabilities, auto-generated properties and layout specs, auto-adjustment of components, and responsiveness. It's not how it used to be when specs required a lot of manual work: adjusting layout, size, duplicating, pushing and pulling, etc.
A task like updating a color of a component in your spec can happen instantly, but it's ensuring the color works within your design system that requires thought and method, necessitating time and effort. Here are questions to pose when being challenged about your scope:
Is the color part of the company or product brand palette?
Is the color compliant with color contrast ratio criteria?
Is the color compliant with standard design heuristics?
Is the color hierarchically prominent in relationship to other colors in your design system?
Is the color reflective of the correct tone, style, and voice that you are trying to convey or represent in your product?
Is the color previously being used in other contexts in your system, which necessitates additional color changes for other components?
Have you reviewed and have gone through your approval channels with the UX team, marketing team, legal, and other required stakeholders?
Have you explored various options, tested with users, compared/differentiate against competitors, and researched best practices?
Summary
Updating color is a process. It has great impacts and outcomes to your product. It's not as clear cut and simple. When scoping your efforts, ensure that you are communicating the implications, process, and impacts with your pod team. Give them examples of a past experience or show how a competitor fails to meet standard heuristic rules. Pad for time to define the right color. And shhh, over-scope your spec'ing efforts, you just don't know what can happen. Even with automated functions to streamline spec updates, things still do require time and thought, and there may be other dependencies.
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.
Comments