15 years ago I worked as a UI design lead, transitioning to a PM role. My team’s Scrum Backlog looked like the image below:
And the product delivery process in my team was:
- Business Analyst / PM creates / updates a Backlog.
- Every 2 weeks engineering team chooses which stories they want to code.
- Engineering team starts coding the user stories.
- Engineering team may ask a designer to help, but most of the time they will code these stories on their own.
As a PM with a design background, I suffered seeing the outcomes. Usability and design quality was untenable, and my very first step to increasing the quality was to incorporate design effort before the engineering time was spent, so designers become a part of the entire scrum cycle (before, during, and after the sprint).
As we managed to produce nicely designed pages, my next step was to start collecting actual feedback from the end users. When I got my very first user interviews, in spite that the UI looked good, I’ve discovered that nobody wanted to use our product, their company purchased it globally and they had no choice. I went back to my manager and shared the results of user testing, hoping that we could change things so our users don’t suffer, but I was told that this is not in the company’s interest to invest any additional effort in increasing user satisfaction and that we are also providing personalized training for $1500 per person.
That day I’ve realized that UX is much more connected to the Product Strategy than to UI or any other discipline.
UX Shall be included
To create great products, UX shall be included in all phases thoroughly, and not just be a layer between PM and Dev.
Organizations often try to “save time” and don’t validate their requirements and designs well. The desire to ship something sooner is understandable, but cutting corners will inevitably show up in the final product.
Just having a decent UX budget and high skilled team of researchers and designers doesn’t automatically makes your product great. What makes the difference is how effectively this knowledge is used across other key teams.
UX vs PMX (c)
I’ve noticed that a lot of organizations do “PMX” (c) rather than “UX”. This happens when PM doesn’t use User Research data in the design process. UX designers can perform their high-quality design work, but this work will cater just PM assumptions, which can (or can not) match user needs.
Questions that a UX mature organization will ask itself:
- Does your Organization collect enough / good enough data / metrics to inform design / strategy decisions? Is this information easily accessible to the team members?
- Does your team know how happy your users are with every key feature at any moment (proactively collecting and structuring the UX insights)?
- Does your team validate the requirements?
- Does your PM team consider improving the actual User Journey (along with catering standalone business requirements)?
- Does your design actually solve user problems? Does it bring any new usability issues (how well it is validated)?
- Has your dev team implemented the design the way it was designed?
- Does your roadmap have the bandwidth to take care of a technical / usability debt?
Low Maturity Signals
Nielsen recently released a video with few other signals of Low UX maturity in the organization:
- You must repeatedly explain the difference between visual design and interaction design.
- Usability testing is done late, and only on working designs (never on prototypes).
- You never do field studies.
- UX practitioners are excluded from product meetings.
- UX Processes and research are neither viable nor automatic.
There are many more variables to a good UX rather than having a good UX team.
And if you disagree with me, this little video is for you.