Practitioners-Guide-User-Experience-Design

used to it.
The point fell flat, and I’d spent a good deal of time trying to make the prototype
interactive and as high-fidelity as possible. I was using the wrong methods to speak to my
stakeholder. If I could go back now I’d do it all differently. I’d mock up only the first
page, put it on a phone, and walk through the office tallying how many people said they
would swipe vertically to move through the article. Such a simple, low-cost test carried
out the moment the issue came up would probably have been sufficient to make the case
for extending our deadline. I took too long to build a complex prototype to test something
that already had great evidence in its favor. Worst of all, though, the prototype gave
credence to the alternate possibility.
That experience taught me a lesson I’ll always be reminding myself about—pick
your battles and how you’ll fight them. I had fought for other design features of the app,
but this was the most important one, core to the experience. I should have better
anticipated how dug in my boss was going to be about the timeline—as bosses very often
are—and gathered more support before going to him, and I should have worked more
quickly. I also should never have shown him such a fully developed prototype in order to
make a basic point about such a fundamental aspect of utility.