So, I was talking to a company the other day, and they had just done a major redesign of their product. Unfortunately, as soon as they released it, they started getting customer complaints. They had removed a particular feature from the main part of the product, and paying customers started to scream.
They were already allowing people to use the previous design, which was a good thing, since folks started switching back immediately. Of course, they went into recovery mode. They started looking at customer feedback and planning a redesign of the redesign to reintegrate the feature they’d removed.
I asked what I thought was a reasonable question: Had they done any prototype testing with current users during the early phase of the major redesign?
Their response was, “We didn’t have time for prototype testing.”
Oh, really? That’s an interesting answer, because they sure has hell had time to do a fairly significant reboot of their redesign after launch to fix a problem that would have been prevented by showing some wireframes to current users.
After all, they already had mockups of the new designs. Showing those mockups to users would have taken a day of work at most.
Look, shipping fast is important. In fact, these days I’d say I do far fewer interactive prototypes than I did back in the days when we were still doing waterfall, mostly because engineers in a continuous deployment process can build, test, and iterate on something almost as fast as I can with an interactive prototype.
But major redesigns that touch all parts of the interface are exactly the kind of thing that you should make time to do prototype testing on. Because in this sort of scenario, more often than not, an interactive prototype, or even just a wireframe or sketch or mockup, can end up saving you a lot of time after launch. They help you get feedback from customers before you go to all the trouble of building something you have to roll back or redesign.
The most important thing to remember is that one of the biggest reasons for shipping fast is to learn as quickly as possible from your mistakes. If you can learn more quickly and efficiently from an interactive prototype, you should do that.
Going really fast in the wrong direction doesn’t actually end up saving you any time in the end. Sometimes glancing at a map before you leave gets you where you want to go faster.
Like the post? Follow me on Twitter.