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.
I recently had the same issue working on a large-scale web application. The first stage of the project was all about building the initial styleguide and UI components. Now that we’re handling API connections, not much is changing visually as the API results are slowly replacing dummy copy.
To show change over time, I added a “demo mode” toggle button that outlines areas of the application differently as hardcoded data gets replaced by real API calls. This satisfies the product owners need for progress while giving the development team more breathing room.
great article, Eileen!
isn’t it great when the user values more a fancy new button style than a new column in a table that takes 3 days of work to get done?
users will always prefer form over function.
The client needs to “see” progress. In email I was taught a simple rule. If it takes 2 minutes to handle the email, handle it, otherwise delegate it for later. When people have credit card debt, they are told to pay off the cards where they owe the least first. This is so they can see “progress”. Your clients (could be your boss or a business unit in the company) need to see progress.
I like the handle the low hanging fruit first. It takes very little time, but has a big impact for the client. “Oh, that’s a popcorn task: super easy and fast, and I like to leave those fixes to the end.”, should never be said. Your job is to please the client first. If they’re happy, most likely you’ll be happy too. That doesn’t mean we don’t say “no” to the client. It’s also our job to create the very best product we can within the time and cost constraints of the client.
Maybe it’s my OCD, but visual issues drive me crazy. Every time I see a visual issue, it bothers me, I just can’t leave them and not fix them. Once fixed, then I have more energy to pursue more complex non-visual issues.
@Mike, that’s awesome! I’m sure there are a ton of clever ways we can communicate progress to our clients – fine people out there in commentland, please share more ideas if you have them!
@Tanny, I don’t agree that approaching a popcorn task last “should never be said”. A project that thrills the client but damages my team’s morale is not one I can call a success. Whether you or I would approach bug fixes in that order is beside the point; I have to honor my team’s self-knowledge of how they work best. Improving the client experience is not about ignoring my team’s work needs, but rather about finding ways for us all – stakeholders and developers – to succeed together.
@Eileen thanks for this article. @Mike that is a good idea.
As a Freelance, I also get this feeling when I try to explain what I do to my loved ones.
I feel it might also be a good booster for my self-confidence if I alternate more between “visible” and “invisible” improvements.
Thank You for your Article
Great article. Thanks for revealing how this process works for you.
We struggle with this as well, but have started implementing some milestones that help the client see progress.
The basic milestones are:
1. Sketches (basic layout and ideas)
2. Concepts (Static designs in Photoshop)
3. Mockup (relatively static HTML templates with basic interactions and animations)
4. Dynamic Site (content starts being fed via CMS)
5. Interactive Site (additional Javascript work, smoother animations/transitions, AJAX)
6. Responsive Site (fine tuning site for mobile, breakpoints and browser compatibility issues)
7. Launch
After the static designs were approved on my last project, I built a mockup of the site templates. These were non-responsive with mostly dummy content, but transitions and animations were in place to give the client that “wow” factor and sense of accomplishment.
As they reviewed the mockup, I began implementing that design in WordPress. The ‘visual’ progress was slow at that point, but the client still had the mockup to play with and show off to their bosses.
Depending on site/CMS complexity, the Mockup and Dynamic stages could be combined, but it’s easiest for me to not worry about the specifics of the CMS/dynamic content when I’m transitioning from Photoshop to the code.
There were a few additional milestones (like when content for specific sections were filled in) where the client could see progress and give feedback, while additional behind-the-scenes work was made.
Client interaction definitely requires a difficult balance of visible and invisible progress, but this milestone process is working for us so far.
Good points Shaw. This is a large reason why we still deliver Photoshop and interactive comps to our clients. Keeps everyone on the same page while development is happening.
We showed a prospective client how their current site looked on multiple devices using Mobilizer. They were shocked, it won us the responsive design contract to fix the mess. @GetMobilizer
My favorite bugs to tackle first are the low hanging fruit variety that also are visually apparent or functionally apparent. When I scan a bug list I always look for something that is both easy and important. The image scaling issue that you referenced probably be the first bug that I fix.