How often does it happen to you that you want to make small changes to your product UI, for example: colors / images / buttons / add a form / add some text here and there?
Do you need to involve the design/dev team and ask them to de-focus from the core product to handle your requests?
Is there any solution that allows non-tech people to do it on their own?
If these requests aren’t urgent (i.e. going to hurt the things you care about ala churn), then batch them up and sit on them for a bit. For a couple of reasons:
Managing cognitive load and minimising disruptions to momentum, is something (in my experience) that your team will appreciate.
You mean issue with designing and planning, or more about team communication?
Yep. I think (from Team Topologies / Peopleware) that your main job as a manager is to remove obstacles for people to work “smoothly”.
Usually if there is already a design pattern set out you can refer to it. Forms don’t count as new design to me as long as it follows the pattern.
In my company designers are too busy designing new features to be bothered with established UX.
@Amy How often do you do UI-related changes?
We are pretty slow to be honest but I can say out of the past 10 UI changes my team did I consulted our designers maybe once. But I am on a legacy product so the patterns were set long ago and I probably couldn’t get design resources even if I wanted to.
If they are small just group them up and add them at the end. And check them with designers first. And who’s calling them small? Are you 100% they’re small, or is that an assumption?
The answer to this is, of course, it depends, but bias towards not randomizing people and instead funneling your feedback through an appropriate channel.
Generally speaking if you have a nit with something in the product UI, there should be a channel to file an issue somewhere and start a conversation. Maybe that conversation is as simple as, “this text is hard to read because of the color” and then someone just changes a single line of code in 2 minutes, deploys the change, and in an hour your product is updated. Maybe it’s longer. Maybe it’s a part of a broader conversation that UX wants to have. Who knows? All depends, but the key thing is there’s an accepted channel to have that conversation.
You may also be in an environment where you, a dev or two, and UX folks all work super close together, and a small slack thread with everyone involved ends up in a quick tweak that everyone agrees with. If you’re in a work group with a culture where small things (one-off, and not a part of a pattern of one-offs) like this are acceptable, then go for it I suppose!
All depends, but I’ll reiterate - bias towards not randomizing people.
We have a low pace project where the designer and the devs build up a backlog of items the dev team could pick from in between other things. Some things are bigger, like a re-design of a screen, some items are smaller, like making a button color consistent.
That is sand in the analogy of “is this glass full” (see here: https://www.youtube.com/watch?v=FA8SgdpW8Dk).
Normally a sprint is made up of large items related to an epic or release, with some medium sized items that add value or are experimental, then you have a variety of small or extra small items that are related to quality, annoyances, etc.
As long as you are prioritizing the large and medium items according to how you and your stakeholders have agreed to do them, then having a backlog of “sand” for you team to pick up and pull into each sprint is more than OK.
That said, it should be part of sprint planning and kick off and should not be “snuck” in mid-sprint. In most instances small items should be around .5 to 1 point stories… which typically means a single person can make the change with no help, and with very little time (think time measured in minutes or single digit hours). If you are keen to only measure complexity, then the complexity of such items are the type which your most entry level engineer should be able to handle quickly.
I hope this helps.
The video is a great lesson on prioritization in life and work. I ended up watching a few more from the same professor 
Thanks for sharing.
Prioritization is perhaps one of the most important roles of a product manager. You have to shield your team from noise - be it less impactful work, demanding execs, or angry customers. A PM should set a rhythm for the team and let them play the music.
This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.