I’ve been thinking a lot lately about how actual progress on a project doesn’t always match the impression of progress—sometimes a lot of code has changed but nothing looks very different, while other times a small change in code gives the sense that the whole project has moved leaps and bounds.
This came up recently because of how my team had been prioritizing bug fixes on a responsive redesign project. Our normal process is that after sharing an early version of a responsive prototype with the client or internal stakeholder, we create a ton of bug reports (GitHub issues, in our case) that act as to-dos as we move through the project. Depending on the project, the issues are usually grouped by content type (“all the variations of portfolio styles”) or by section (“all the sidebars”). The highest priority issues are any that block other people from doing their work, and after that, order of fixing is largely left to the discretion of the developer.
On this particular project, lots of fixes were being committed and pushed out to the development site, but when I reloaded the pages nothing looked very different. Two weeks passed and everything still looked pretty much the same. I knew work was being done, but I couldn’t see where.
Finally, exasperated at what seemed like a lack of progress, I asked the team why they hadn’t fixed what felt like a huge, obvious bug to me: images were being scaled to larger than their actual image size at some breakpoints and looked pixelated and crappy. “Oh,” one developer said, “that’s a popcorn task: super easy and fast, and I like to leave those fixes to the end. I start with the complicated issues first so I have the most time to work on them.” Another developer explained that the display bugs in the header and main navigation weren’t slated to be addressed until she had finished styling the news archives.
When it comes to front-end development, many of the trickiest issues are subtle—the way a table resizes at a middle breakpoint, or line heights adjust as the viewport size changes. On this site, the glaring issues that were clearest to a non-developer—the ratio of column widths, wonky margins, and broken images—kept getting shoved to the back of the queue, where it looked to me (and our client) like no one was paying attention to them. And of course an ugly and broken header is going to stay that way as long as the team is focused on styling the news section instead.
For the next few weeks of the project, we tried something new and tagged some of the issues as “visually important.” Those issues got addressed early even if they were simple or not part of the section in focus, based on our judgment that fixing them would add to the impression of progress on the development site. Each week when I reviewed the site, I saw headers now properly aligned, new snazzy CSS transitions, and trendy border-radiused circular profile images.
By the end of the phase, we had fixed all the same bugs that we normally would have. But by strategically addressing the visually obvious issues, we created an external sense of progress for our stakeholders that was a more accurate reflection of the amount of work going into the code.
Iteration is a hot topic right now, and many of us are moving toward sharing earlier and messier versions of a site with our stakeholders. We put a lot of care and attention on crafting a great user experience, but the end user isn’t the only one who needs to be pleased with the site. It’s worth adjusting the processes around how we present and work with rough prototypes in a way that provides a good client experience as well.
via planetweb
0 commentaires:
Enregistrer un commentaire