Values in Software Design Practice

by John Schrag on July 10, 2009

Every user experience (UX) designer who practices in a corporate setting knows the breathless whirlwind that is modern business.  We designers manage relationships with developers, business managers, and customers, and still have a full-time production role researching, designing and validating features and interactions.  We rarely have enough time to do everything we should, and therefore have to carefully choose where to spend our time and resources.  Some designers don't even have the luxury of such choice, and instead are tasked with specific deliverables, which are sometimes not the best use of their time.  In the face of this industry-wide problem, it's no surprise that dysfunctional design practices can arise and even become so common that they are seen as normal, or at least inevitable.  But I don't believe they are.

In 2001, a group of software developers, development managers, and consultants created the Agile Manifesto, a document that outlined a set of simple values that they believed were the foundation of good development practices.  What is interesting about this document is that it makes no reference to specific practices or buzzwords -- instead, it outlines principles and values against which any particular practice can be evaluated.

In the same spirit, my co-workers and I spent several hours considering the question of UX design practice.  We weren't considering the question of what makes good design;  there are innumerable books on that topic.  We were considering the question of what separates a healthy, effective design practice from the horror stories we hear about when talking to others in the industry.  We came up with two lists;  the first list (below) talks about doing certain actions in the right order.  Reading the list, these orderings may sound obvious, but they are by no means standard practice:

Setting Goals before Taking Action
Understand Problems before Generating Solutions
Designing before Writing Design Documents
Validating Designs before Investing in Code
Steak before Sizzle

The second list is one of relative values.  While all of the items on both sides of this list have value, we value the items on the left more than the items on the right:

We Value:

Validated Data over Expert Opinion
Quality of Data over Ease of Data Collection
Complete Workflows over Long Feature Lists
Achieving Results over Writing Reports
Collaborative Design over Design by Referendum or Design by Fiat
Ease of Use over Ease of Coding
Well-designed Critical and Common Workflows over Complete Coverage of Every Possible Workflow

Of course, a few words in a list doesn't capture these ideas all that well.  In future blog posts, I'm going to talk about each of these items in more depth, show examples and talk about what can be done to keep your design practice healthy, even in the face of the whirlwind.

Do you have more items for our list?  We'd love to hear from you.

Comments

[reverse phone detective]

In the same spirit, my co-workers and I spent several hours considering the question of UX design practice. We weren't considering the question of what makes good design; there are innumerable books on that topic. We were considering the question of what separates a healthy, effective design practice from the horror stories we hear about when talking to others in the industry.

[Mark Spencer]

This is true we designer do a lot. communicate with the management, interaction with the clients to understand the requirement then start design. Your steps are in order and perfect to follow.

[Sam Pierce]

Exactly strategies always works, make a plan, set your goals or strategies are to move from point A to Z. How you will reach there and steps you will follow.

[tinggi badan]

In the face of this industry-wide problem, it's no surprise that dysfunctional design practices can arise and even become so common that they are seen as normal, or at least inevitable. But I don't believe they are.

[cara meninggikan badan]

In the face of this industry-wide problem, it's no surprise that dysfunctional design practices can arise and even become so common that they are seen as normal, or at least inevitable. But I don't believe they are.

[Logo Design]

well, reading your content very late but i would say the second list is very fine.

[John Schrag]

Sorry for the late reply -- just got back from vacation.

@Jason Grant:
"Design by Fiat" means your design is based on the unsubstantiated opinion of one person. (Usually a designer with an overly-high opinion of his or her own abilities.)

@Jeremy Kriegel:
Our list was never intended to be Agile, although I admit I have a strong preference for working on Agile projects (so long as they have a good agile design practice).

I think you make an excellent point about the "ordering" list --- that the activities on the left don't necessarily need to be completed before the activities on the right, but they do need to at least start first. That being said, the common problem I've seen is where the activities on the left are excluded altogether "because we don't have enough time".

I'm not sure I agree with your last paragraph, though. All projects are constrained in time and resources, and I believe that these values can be applied at different scales, depending on the appropriate level of resources.

[Jeremy Kriegel]

My initial reaction was that your first list was somewhat un-agile ('though I suppose you never said you were trying to align with agile). However, with some modifications, I think it might be close and a bit more nuanced.

We value:
Setting Clear Goals before Taking Extensive Action
Understanding Problems before Generating Exhaustive Solutions
Validating Designs before Investing Significant Effort in Code
Steak over Sizzle

I think emphasizing the magnitude of activities on the right allows for more of an agile bent. It allows for some activity on the left to precede some activity on the right, but does not imply that activities on the left must be done in their entirety before starting activities on the right.

As discussed on the UXAgile list, expert vs. data may not be valid, and I believe it is subsumed in the second point of quality over ease of collection. An expert may be easier, but the data may or may not be better.

As far as the other values, I think they depend on a project's definition of quality. If that definition is high, then these values apply. However, not all projects are aiming for a high degree of quality. In these cases, we do our best to work within the constraints we are given.

[Jason Grant]

What does 'design by fiat' mean?