Process: Agile UX

If you were moving to New York City, what would get you excited? You might say the nightlife or the food. But for the geek in me, it was getting Verizon FiOS (Fiber Optic Service). I mean, who wouldn’t want blazing fast Internet speeds? My new condo is FiOS-ready, so I thought it would be easy. I called Verizon weeks before the move, so I would have Internet access on Day 1. But there was a snag: after about two hours on the phone, trying to figure out why we kept getting an error, the sales representative said that she would have to call me back. I never got her call.

Since I had gotten nowhere trying to order FiOS by phone, I next tried ordering FiOS online. Then, two days before my move, I again tried calling Verizon. That sales representative also hit an error and couldn’t help me. I called again on my moving day and asked to speak to a manager. While I waited for a response, I tried using my iPad to see whether I could complete the task online. It turns out that Verizon had run out of phone numbers in the 212 area code. No error messages alerted them to that fact or offered any alternative way of proceeding. Okay, so who cares about an area code? (It turns out, I do—and by yelling and screaming, I ended up getting one—but that’s beside the point.) Read More

If you use—or want to start using—an agile-development process, you probably already know its benefits, but you might not be as aware of one of its main drawbacks. Even though 46% of US organizations and 85% internationally report that they’ve used an agile approach within the past year, communicating your agile process to clients remains a challenge.

Specifically, the problem is bridging the gap between clients’ expectations of the process and the way agile really works. But overcoming this difficulty is well worth the effort if you wind up with a first-rate product and a fully satisfied client.

Of course, some clients are already quite familiar with how agile works. However, for those who aren’t—and whose previous experience was with waterfall product-development approaches—explaining the process and merits of agile can be tough. Sure, your clients might know some agile buzzwords, be familiar with some of the tools, or know the importance of meetings to the agile process. However, it’s unlikely that they understand how agile actually works in practice. Read More

“It’s very easy to be different, but very difficult to be better.”—Jonathan Ive, Chief Design Officer, Apple

Deciding on the right product-development process for your team can often be a paradox. Maintaining balance amidst a proliferation of inconsistencies in product requirements and development outcomes is challenging for both large and mid-sized organizations —especially when teams lack any metrics to measure their impact on a release.

Friction arises when there is a mismatch between the user’s mental model and product features. When a development team finds itself in an untenable situation, the blame game begins. But as Mad Men’s Don Draper often said, “Move forward.” Read More