Business: DesignOps

In this edition of Ask UXmatters, our experts discuss the newest discipline within User Experience: DesignOps, which covers the operational aspects of design. Most DesignOps practices have been standard operational practices within software companies for many years—they just weren’t called DesignOps until a couple of years ago, and they did not yet constitute an integrated set of practices.

DesignOps is such a new discipline that the term is still somewhat ill-defined—even though there’s already a conference that focuses on this discipline, the DesignOps Summit, for which 2018 will be its second year, and InVision has just released an ebook on this topic, The DesignOps Handbook. It’s unclear who originally coined the term DesignOps, but there is universal agreement that it was inspired by the term DevOps. This is just the second piece that UXmatters has published about DesignOps. The first was Jeff Sussna’s article “What DesignOps Can Learn from DevOps.”

In this column, our expert panel defines DesignOps, discusses what dimensions the discipline comprehends, and describes DesignOps roles and practices at several leading companies. Read More

In this edition of Ask UXmatters, our expert panel addresses scoping UX projects and what functions are within and outside the scope of User Experience. It seems that the definition of User Experience is constantly expanding. First, our experts discuss how the business community currently perceives the practice of User Experience in relation to their business. Then, we’ll explore some specifics such as:

• defining the scope of the project work an organization need to do
• how to manage change
• matching the skills of team members to the work
• how to accomplish the work within the allocated time and budget

One panelist asks us to consider whether it really matters if something is within the defined scope of User Experience. Read More

In Part 1 of this two-part series, I described some challenges that companies have in managing their customers’ experience as their software products evolve. These are not uncommon problems, nor are they easy challenges to overcome.

In my experience, developers of legacy software that are working to grow their platform are generally the furthest behind the curve. If, in general, they have dealt with change management in a piece-meal fashion, they are bound to face a sobering reality at some point. These companies also have existing customers who have contributed to and have a vested interest in the legacy software. Plus, they need to onboard new customers on the legacy system who may struggle with the legacy software and want improvements. This situation can present a wicked problem that puts a company in a perpetual technical tug of war. Read More