As a reminder from the 2021 document, a UX review is now mandatory on all tasks from the accelerated projects listed in that document, when they affect the user experience (even very slightly). So remember to assign @cassie or @Ali as a second reviewer on those tasks during sprint planning (if you have any matching tasks in the current or previous sprint, make sure to reach out to them now!), to allow them to plan their work.
Passing that UX review is part of the internal review, and should be completed before the work is merged - not completing it before the end of the sprint would count as a spillover, like any other part of the internal review. Note however that the UX review can be done at the same time as the development review and/core committer review, to allow to parallelize things. Just make sure to mention anything that would change or affect the UX as a result of a change from the code reviews to the UX reviewer, and the other way around.
We have been trying to adopt this in OCIM UX 2.1 epic, here are few issues that come up:
Constant change in staging
Since the way to review UX change, is to deploy the changes on staging and then asking the reviewer to go through it. The is an asynchronous process so by the time they access the staging someone would have deployed their code and overwritten the changes.
This increases the review cycle and confusion.
One solution is to help design reviewers by setting up a local devstack, but I highly doubt the feasibility since it requires some amount of familiarity with the codebase.
Availability
It requires a deeper level of planning to get your features reviewed, sometimes if the feature is done late in the sprint or both design reviewers are off then the ticket gets stuck. So something like a design review FF would be of help in this scenario.
There are few problems we faced in the Epic so I thought it will be a good idea to bring them up here.
You are right that asking to setup a local devstack isn’t a likely solution – maybe more something like what we have for edX product reviews, ie a dedicated sandbox for the ticket. Since this is a technical issue, can I let you figure out a solution and discuss it with @Ali and @cassie
It is the responsibility of the task owner to plan the reviews with the reviewers, and to get everything ready on time. The assignee needs to coordinate the time at which the reviews will be sent for UX review, discussing it at the beginning of the sprint with the UX reviewers – just like for code reviews. And remember that both code reviews and UX reviews can happen simultaneously, as long as both are kept informed of any new changes brought by reviews.
As for a design review firefighter - I’m not sure what it would mean exactly? You mean ensuring that there is always someone available to do a UX review? Shouldn’t the UX reviewer assignment ensure this? Can I also let you coordinate together with @Ali@cassie, finding an approach that works for everyone, and remains similar to what we have in place for code reviews?
Thanks for trying to come up with a way to make the process smoother. @cassie and I have a few notes now that we have a better idea of the type, and the frequency of the reviews we’ll be responsible for:
It would be easier for us to schedule our time if there were a specific day/s per week/sprint that we dedicate to these reviews. That way we can make sure we’re always available to give feedback when you need it. Would something like that be possible?
Things might run more smoothly if we were given bigger chunks of work to review. I’m not sure how this would affect the development process though. Could it work?
There’s been some confusion between the wireframes we created as part of the UX evaluations, and the handful of UI designs we were asked to put together. The styling from the style guide we provided is supposed to be used across all pages. Is there something we can do from our side to clear up any confusion?
I’m sure we’ll get things running more smoothly soon!
P.s. Please note that Cassie and I are both off next week, from the 31 March - 5 April.
Most of the development work is done on a daily basis, so assigning few days for UX reviews will again bring in more deadlines for the developers and it might create additional pressure for the team. In place of this, it would be highly appreciated if at the beginning of the sprint you can see how many tickets require UX reviews and on the basis of that you can assign some time daily. That is how we do development reviews right now and it helps to manage the work better for us.
Also if we assign some days in the week the review and turnaround time to address those reviews will be too long.
For development we try to make the requirements as granular as possible, our intention here is to keep the UX cycle and development cycle to be in sync so that at the end of the sprint we are shipping out features. And if we combine tickets together we might have to block deployment hence there are small chunks for reviews.
This is something that we are doing for the first time what I feel is having a mock for every page that has to be worked on can save use. The wireframes can be used for UX evaluation but for development we should have the mocks ready that saves up the confusion and gives us an absolute understanding of what is expected.
I’m sorry it’s taken so long to get back to you. Please see my comments below.
Ok, I see the problem. So just to confirm what you have in mind: The first day of each new sprint we’d review the tickets that have been assigned to us to review during the sprint. We’d then have the full sprint to respond to those tickets and provide feedback. Is that correct?
For us it’s not viable to follow the same process as Code Reviewers (i.e. providing reviews within 24 hours) because we have other clients and projects going on at the same time. Because of that, we need to manage our schedule carefully.
This makes sense, however it’s often difficult to review the user experience of an interface in these kind of bite-size chunks. User experience is usually determined by how different elements work together as a whole, not in isolation. That said, we can do our best to review small chunks, but may need to conduct larger UX reviews from time to time.
I agree that this is the better approach. I think future projects should be managed like that where possible (obviously budget and timeline will determine whether this is possible). We’ll just need to make sure everyone understands the approach before the project begins.
Here is my thought on this point and let me know if I am assuming something wrong. At the beginning of the sprint, you can see how many tickets are required to be reviewed throughout the sprint. This will give you a high-level idea of the workload which can help in better planning.
I think we do understand that the turn-around can exceed 24 hours, but it would be great if you can inform the assignee what is the expected time for the review. I just want to emphasize that there can be follow-up work on the ticket to address the reviews so the earlier it is done the better.
Generally, it is not urgent but at times the ticket comes really late in the sprint for review depending on the urgency, you can take a call to review it or let it go in spillover. Either way, it’s always good to communicate that to the assignee it saves both you and the assignee from additional stress.
We as developers can make sure to either deploy this on staging and give you access to the working UX and if not we can co-ordinate.
What we can do is on the addition of the new feature/fix you can always comment of the ticket if anything else should be changed and depending on that either scope of the ticket can be expanded if possible or a follow-up ticket can be created to fix it.
