“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
On a quiet spring morning, one of our clients—the director of a small firm with ten employees—called our office and wanted to see me the very same day to discuss a new project. When we met in the afternoon, he told me his firm needed a new Web site for the launch of their latest product, which they would promote—and, hopefully, sell—only on the Web. The site was to include communications tools for interacting with customers, Help, and a blog on which they’d announce new versions of the product.
Nothing strange so far. The firm meant to invest, as it had previously done, in user-centered design, online promotion, and development by my firm and two other partners. However, toward the end of the meeting, the director told me that everything must be online in three weeks’ time for a fair, and the whole site must be completed on a budget of less than $15,000.
Many firms and professionals who work internationally in user-centered design would not have taken up the challenge. In addition to the project’s limited budget, time is vital during the design phase. Typically, the more time you have, the better the solution you are likely to devise, because you can metabolize more ideas and reflect at length on more user interface and interaction design issues. Read More
Agile development has recently captured the imagination of many software development teams—and with good reason: its focus on producing working software quickly is well suited to today’s fast-paced markets. But how do you go about combining agile with user-centered design (UCD) so you can enjoy the benefits of both approaches? On the face of it, they should work well together because both philosophies are iterative, incorporating testing with users and refinement. But in practice, they often conflict with one another.
An agile approach such as Scrum tries to minimize up-front planning in favor of producing working code quickly. Plus, agile generally prefers in-situ workshops for gathering requirements, while UCD largely favors up-front user research. Agile also uses working software as its primary measure of progress, while UCD focuses on whether users can easily achieve their goals—with or without software. To add to these discrepancies, because agile is typically led by developers, while UX professionals usually drive UCD, the differences between these two approaches can result in political conflicts in many companies. Read More