Recently I wrote an article for the INSPIRE site describing Adobe’s approach to service design. The full text of the article is below, in case you missed it over there. Definitely interested in your comments.
Also, I started writing here about my experiences on Adobe XD, doing design for Agile. So far, I’ve published one post about it, and have six others in draft form. Expect those drafts to start flowing into finalized posts, in the near future.
—
Adobe’s Approach to Service XD
As a traditional desktop company, Adobe is relatively new to online services. But in response to the general shift in the industry toward providing software as a service, Adobe has rapidly evolved its approach to releasing software. The new approach blurs the lines between desktop and the web, and affects the way teams think about product strategy and operations. Adobe XD is keeping pace with, and occasionally leading, this reorientation towards software as a service. This article describes how Adobe XD structures its approach to designing services.
The Context
Before detailing how Adobe XD approaches service design, it’s important to provide a deeper context by defining what “software as a service” means at Adobe, and how Adobe XD is helping to further shape this definition.
As mentioned above, Adobe is relatively new to software as a service. Whereas Google and Amazon were born and bred on the web, Adobe’s DNA is the desktop. As a result, change management is a key ingredient of all service design projects. XD is required to think outside the desktop, and help product teams understand the difference between user-centered opportunities presented by the web, the desktop, and the interrelationship between the two.
One of the ways we accomplish this is to focus on services as stand-alone functionality. In other words, we design services that provide value to users who don’t own Adobe desktop products. For example, Browser Lab provides a great example of a service that is useful to any open web developer, even those who don’t own Dreamweaver. Another example is Photoshop.com, an online photo organizer and editor that doesn’t requires its users to own Photoshop Elements.
At the same time, we strive to create seamless workflows between the desktop and the web. Using Browser Lab again as an example, its functionality is made accessible within Dreamweaver in the right place, and in the right way, to optimize a Dreamweaver user’s “web preview” workflow. To a Dreamweaver user, Browser Lab is just another Dreamweaver feature.
To summarize this model, Adobe XD considers services as stand-alone features of our desktop products. And because software as a service is relatively new to Adobe, Adobe XD maintains a critical stance in working on these projects, in order to help teams identify new models that leverage what is best about the desktop and the web.
The Program
One of the most critical differences between desktop and web-based software is their development process. Desktop products go through a full two years of work before being released, whereas services are updated on a monthly basis. The difference between these cycles has a profound impact on Adobe XD’s approach to service design.
For desktop products, slipping the release date is one of the worst things that can happen. As a result, desktop apps are often stripped of features in order to ensure that they ship on time. Historically, design-related features are the first to be cut. Unfortunately once a feature is cut, it can’t make its way into the product until a new release, years later.
The monthly release schedule for services, meanwhile, provides an opportunity to incrementally improve the experience of existing features, while also adding additional functionality. This benefits Adobe’s users, who get more features, and improved experiences, throughout their relationship with the service.
Monthly release cycles also have a positive effect on relationships within the team building the service. Each release can function like the opening of a pressure valve, releasing tension that’s built up among team members, about what tasks should be prioritized in the next version of a service. Instead of arguing about a design getting into the current release, XD can rely on it flowing into the next, which is only one month away.
Design
The monthly release cycles dictate XD’s approach to tactical design. Because features are released frequently, XD has to design in an agile manner. We do this by reusing UI resources that are common to all Adobe services, so that we can focus more on what is unique to each. A common set of templates, built in Adobe Fireworks, allow designers to quickly generate a wide range of static specifications such as sitemaps, workflow diagrams, wireframe screen designs, and visual UI elements. Nearly all service designers use the same templates, so their specifications can be easily reused across different services. For example, the designer working on InContext Editing can easily reuse the “Purchase” workflow specification that was created for Photoshop.com. Commonality across specifications helps speed spec completion, and ensures that different services, built by different engineering teams, give users similar experiences.
Recently designers have also used beta versions of Flash Catalyst to quickly create interactive specifications that communicate design in a much richer fashion that static documents, saving everyone time and energy.
In addition to tactical design work, XD provides service teams with strategic design visions that complement emerging business strategies. To establish the design vision, designers collaborate with user researchers to identify core user personas, establish high-level workflow phases related to the business problem, and enumerate illustrative use cases that are in alignment with users’ needs. It’s no small feat to prepare all these materials - and what I listed is merely a subset. In part this is because the process is a deeply collaborative one, which involves securing the agreement of, and coordinating efforts with, the greater service team.
Once collected, this user-focused data flows into the design vision. Explicitly speaking, the design vision is a visual showcase of a service’s experience and value. It generally takes the form of a set of high-fidelity visual mock-ups. When the vision is ready, it is previewed with customers, who provide feedback. As in any solid design process, feedback from customers is integrated back into the vision, in an iterative manner. By the conclusion of the feedback process, the design vision, and its associated product strategy, should be very much in alignment with the needs, wants, desires and purchasing behaviors of the service’s target customers.
The design vision additionally benefits the service team by providing a two-to-three year roadmap. Everyone understands that we can’t implement the entire service vision overnight, therefore it’s used as a northstar, guiding the team towards key goals.
Research
The final and most important aspect of XD’s approach to service design is collaboration between designers and the user research team. This collaboration takes a number of forms, and will continue to evolve as XD’s experience and understanding of service design matures.
As I mention above, when focused on strategy, our designers and researchers collaborate to collect and synthesize information on users, and create a service vision. As part of defining the vision and understanding the needs of our end users, we spend a good amount of time visiting customers in their workplace. We want to understand our customer’s workflows, what’s working, not working and the context of their work. What is their office environment? How do they collaborate as they accomplish their tasks? How do they deal with interruptions? And so forth. This contextual research feeds into our work in developing personas, documenting workflows and understanding the goals and needs of our audience.
Also, throughout the development process, the user research team continues to take prototypes of the service into the field and validate them with customers. In the best case scenario, we have users try to use the prototype in the course of working on actual projects, to simulate as closely as possible what the final service will feel like. Sometimes research brings users into XD’s usability labs and watches them use the products. Not only does this provide usability feedback, but these customer engagements help us understand how users approach our new business models.
From a tactical perspective, research and design collaborate to evaluate the design of the service’s features before it’s released to users. To this end, the research team conducts usability testing sessions to evaluate the efficacy of designs, and designers incorporate the results into their work. In addition, researchers tell designers where and why specific workflows should be instrumented, in order to collect usage metric feedback. Proper instrumentation helps the service team understand where, when and why users’ workflows succeed or fail, then figure out if any failures can be traced to the design.
Once the feature is released to the public, usage metric information then flows back to the service team. Research often analyzes and translates this information into actionable design recommendations. Like all good design, our process is an iterative one. And the benefit of design and research collaborating together in tandem is that we are better able accurately to assess the efficacy of our design decisions, in order to continually improve the service experience.
