Closed down

December 9, 2008

Hello, due to irreconcilable differences between me and the wordpress interface this blog has been moved to http://ausefulrecord.tumblr.com/


Blind spot

October 19, 2008

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

October 19, 2008

“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?

October 17, 2008

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

October 9, 2008

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?

October 4, 2008

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


Hooked back up and considering the purpose of things

September 23, 2008

There was an interesting article by David Malouf on the similarities between industrial and interaction design. I’m still struggling with that one. I wish I had the time right now to sit down and work it through as there are many half-baked ideas bumping around my head.

Industrial design is something I know relatively little about, but from what I have gleaned so far, it is a craft that involves the execution of an idea, the creation of an artifact, or the expression of a concept…essentially, the creative shaping of objects in peoples lives towards a particular effect.  The goal is the effect.

Interaction design in contrast…well, how can I describe it?  The goal of interaction design is the creation of processes within the lives of our users. In my conception of interaction design, creativity or any kind of emotional design is simply a means to an end. Interaction design is the creation of a product. The goal is the product – the business  – and the work of an interaction designer is to support the product and the business.

…and here is were this post ends, because it’s 1am and I have work tomorrow. You know, I never thought I’d say it, but I do kind of miss grad school, where it was my job to think about these kind of things…


It’s been a while…

September 22, 2008

It’s been a while since I updated this blog. A lot has been happening, including a slow shift in my professional work from ‘agile usability specialist’ to ‘agile user-experience analyst.’ And don’t ask me just yet,  because I’m still not entirely sure what the title means myself.

My work in the past year has run the gamut from user research and requirements gathering, to user testing and evaluation, to interaction design, to product ownership and product development. In general, I tend to favour the latter tasks, although most of my skills and training are in the former.

I have been doing a lot more design. Real design, and not the usability-based interface creation I was taught in my HCI classes. It has been a bit of a stretch for an analytical thinker like me to squeeze my head into a creative and intuitive design space. Nevertheless, I find the insight, freedom, and plain old fun that can be had while designing to be simply wonderful.

My positive experiences with design so far, including recent participation in several design workshops at the Agile 2008 conference (e.g. an insightful Design Studio from the folks at Adaptive Path), have definitely enriched my life, and I’m interested and excited to learn more.

In light of this I decided to revive my dusty blog and spend some time over the next couple of months doing exactly what I have been considering for a while now – exploring user experience, exploring design, and finding a space where I want to fit myself into for the next little while.


Agile is a cooperative game

July 26, 2006

The connection, in my mind, between agile environments and game environments grows stronger the more I learn more about what motivates people in software development teams. Agile environments provide feedback, engagement, and a sense of flow stemming from iterative development, a shared team room, and surmountable challenges in the form of stories. There are increasing ‘experience points’ as you move up through iterations and develop skills; and there is even a ‘reload’ option, where if everything goes terribly terribly wrong you can always go back and restart from the last time that all the tests were working. Some teams that are keen on information radiators even make good use of buttons and lights, which makes me imagine a truly engaging team room environment modelled after an arcade game :-).

It’s funny how it wasn’t until after I chatted to several people at Agile 2006 about this flow/game idea that I decided it was worth writing down. Go social constructionism.


Human response to change

May 16, 2006

I was thinking about human response to change. Most models in organizational psychology include a transition from normality to a period of disruption (generally accompanied by decreased performance), then return to re-defined normality. For example, Lewin’s (1952) model of freezing the normal state, moving, and then unfreezing. Or the Kubler-Ross (1969) model, where people go through various stages of denial, anger, bargaining, depression, and acceptance. Interestingly, although the Kubler-Ross model was originally created to model reaction to death and dying, it has been shown to apply to people responding to significant change in organizational settings (Zell, 2003).

It strikes me that there do not seem to be any valid models of human reaction to constant change (that I know of). I vaguely remember reading in my org psych class about systems of constant change, but I do not remember reading about any models explaining human reaction to such change. So how do humans react to environments of constant change? Do the same models apply?

I had a conversation with Jeff Patton at the CHI conference last month, and he talked about people who had strongly practiced pair programming in the past had now gone back to working separately for the most part. Aside from the fact that pair programming might have diminishing benefits, could this reversion simply be a reaction to change? It would be interesting to study the long term adoption of these kinds of practices.

I guess this is why some people stay in school their entire lives…