Blind spot

While looking up links on the topic of green and sustainable design, I came up across some disturbing facts. For example, the fact that Apple, as a company, rates pretty low on several environmental ratings, including the Greenlist from Greenpeace, and Scorecard from Climate Counts.

Climate Counts rates Apple at 11/100 on a scale that measures climate footprint, efforts to reduce impact on global warming, support for progressive climate legislation, and public disclosure over climate-related actions – a score that is well behind companies such as Motorola, Sony, and Nokia.

I received a bad case of cognitive dissonance when I read the Scorecards verdict on Apple: ”STUCK – A choice to avoid for the climate conscious consumer. This company is not yet taking meaningful action on climate change.“

I think of every single article I have read over the iPhone; all the the press and the buzz and the wow. And not a single word of it referred to climate or sustainability issues. Funnily enough, there HAVE been improvements in the “greeness” of the iphone, but noone is really talking about it. We are more interested in the slick new interface, the price, missing bluetooth functionality, and the way this wonderful little hunk of electronics is revolutionizing the mobile industry.

They (public relations, media, bloggers…) are not telling us about responsible design, and we are not asking about it.

Why not?

Socially responsible system design

“Systems theory lies at the heart of the design process,” a quote from Jan Nichols in his article ‘A Hearty Economy and Healthy Ecology Can Co-exist’ in the current Journal of Interior Design.

He goes on, “We cannot design with segregated elements; all must work together in the systems we create. The design process is organic and, at its essence, must respond to a changing environment in the same way life forms adapt to environmental alterations. This process moves us beyond tapping into biophilia—the method that Stieg intelligently suggests—to design by biomimicry (Benyus, 1997), which means recognizing organic patterns and natural connections, understanding the causes and effects of competing and interrelated components, and then making appropriate design modiications. We intuitively design for flexibility, adaptability, universality, and plan space for growth, restructuring and contraction. In its inherent capacity to adapt, deconstruct, and recreate as needed, the design process mirrors the actions of living organisms. Therefore, the educated and experienced designer uses the model of systems theory during the routine course of project work. If any professionals understand that success doesn’t occur in a vacuum, and that everything affects everything else, it is those professionals who design the built environment. Systems theory gives us a basis upon which to model an earth-altering paradigm shift (Hawken,Llovins, & Lovins, 1999). “

It brings to mind Bill Buxtons keynote at CHI 2008, where he basically put out a call for designers to consider the wider implications of their designs…to think in systems rather than just software.

I’m sympathetic to and inspired by such calls to action, but to be honest, I find the whole process little daunting. I look at the projects I am currently working on: the complexity of the processes we support and diversity of our users, the gaps in our understanding, the requirements coming in from different directions, and the fact that we have to get a product designed, built, and shipped by…well, by yesterday. And then I think of sustainable design, of systems thinking, of ecological and social responsibility; and I have to admit that I’m not sure if all of these wonderful concepts and considerations can comfortably fit into my already strained work day.

I am also aware that I am working for a business. As an interaction and product designer I come up with many wonderful ideas about how to improve our software, of which only a fraction of which make it through the various organizational filters (are we willing to invest in this type of design/technology? do we have the resources? does it make us money?), and into the actual products.

It’s an interesting dilemma. I will be posting more on this soon.

User experience: more than just a product?

I read this hefty (101 slides) slide deck on the topic “Are you an user experience designer” today. While some of the discussion was focused on semantics (read: not so important to daily work practice), one distinction the author made did shed some light on the difficulties I’m having in my current position; namely, the difference between designing the experience of the user when they interact with a product, and designing the *entire user experience*, which also includes support services, marketing, branding, and all contact points that the user has with the company in addition to the product itself.

Being in a UX design and research role I often come across aspects of user experience that I cannot change through product design. For example, I talk to many users who are not aware of a certain modules that my company offers, although these modules could be valuable to them and their business. This education of our users and customers is, for the most part, a marketing issue, but I come across it quite often in my work.

The question then becomes whether I decide to accept this as a problem that the UX team wants to try and solve.

One thing I did during my first few working years is to take every major user problem I came across and try to find a solution. It sounds like a good idea, but the end result is that I spent a lot of time running around talking to other departments and trying to move things along that were not really my responsibility or under my control. I realize now that I ran into a lot of problems because I hadn’t clearly defined the boundaries of my work and domain.

There is, of course, value in collaboration with other areas in the organization. For example, we are currently working together with Marketing and Support to create a ‘Tips and Tricks’ section to put in our monthly user newsletter. On the other hand, the aspect of my work that often suffered as a result of my ‘extra-curricular’ efforts was what I now see as the core of my responsibilities – that is, the design and development of our products.

There is also the question of whether certain user problems are best solved through the product itself – by including some blurb text in the interface about other software modules the user is not aware of, for example -  or through some other means, such as through our user newsletter or product pamphlets, or through a combination of the two.

This topic brings to mind a write up of a lecture I recently read by Don Norman on the design of services.

