This NYTimes.com article on the foundation of Italy’s economic woes. Many of them stem from the effects of globalization on the practice of bespoke manufacturing. The article shine a light on the fact that in this day and age, even the highest level of luxury and quality are trumped by efficiency.

This quote shines:

In the eternal contest between the meticulously honed and the nationally franchised, Italy knows where it stands. As a matter of profit and loss, it doesn’t make sense to store wool in a spa and let it convalesce for six months, but the methods of Luciano Barbera were never destined for a get-rich-quick guide to manufacturing. His business will make sense only to customers, and for them, quality has a logic of its own.

THe new breed of social games feeding off of Facebook is fascinating. In this NYTimes article Seth Schiesel summarily captures the essence of these games, which is that they are business machines ingeniously cloaked in the veil of interactive entertainment.

When you talk to most designers of great games they will tell you something along the lines of, “We make the kind of games we would want to play.” That never feels like the case with Zynga games. To me, a game like FrontierVille says, “We make the kind of games we think can best attract and monetize the most number of people with credit cards who don’t mind dropping $10 or $20 once in a while for a virtual tchotchke.”

He goes on to describe how the social reward systems for these games lead to additional customers. All in all, the article does a great job summarizing Zynga’s successful tactics.

Scott Berkun has some deep thoughts on the plague of “not invented here.”

An executive might proclaim the wonders of the new (worse) thing to his division without encountering anyone willing to stand up for the old (better) thing. It’s harder to inflate the importance of one’s own work if the key decision was to buy or borrow from elsewhere.

Great organizations reuse, repurpose, and extend that which already works. By reusing that which already exists, and is known to work, time and effort can be better focused on that which is new and innovative. Within the context of the large organization, innovation is far easier when the ethos is not to reinvent, but to explore that which is new.

I couldn’t agree more with these twelve beliefs. As a manager of incredibly creative and talented designers, I have found that these beliefs are especially crucial.

Design Thinking is a great thing, especially when the end result is great design. This free primer on the topic, however, is simply a case for bad graphic design. Sure, the concepts within the package are good and useful but - please, please, please Stanford d.School - hire professionals to do your branding.In general, one of my complaints with design thinking is that it is too much about the process, the concept, the business and the engineering, and too little about aesthetics. Aesthetics is what is core and fundamental to great design - it’s part of the total experience that actually immediately touches people. For some strange reason, much of the propaganda around design thinking seems to consider aesthetics as an afterthought, or ignores it altogether. Perhaps it is because those who have established the notion of design thinking see aesthetics as so fundamental, that they fail to mention it?

People work for more motives than money.

I’m a sucker for behavioral economics, which means that Dan Ariely’s book the “Upside of Irrationality” most definitely makes my reading list. Today driving home from work I heard Dan interviewed on NPR. Here’s the audio of the interview:

The bit that stood out to me was an experiment that Dan conducted with legos. In this experiment, he used two scenarios involving lego robots. In the first scenario, people built robots, one after another, and were paid on a diminishing scale. It was up to the participants to decide when the benefit of building robots was not sufficient, and then they stopped.

The second scenario took place using the same conditions, but after each robot was created, the experimenters disassembled the robot before the eyes of the participants.

In the second scenario, participants stopped far sooner, and reported that they enjoyed the act of creation less. And when the experimenters asked how much people enjoyed legos in general, those who enjoyed legos in general persisted in their task longer. But in the second scenario there was no correlation.

Ariely postulates that the negative effects of the second scenario are due to the fact that when the creations of one’s labor are destroyed before their eyes, they joy of the task is choked out of it. As a result, people gave up much faster, and enjoyed the job less. In other words, when we destroy the meaning of a person’s job, we jeopardize both their satisfaction and their motivation.

This all seems obvious, but at work we are rarely building lego robots (darn). Instead, we are building a report, or a design, or a full fledged product. Not everything everyone does will be correct, or successful. But the key take-away that I received from Ariely’s research is that in order to support motivation, it is crucial for managers to recognize the hard work that people put into their creations. And if the work isn’t right, the next step is to provide a higher level meaning to the critique (or the destruction), in order to maintain motivation.

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

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.

Jakob Nielsen’s latest recommendations on Agile and UX parrot his originals:

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).

More Nielsen on Agile, here, and here.