I wanted to start a thread to discuss how we can better integrate UX and product reviews into our release process. Currently, product/design often don’t get to see the developed product before it’s shared with the client, which makes it really difficult to ensure we’re delivering the experience we’ve designed and promised. The process is included in our Task Workflows in the Handbook so I’d like to understand why consistent reviews aren’t happening / accounted for in budget?
As we continue to evolve how we work, it might be helpful to explore better ways to include a UX QA step before releases. This isn’t about adding blockers - it’s about releasing with more confidence and ensuring the user experience aligns with our intention.
@cassie The section of the handbook you linked conflicts some what with the section on product review in the estimates guide.
The task workflow currently implies that initial discovery is done without product input, but this is no longer the case.
I think the real answer is that we should expect any ticket with UI elements (that we designed) to have an assigned product reviewer. In cases where we aren’t the designer we will probably need to defer to the client’s review.
Actually, product reviewer is becoming frequent enough that we should probably have a dedicated field for it like we do the CC field. @tecoholic or @braden would you have access to add this? Are you aware of any issues it might cause? Theoretically it should be counted in SprintCraft as well for hours allocated, but Cassie and Ali are in Deathstar and so don’t use it. However this might be something to review when doing the Huly migration, so ccing @Agrendalath .
Listaflow already has this integrated in our workflow-- we ping product as part of the review to verify that a release is meeting expectation for design implementation. However, the assignee is obvious in our case-- it’s always you, and if the assignee doesn’t ping you, I do since I’m almost always a reviewer. You probably also have notifications set up for Listaflow anyway so you wouldn’t miss opportunities for review.
Not having our tooling indicate that there is a product reviewer to be assigned, and not having conveyed the expectation of a product reviewer for implementation tickets, seems to be the combination of factors causing this.
Totally agree with this – thanks for raising it. Having a proper UX QA step would go a long way in making sure the final experience aligns with what we intended and, most importantly, presented to the client.
Given that we are not far from the Huly migration, it does not make much sense to add more features to SprintCraft at this point. SprintCraft also does not support the CC reviewer field - it was created to count the hours correctly in the Tempo reports. However, I recall that we usually create separate tickets for CC reviews anyway.
@kshitij, do we have a discovery ticket for SprintCraft adaptation/replacement in Huly?
If we don’t change any of the existing fields, it should not break anything in SprintCraft.
I don’t have any concerns about using a FAL ticket to work this process out, since we have some sustainability to spare.
But I did think the topic is separate from most of what Falcon does, since our projects are specified by Axim’s Product team, and designed by their UX people. Does Falcon need to change our processes too?
That’s a good question. I would say Axim should define the UX/UI process in that case. But if Falcon does ever work with the internal UX/UI team, they’ll need to follow our processes.
@tikr what do you think process wise? And logging time on Falcon?
For logging time, we don’t really have much of a choice right now. So it seems like the fact that Falcon’s processes would likely remain unaffected for now can’t be viewed as a deciding factor.