As of now, I am not entirely clear on the boundaries between the user experience of the product itself, as opposed to the users experience as a whole – including marketing/branding, support, and other contact points with the company such as sales and billing. A lot of the UX literature I read comes from design firms such as Adaptive Path who seem to have a say in many aspects of product strategy and branding that are simply outside of the realm of a UX specialist working inside a larger organization. This trips me up sometimes. I think that being aware that a distnciton exists will, however, help me make better, more focused decisions in the future about how I spend my time.

Write for software as if you were a person

The documentation specialist and I had a nice discussion this week about the ‘tone’ of text in our software and documents. We would like to set a standard. Should we be friendly but professional? Should we be more buddy buddy like some of the web apps out there? Then how do we deal with languages were there is a formal ‘you’ and an informal ‘you.’ Of course, we want to keep the text we use as simple and direct as possible so as not to clutter the interface or our users lives…etc.

When we asked the opinion of our manager, however, he said something quite wonderful: “Our software and help should sound like one of our support staff was there helping the user.”

This made me smile immediately. “Yes!” I said, making a strange happy fist movement, “That is exactly how we should write it!”

We still have to work out the details of couse, but it helps to have such a benchmark to work from. Developing software and interfaces we sometimes get so caught up in the details and logic behind what is happening, when all the time a more personable and holistic view can make everything so much simpler and better .

Standards vs. design?

My past week at work mainly involved updating our standards/style guide website for our company. I found the task unusually difficult – possibly because I decided just last week to focus on designing and design work, possibly because I subscribe to agile methods, which are not so hot on time-consuming deliverables, and possibly because updating standards is just plain boring.

I was educated in classic HCI and usability methods, however, and so I do believe in the value and important of style guides and standards – particularly in an organizational context.

This rambling post is an attempt to explore the value of standards at my company, as it is not entirely clear to me at the moment.

The purpose of our corporate style guide is to support the development of a unified and usable product suite that presents consistent branding, interaction, and navigation to our users. Our site is a resource for internal developers/designers when designing or redesigning products.

The purpose of my design work is to create a product that supports user processes and needs, to provides a user experience that supports my companies brand goals, and to do this with the minimum amount of complexity during product development.

Of course, sometimes standards and optimal product design bump heads. The simplest design that could be created for a new product will not always comply to the standards defined for a set of existing products. While the standards we define related to terminology or colour palette are definitely valuable, the value of other standards that we are defining related to interaction style is still unclear to me. We often create an entirely new design for a new product, e.g. with a different navigation structure to support a more complex product, which makes any standards for application navigation somewhat irrelevant.

Our solution for this has been to create a “style guide” along the lines of Microsoft Vista User Experience Guidelines. We have certain standards related to look and feel of elements in a page, and provide examples of good design, but leave it open regarding the layout of a given product. We spent this week creating a solid basis for the style guide, including basic screens, widgets, pop-ups, and navigation, but since the standards are in their infancy (we have not yet created a full-scale product with them as a basis), we plan to update and add new items as we move forward on our project work.

The worry I have is not the use and value of this guide within our project team – this is clear. What is not so clear is the use and value of the standards to the rest of the company (and why I am spending all this time on a nice website so that the standards are accessible to them). If we continually change and update our “standards” they are not really standards. And style guide only has value to the rest of the company if people are motivated to learn it and follow it.

A company like Microsoft has the advantage that they have already gone through many iterations of products and have a good idea of what kind of standards and guides they need to provide. Even they (or perhaps I should say especially they), however, have problems. At a talk regarding standards at CHI 2008, the Microsoft representative basically admitted that Microsoft had a number of different standards floating about, and no single body overseeing standards development within the company. I totally understand this. Too many standards basically stifle creativity, and the ability to explore better interaction design using new technologies/ideas. I don’t want to imagine political battles that a “standards police” could get into when trying to pull together a single standard from the work going on in many different projects.

Bringing this back to my own work…we have one basic ‘portfolio’ team which the UX team is part of, but there are several other development teams working on customer projects and making changes to existing products. I realize now what part of my reluctance in making our style guide. At a company like Microsoft, they have teams of designers working on their products that will actually read the user experience guidelines. At my company, we have teams of developers who are under a lot of pressure from customers (usually a 2-6 week time-frame for each project), and who are very unlikely to read and apply design guidelines, especially when adhering to such guidelines would mean that they would have to push to extend the project deadline.

Perhaps the solution here is that the UX department needs to do some aggressive marketing of our style guide to management and developers. The more I consider the problems I face everyday as a UX designer, the more I find that culture and awareness of UX issues are just as, if not more important than any standards, process or individual activity.

…

You know, I have a quote sitting on my desk at home, exactly because I know that I have the tendency to overthink things: “There is no solution, because there is no problem.” I wonder if this is true for this direction of thought. Perhaps the relationship between development, design, and standards is simply one of growth and simultaneous evolution. One changes the other, and eventually there will come a time for change e.g. an overhaul of the style guide, or a redesign of all existing products.

Maybe I just need to accept this and move on .