Put usability in your Agile backlog

We’ve all seen it: waterfall projects that deliver the wrong thing, too late. So we understand the appeal of the Agile method, delivering working software sooner, so the intended users—our clients and their customers—can provide feedback that steers us to deliver the right thing. Agile reporting tools also help us estimate how long the work will take, which makes it possible to deliver on time.

But there’s a tension between delivering the right thing and delivering on time. And as a UX practitioners, we sometimes see usability sacrificed in the rush to release on time. This happens despite the first of the Agile Manifesto’s principles:

  • Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

Valuable software is usable software, among other things. Data about what’s usable comes from testing. And much of that testing can’t take place until after the development—done in Agile stories—is completed and signed off. Development teams—consisting of analysts, developers, testers, usability researchers, and interface designers—often consider an Agile story to be completed despite the lack of feedback from the intended customers about its usability—or unusability. We can do better. Continue reading “Put usability in your Agile backlog”

The right mental model makes software easier to use

Recently, a client told me we needed to redesign the main data-entry form of their company’s flagship product. Customers said they didn’t like the form in our client’s SaaS or cloud-based software. Despite extra training, customers still felt apprehensive and intimidated by its complexity.

The online form was built years ago, without a designer—as was typical of dot-com start-ups. Within a few years, iPhone and iPad showed people that software could be simpler, and that’s what our client’s customers wanted, too. So we were tasked with simplifying the form. Continue reading “The right mental model makes software easier to use”