This is a a bit of a sequel to my earlier post about usability testing and gathering insights at my UX internship. As I mentioned, the interviews I conducted were the only monitored usability testing that had been performed on the app. There was more than a handful — perhaps an armful — of actionable feedback that I gathered. When it came time to organize these and make some sense out of what to tackle and what to shelf for the future, I went with an Effort vs. Impact matrix: what would make the most or least impact for users, plotted against the highest effort for product/developers to implement.
I thought I had it all planned out — go for the low hanging fruit first (high impact, low effort) and work on the high impact changes in the meantime. My first mistake: making assumptions about developer effort without actually speaking to a developer first. My second mistake: assuming nothing would get in the way.
Needless to say, things got in the way: we switched developer teams (from one offshore agency to another), ran into legal issues (nothing major, but it added steps to the user onboarding process), and my area lost power and internet for a week. When I got back on solid ground, much of my time was consumed by catching up the new developers, and designing a new task flow to ensure compliance. My beautiful Effort vs. Impact matrix was nowhere to be seen.
As I was working closely with the new developers to get them up to speed, they identified an armful — no, maybe a truckload — of bugs that were caused by the old developers. We also had to incorporate a new task flow that involved input and coordination from our board of advisors and CEO — this proved to be harder than we expected. It involved rework on the part of the developers, and they were not happy.
Lessons learned for me: what sounds like “low effort” for me might not necessarily be so for developers. Before I decide to label any change as such, it would be wise to consult those who will also be putting in effort to the cause. Moving forward, I’ll try to be more thoughtful about the implications of a potential change I’m considering — keeping in mind that my design doesn’t sit in a vacuum.
Case in point: a completely redesigned home page layout might be aesthetically pleasing (and I might have had my heart set on it for my portfolio), but the amount of work it will require to redo the whole navigation might not be worth it for a beta test. I will aim to be flexible, because even though my designs may be user-driven, they may not be the optimal solution in a world where both I and the developers have a limited amount of time and resources.