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
As software products have expanded over the decades, companies have had to apply a fair amount of effort to managing their customers’ experience. Since companies have added more and more features and functions to their software products, customer engagement has begun to fluctuate. Managing customers’ expectations had become complicated. These products have continued to grow because customers desired more features and the software companies wanted to offer more value—for a nominal fee, of course. Now, these companies confront the challenge not only of how to design and build the new features but also how to manage and release them.
Several companies—for example, Google—have managed these changes fairly well, but many have a lot of room for improvement. The days are over when we can honestly say, “If we build it, they will come.” We must do the work necessary to truly understand our customers’ needs. If we understood our customers, we would understand that we can’t just jam new features or functions into our software and expect customers joyfully to accept them. Read More