David McCandless over at the fantastic blog Information Is Beautiful provides this visual attempt at defining the qualities of good information design.
I was recently reminded of these. It’s good to always keep them in mind.› Good design is innovative› Good design makes a product useful› Good design is aesthetic› Good design helps us to understand a product› Good design is unobtrusive› Good design is honest› Good design is durable› Good design is consequent to the last detail› Good design is concerned with the environment› Good design is as little design as possible
Theresa Neil, author of Designing Web Interfaces, recently presented these slides at a conference in Malmo, Sweden. Seems like every other conference is located in Malmo, strange.
Check out Theresa’s blog for a good focused look into the world of prototyping tools. Her favorite tool is Balsamiq Mockups, which is indeed a useful tool.
From Fortune’s article summarizing why Steve Jobs is the CEO of the decade:
For those paying attention after Jobs’ return, the CEO was telegraphing Apple’s trajectory. “I would rather compete with Sony (SNE) than compete in another product category with Microsoft,” he told Time in early 2002. “We’re the only company that owns the whole widget — the hardware, the software, and the operating system. We can take full responsibility for the user experience. We can do things that the other guy can’t do.”
A while back I started writing a multi-part series on Adobe’s approach to designing services. Well, my life became too busy to complete the series, but I captured a summary of my reflections in an article, originally posted on the INSPIRE website. Here’s the article, in its entirety. I’m interested in your observations on it.
—
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.
The two main recommendations for ensuring good usability in Agile projects remain the same as in our original research:Separate design and development, and have the user interface team progress one step ahead of the implementation team. That way, when it comes time to build something, it’s already been designed and tested. (And yes, you can do both in a week or two by using paper prototypes and discount user testing.)Maintain a coherent vision of the user interface architecture. Create the initial vision during a “sprint zero” period — before any implementation has started — and maintain it through annual (or semi-annual) design vision sprints. You can’t just design individual features; they have to fit together into a coherent whole — a whole that must be designed as well. Bottom-up user interface design equals a confused total user experience (the Linux syndrome).
Now that Jojo and I have a newborn beautiful baby, I’ve become interested in the theory and practice of early childhood education. One unexpected discovery that has amazed me is how the intellectual needs of a growing child change nearly weekly. Infant minds are like sponges, in large part because they start relatively empty, and grow even as they are filled.
I’m also fascinated by how explicit the link between a young child’s mind and body. Children learn by exploring not only with their senses, but also with their entire bodies. As they grab, flail, kick, and squirm, their mind organizes all this physical data into new structures.
With that in mind, it’s no wonder I have a new-found respect for the iPhone as a compelling platform for children’s educational games. They blend notions of early childhood education with a certain physicality.
Take for example, this new game called ABC Oddity. It offers its kinder-user a fun, stylish, physically engaging way to get more familiar with the ABCs.
In my opinion, the NYTimes.com provides some of the best interactive (and static) infographics around. The designs are usable, readable, and beautiful, and they communicates the right information in the right way. In other words, their designs seem to be greatly aligned with the principles espoused by Steven Few, one of my favorite visual thinkers.
The team behind the designs has created a portfolio of their work aptly titled Innovation Portfolio. The site itself is a great example of the team’s consistently quality work. Give it a spin.
Also, Fast Company has a short article about the site.
A fitting follow up my last post on Ford’s use of personas - here’s an interview of Adrian Hooydonk, BMW’s head of design, by Tyler Brule, the editor-in-cheif of Monocle.It’s interesting to note that BMW’s focus is on designing in response to mega-trends, and the idea of trust in the designer’s intuition. In other words, it seems that design at BMW is driven far more by the insights and talents of designers than by cold, hard, objective data.
This great article in the NYTimes highlights Ford’s use of customer “archetypes” in car design. Archetypes and personas are fundamental to user-centerted design, and it’s great to see that they are used in such a critical way throughout Ford’s design process.
Perhaps Ford’s focus on it’s customer’s usage of and emotional connection to the vehicle have helped to contribute to it’s recently improved performance.
Ethan Eismann is an Experience Design Manager at Adobe Systems. This blog is about Flash, Flex, AIR, Flash Catalyst, RIAs, design management, and design writ large.
