Jeff Patton

On the surface, a Broadway musical, a newspaper, and software may not seem to have much—if anything—in common, but they have one common thread. All are delivered on a fixed schedule. But of the three, software tends to stray the most from the fixed schedule. In this week's column, Jeff Patton says that by focusing on the readiness of the entire product—as done in theatrical performances and when publishing a newspaper—and not just on the completion of the planned bits of work, you can produce software on a fixed schedule that you know is ready to ship.

Knowing who will use your software is important to the software development process. Having the end-user in mind helps you develop features that fit the user's needs. And, figuring out your end-user, as Jeff Patton reveals, is indeed easy. In this column, Jeff details stereotypes to avoid, questions to ask, and how to implement this pragmatic persona in your development process.

Does your software development process need tuning? How can you tell if it isn't running as well as it could be? In this week's column, Jeff Patton offers a diagnosis checklist for your team to help assess the vital statistics of your current development process.

As a user experience design specialist, clients often ask Jeff Patton to make their software "look better," so it can be successful. But when clients focus primarily on aesthetics, they're often addressing the wrong thing. In this column, Jeff takes a look at common user interface (UI) mistakes and the key concerns software development teams should address to build successful UIs.

Jeff Patton has been building software using the agile approach for a while now. His observations of how others are implementing agile development fall short of complete, but he has noticed is that the adoption breaks down during the evaluation phase. In this column, Jeff goes through the agile development process and offers guidance on the correct way of conducting an agile evaluation during this phase in the software development lifecycle.

In most projects, testers are the keepers of quality. Sharing the vision of quality with the entire team helps everyone involved in a project play a more active role in determining the state of quality in a product. In this column, Jeff Patton shares several innovative ideas he's seen in practice lately that have helped an entire team own up to the quality of its software.

Managing an agile project based on uncensored "Very High," "High," and "Low Priority" user stories or backlog items used to induce stress on Jeff Patton. So he learned to implement a combination of prioritization techniques to get these lists--and the job--under control. In this week's column, find out how Jeff utilizes MoSCoW and business goals to make sense of prioritization.

In this week's column, Jeff Patton sends a reminder that software developers who neglect the practices of "iteration" and "incremental" will get caught either delivering poor quality software or delaying schedules in order to make time to iterate. We kick ourselves, or others, for not "getting [software] right up front" when we all know that the hardest part of software development is figuring out what to build. But there's hope, and it comes in the form of prototypes and frequent iterations.

Jeff Patton will admit that he's easily sidetracked. In a meeting or simply working on a problem with a small group, a cool idea or puzzling problem can send Jeff sideways. His head spins off track, and his mouth goes with it. He's not alone in this behavior; Jeff suspects everyone reading this column has been confined in a meeting called to resolve an important problem while someone—and it may have been you—burned up critical time to take the meeting off on a tangent. While not a completely curable condition, there are a few useful techniques Jeff explains in his column that will help keep a collaborating group on track.

Ever find yourself spinning in a conversation where the discussion of ideas gets stuck in a circuitous route? In the world of software development, where the need to effectively communicate elaborate and complex ideas is most important, such conversations end up being counter-productive. In this week's column, Jeff Patton shares a technique that keeps such conversations on a straight and productive path. Find out how he channels different ideas and categorizes them-all within one very fun and productive meeting.

It's easy to split user-experience experts and software architects into different categories and still grant them equal importance; the former deals with the façade of the software while the latter deals with the workings beneath the surface. This separate, but equal attitude changed for Jeff Patton after attending a workshop in which his eyes opened to an epiphany of holism in software development. From this enlightened moment, Jeff realized a way software development could change for the better.

Testing doesn't have to begin after the code has been written. In this column, Jeff Patton resurrects the oldest and most overlooked development technique, which can be used to test a product before any piece of it materializes.

When deciding how a user's task is to be supported in our software, we often look at possible design solutions and select one that's best for the product and the user. As the project deadline approaches, however, we might choose to dismiss some features outright. In this column, Jeff Patton suggests we try keeping more features by adjusting their scale.

The new Web 2.0 has quietly emerged; well, maybe not so quietly for those who were paying attention. But it is already changing the way we design, develop, test, and release Web applications. This change came about from users' new expectations of the Web. Web developers' and programmers' willingness to adopt these new expectations will not only change the way we see the Web, but will also change the way in which we work every day.

There's a common misconception that test-driven development is a testing technique when in fact it's a design technique. In this column, Jeff Patton explains this and how you might use your unit tests to explicitly guide and describe the design of your software.

Design thinking points out several missed steps in software development. And, while some may believe ideation and iteration to be wasteful, they're easy to add to the development process at low cost and, in the end, result in substantially more valuable software. In this article, Jeff Patton describes the four basic steps of design thinking.