Coopers vision of agile

Alan Coopers view of Agile by Alan Cooper on July 31, 2009

"Lots of ivory tower software experts cheerfully follow their own muse, but in the world of business, the dreams of money-makers are usually in conflict with the dreams of geeks.

In the business world, software developers have always been the whipping boy. In commerce, the delivered-software never matched the envisioned-software, and the technologists got the blame. Executives have always been unhappy about their inability to effectively direct and exploit software development. The only tool that seemed to get results for managers was to keep programmers on a ridiculously short leash by allocating resources in tiny increments. The results weren’t good, but they tended to prevent colossal disasters, which was, apparently, good enough for business.

Over many years, in self defense, programmers increasingly hunkered down to protect themselves. They aggressively lowered the expectations of their managers. They tried to commit to the least possible performance to avoid blame. All they really accomplished was to avoid good performance.

Nobody was really very happy with that situation, but it was good enough to provide most programmers with a decent living and some self-respect.

But many programmers are more ambitious than that, and most of them are used to higher levels of achievement than just “good enough”. All of that mediocrity has generated a lot of frustration for many programmers. Extreme programming was one method whereby developers could force business people to view the consequences of their decisions.

Extreme programming showed developers that there was power in self-determination, and in reaction to all that old defensive stuff, many programmers have finally said “Enough is enough”. They emerged from their bunkers to become proactive in *guiding* the development process rather than just doing what they were told (and then getting blamed for the failure that results). And agile is the mechanism they used.

I’ve long been an advocate of such technological-craftsman-self-determination. It’s just that I advocated it via the “interaction design” point of view. Therefore, agilists and I are on the exact same wavelength.

Now, there are some agile programmers who think that they are dealing with *technical* issues rather than social ones. If you ask me (no one ever seems to actually ask me), these people are trying to take TWO steps backward: they don’t want to return to the hunker-down phase, so they want to reinstate its ivory tower antecedent, that small-world-coding-happy-place that existed before software went big time. That place has never existed in the commercial world.

To my mind, agile means taking responsibility for making a good product. Even if you used test-driven-development, pair-programming, retrospectives, stand-ups and all of the detritus of “agile” but then built a product that nobody liked or wanted, then it wasn’t agile.

One of the responsibilities of software development is to assure that the right product is being created, and then to create it in the right way. The only way to accomplish this is to apply the best practices of programming, design, and all of the other associated disciplines and crafts. *TRUE* agile means integrating these crafts into a joyful, unified, productive whole."

Values in Software Design Practice

A really useful post from Autodesek on the values required for software design practice, this I feel links in with the values outlined out in the IE.

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.

How to get better results from developers

A somewhat topical discussion with the change of location for the the work - there really is a great point of re-addressing the us vs them approach. We are all in software development together, how much of an aspect of this is really discussed in the UCD approach?

Overall, I think you have some valuable insights, but the way you express them belies what I think is a wrongheaded approach to interacting with devs. The subject line as well as numerous things in the text imply a goal of manipulating and controlling and conflicting (and even condescending) with devs, which I think is not the best way to create an effective team. More inline. My reason for taking the time to respond in depth is in the hopes of creating more empathy and a better way [trim] Ambrose,
Right on the mark.The "us" vs. "them" attitude never works. We're all in this together.

I think the methodology has to really capture this aspect, but as said further down in the thread

Much of this assumes you are all working to the same objectives towards something better. Often teams don't and that's where the problem lies.

So is this something that can be captured?


The full post below How to get better results from developers

Earlier this week at the local Utah IxDA meeting and over the last while at various places I've heard the topic of how to deal with developers come up. I was thinking about it and realized I had a lot to say about it. Sorry for the length : )

I currently work at a very small company, less then 20. But compared to the other stories I've heard lately from Interaction Designers like myself in Utah, our company gets surprisingly consistent results from our developers in regards to design. Following are my 13 lessons that have helped me get better results from the developers I've worked with.

1. Be a developer

I can't stress this one enough. Development isn't something that can be appreciated, it has to be experienced. HTML and JavaScript don't cut it, you have to go out and actually do what your programmers do. Write SQL statements, create classes, build an application. When you can follow along and contribute intelligently to all the technology discussions, the developers will start to trust you that you understand them. Let alone the fact that you will be able to call them out on their bullshit, and yes they bullshit a lot.

2. Get in bed with the business people

At the end of the day the business people run the company and they control what the developers do. At my company I spend a great deal of time with our project manager, VP and CEO. I try to develop personal relationships with them. I make it obvious that my goal in life is to help them articulate what they want to the development team. Then when I present something to the development team, it's not my idea, this is what the boss wants so you better get it right. There is nothing more powerful then presenting a finished interaction document to development and saying that this is 100% approved by the CEO. And in the end the developers are actually happy you managed all that back and forth crap with the business guys so they don't have to.

3. Ease their pain

Developers just want to develop. They don't want to worry about requirements gathering, deadlines, art, research, politics and all the stuff that goes into running a project and a company. So the more you take responsibility for all these things they don't want to do, the more reliant they will become on you. When they need something from you, do it fast and with a smile. The more enjoyable you make their lives the more responsive they are going to be when you ask them to do things.

4. Force business to iterate in design, not in development

There's nothing a developer hates more then spending months on something that once the business guys see it they realize they want to do something else. I won't hand anything off to the developers until I have thought it through and iterated through it with the business guys as much as humanly possible within the time I was given. There are many decisions that can be made off of drawings rather than programming it. And business will quickly realize that getting the designers to change their designs is a thousand times cheaper than paying those expensive developers.

5. No one gives a rip what the artist thinks

The irony is they hired you to be the design expert, but they never listen to what you say. And guess what, they never will. You have to get over the illusion that they will do what you say because you know better, it doesn't happen. To be happy you have to accept the fact that you will never get to design what you want. Instead you have to learn to enjoy the reality that you are there to facilitate and assimilate everyone else's ideas into a single coherent whole. If you need an artistic outlet, do it at home, or you'll always be bitter.

6. But you do get to do what you want

Once you've checked what you want at the door, something amazing starts to happen. The funny truth is most business guys and most developers don't want to think about the details, so you get to! Other people on the team only care about their pet features, no one wants to take all that time to think through the rest. So as long as their pet issues are represented, you get to fill in the rest with whatever you want.

7. Write it down!

The beautiful thing about writing is it's the universal standard for communication. Yes a picture is worth a thousand words, but you cannot draw interactions as well as you can write them. My documentation is a mix of what we call "stories" with supporting graphics at key points. My friend is an html guy at a large company and his biggest complaint is that he gets handed a large photoshop file with no documentation. Somehow he is supposed to read the mind of the of the designer to figure out what actually happens in ui when the user interacts with it. The designer has failed to communicate the interaction. Writing is a royal pain in the ass, but it is incredibly effective at communicating the interaction to the developers and the QA team.

8. Get in bed with the QA team

The QA team is the group of people whose job it is to tell the developers they did it wrong, they are your enforcers. The better they understand what you wanted from the developers the better they are going to be at telling the developers what they did wrong. It's critical QA has the right kind of documentation to do their job, and you want to be in charge of that documentation. The cool little secret about QA is that they like checklists. I write my documents so that they are essentially checklists that the QA team can say, hey dev, item 3.i.b is wrong, fix it.

9. You have to have a middle man

Developers do not like to do HTML. It's a fact of life that will never change. As much as they think HTML is easy, it takes just as much concentration to do HTML as it does any other kind of development. In my experience the very best scenario is to hire a UI developer to be the middle man. In the web world this is called a Web Designer. A Web Designer is someone who cares about the visual details, but they can also code. If you don't get this guy you'll always be fighting a losing battle with the developers because they don't want to do HTML, they don't give a rip about visual details and you don't have the time to program the HTML either.

10. Sit next to them

There is a direct correlation to your physical distance from the developers and how effective you will be with them (remember Fitts' Law?). Currently I sit right next to my developers. I hear everything they say, I'm accessible, we go to lunch, I know what they are doing and saying. If you hide in an office or work off site, you're screwed plain and simple.

11. Spend time with them

This one should be obvious, but there's a basic rule that the more time you spend with someone the better you are going to be able to interact with them. Be friends with the developers, kick their ass in Team Fortress, go to lunch, carpool, whatever it takes. Get in their face and take as much time to figure them out as you do figuring out your customers. Do you even known your developer's names? Have you spent enough time with Derron to understand why he is such a grumpy prick?

12. Learn to articulate well

This is where studying design comes into play. Design is difficult to communicate verbally, it's naturally an intuition and feeling thing. But the cold hard fact is no one is going to trust your feelings, people will always want reason and logic to make decisions. So you have to learn to verbally articulate your feelings. The good news is there actually is logic and reason to art, but the bad news is it's one of the most complicated things on this planet. Learning to verbally articulate design takes time, there's no way around it. You simply have to study it. Study how other designers talk, learn patterns and read design literature like a mad man. And what will start to happen is you'll actually be able to argue for a design and win.

13. Good design is always hard to program

I finally realized this universal truth. What makes sense to a computer does not make sense to a human being. It takes a lot of hard work to get a computer to speak human. This is what you are trying to do as a designer. Developers are incapable of this because of the very fact that their job is to speak computer. Your job then is to force the programmers to make the computer to do something it was not meant to do. That will always mean that have to personally generate an incredible amount of extraneous code, blood, sweat and tears, everything they hate. This is why there will always be an eternal conflict between developers and designers, because your job is to make their life difficult, plain and simple.

That about sums up what I've learned so far. I hope this is helpful in some way. The painful truth is that design is a pain in the ass, and getting developers to do what's right for the users is like standing against a raging river. It's not natural for developers to do good design, it goes against their nature. Your job as a designer is to deal with this fact and somehow still get those developers to produce something human beings enjoy using.

What do you think? What have you found to be effective?

Cooper on Cooper vs Beck

A really useful piece from IxDA on the Beck (XP) vs Cooper (agile) of the discussion that was requested in a post. The most interesting post was from Cooper himself, who stressed how the discussion is no longer relevant with the changes that agile has come through both with the development of interaction design and agile community.

What I find really interesting is the point:

"Agile is a significant and positive movement in the world of technology, just as the movement for design has been. They are NOT AT ALL MUTUALLY EXCLUSIVE and I'm actively working with a broad range of agilistas to find effective common ground."

This is where my research research also lies in finding this common ground.

And although Cooper says

"Please don't listen to this recording.It was made a long time ago and it is NOT representative of anybody's current thinking."

From a research perspective, I think this helps to highlight the changing and evolving process of agile and so helps to emphasize the demands placed upon interaction design to mange and cope with finding and understanding where the common ground lies.

Cue a methodology...

For the full IxDA Cooper vs Beck post
http://gamma.ixda.org/discuss.php?post=41166

Alan Cooper

Sunday 9:29pm

Apurv,

Please don't listen to this recording.

It was made a long time ago and it is NOT representative of anybody's current thinking.

At the time, Kent Beck was pushing pure XP, which is decidedly NOT the same thing as what is currently known as "agile". My opinions about XP are NOT the same as my opinions about agile. In the years since that recording was made, much has been learned by both the interaction design community AND by the agile community about what the world of software needs and how our two practitioner communities can provide it.

Kent's innovations such as pair programming and test driven development are powerful and effective tools. When they are paired with the agile concept that I call "responsible craftsmanship", the synergy is fantastic. While Kent and I still have significant points of departure in our thinking, I'd wager that he would not take the same stance today that he did in 2004, and I know that I don't (would you?) . Over a year ago I asked Kent to record our "debate" anew, and while he was game for doing it, the logistics never came together.

Agile is a significant and positive movement in the world of technology, just as the movement for design has been. They are NOT AT ALL MUTUALLY EXCLUSIVE and I'm actively working with a broad range of agilistas to find effective common ground.

Please don't dredge up old arguments and mis-apply them to new ideas.

Thanx,
Alan
cooper | Product Design for a Digital World
Alan Cooper
alan at cooper.com | www.cooper.com
All information in this message is proprietary & confidential. "Whenever you are asked if you can do a job, tell 'em, 'Certainly, I can!' Then get busy and find out how to do it." - Theodore Roosevelt

Original Message
From: discuss-bounces at lists.interactiondesigners.com [mailto:discuss-bounces at lists.interactiondesigners.com] On Behalf Of Apurv Sent: Thursday, April 09, 2009 5:35 PM
To: discuss at ixda.org
Subject: [IxDA Discuss] Content of Cooper vs Beck

Hi all,

While looking interaction design in an agile context, I'm constantly coming across a certain very landmark public discussion from 2004 between Alan Cooper and Kent Beck (of Extreme Programming) mentioned across the web. It seems this was a very insightful discussion and I am very curious to read it.

The original link to the content however is dead - http://www.fawcette.com/interviews/beck_cooper/default.asp

Would anybody have a copy of it stored with them and be able to share it with me? I'd be humongously grateful!

Here's the link to the Cooper vs Bech discussion on IXCD years ago - http://www.ixda.org/discuss.php?post=1079

Cheers,
Apurv

Why Designing Products and Services is a Team Sport

A useful piece on Why Designing Products and Services is a Team Sport - by Peter Merholz Experience Matters - useful to think of in drawing on for my own methodology for the dynamics of working with agile development. A interesting point how the apple process of the continual iterations acceptance of end -

"So how can you avoid the blinking "12:00" products and the fragmented efforts that produce them? In the world of products, we see that focused, multidisciplinary teams deliver the best experiences. I interviewed Margaret Schmidt, Vice President of User Experience and Research for TiVo, for our recent MX Conference, and she stressed how the engineering, product management, and user experience teams eschew departmental hand-offs and reviews. Instead, product managers, marketers, designers, engineers, and user advocates work closely on a single project.

In his book Inside Steve's Brain, Leander Kahney explains Apple's design and development process: "Under Jobs' guidance, products are developed through nearly endless rounds of mockups and prototypes that are constantly edited and revised. This is true for both hardware and software [and their retail stores, it turns out]. Products are passed back and forth among designers, programmers, engineers, managers, and then back again. It's not serial."

In the world of services, make sure your project teams are multichannel. Coordinate in-person, online, phone, and mail interactions and communications. Recognize that your customer doesn't distinguish between channels they way you do, and make sure she's satisfied no matter how she chooses to engage.

Without such coordination and collaboration, companies will either deliver slapdash experiences, or, due to the gauntlet, nothing at all."

It concludes

"make sure your project teams are multichannel. Coordinate in-person, online, phone, and mail interactions and communications. Recognize that your customer doesn't distinguish between channels they way you do, and make sure she's satisfied no matter how she chooses to engage.

Without such coordination and collaboration, companies will either deliver slapdash experiences, or, due to the gauntlet, nothing at all." - I need to bulid further a wider the background collection of informaiton of socio-technical issues in knowdge communication.

- A further useful follow on by piece by Margaret Schmidt - TiVo VP Margaret Schmidt on Redesigning.

- And another piece on information technology and knowledge management.

Why information technology inspired but cannot deliver knowledge management.

Article Abstract:

Recent developments in information technology have inspired many companies to imagine a new way for staff to share knowledge and insights. Instead of storing documents in personal files and sharing personal insights with a small circle of colleagues, they can store documents in a common information base and use electronic networks to share insights with their whole community, even people scattered across the globe. However, most companies soon discover that leveraging knowledge is actually very hard and is more dependent on community building than information technology. This is not because people are reluctant to use information technology, rather it is because they often need to share knowledge that is neither obvious nor easy to document, knowledge that requires a human relationship to think about, understand, share, and appropriately apply. Ironically, while information technology has inspired the "knowledge revolution," it takes building human communities to realize it. (Reprinted by permission of the publisher.)

author: McDermott, Richard

Publisher: University of California Press

Difference between iterative and incremental development and a bit for agile

A really useful perspective on iterative and incremental development from JanBlog

"Do you sometimes also have problem to make clear distinction between iterative and incremental development? What if you should explain difference to customer or friend?

Hopefully these two pictures taken from Don’t know what I want, but I know how to get it will help you understand it.

When you work incrementally you are adding piece by piece but expect that each piece if fully finished. One picture is worth of thousands words :)
When you work iteratively you create rough product or product piece in one iteration, then review it and improve it in next iteration and so on until its finished. One picture is worth of thousands words :)
So is Scrum incremental or iterative?

It is iterative by the definition as we are running sprints. We are improving application iteration after iteration.

But I believe it is also incremental because user stories finished in sprint should be of shippable quality and therefore we should not return to them in next iterations.

So Scrum is iterative incremental process.

Is this your opinion too?"

I currently thinking scrum/agile must draw on a iterative incremental process.

This links with a a recently read question asked to Alan Cooper on
asking “Is incremental design the wave of the future, or just a flash in the pan?”

"As agile methods take over the programming world (and they will), EVERYONE else will adjust accordingly. The old paradigm of everyone hunkering down and protecting their turf from everyone else is what gave rise to the "traditional cycle" (which is, by the way, uniquely ill-suited to software construction and design).

The new (agile) paradigm isn't at all defined yet, but it characteristically includes a) Generation Y programmers; b) a refreshing belief in the potential for change; c) the understanding that satisfying human users requires special efforts and probably special skills; d) a belief that software should be built in continuous increments; e) a corresponding belief that everything else in the world relating to software would benefit from such continuous increments; f) that building software is a team endeavor; and g) that nobody has solved these problems before.

It's very reminiscent of the way I felt in 1976. At that time, all computers were multi-million-dollar affairs, residing in specialized corporate bunkers, owned only by large corporations, and used to perform operational business functions. I, on the other hand, had just purchased my first computer.

It was a 1MHz, 8-bit microcomputer with 8" floppy drives and 64K of memory. All of the then-current assumptions about software development, creation and use were marked for death as we Boomer Generation programmers began to invert the dominant paradigm.

Within 15 years, we had utterly changed every aspect of software and computing, and today's agile, Web 2.0, open source, Gen Y programmers will do the same, only faster.

Interestingly, the changes we wrought were almost all bottom-up. The only influence large corporations had on the great microcomputer software revolution were to obfuscate and delay it. And, of course, the reason why we study history is so that we can chuckle at the irony of its inevitable repetition. Today's changes are also coming up from the bottom, and big companies are doing little to help and much to hinder.

Thanks,
Alan"

Is there more scope now for understanding and demonstrating how the agile process should be without such hinder with the understanding how it can be used with UCD ?

Are We Designing Interactions or Designing Software?

A really useful article from the blog - graphpaper

Are We Designing Interactions or Designing Software?

February 11th, 2009

One of the problems faced by designers trying to integrate their work with most software development processes, even (or possibly especially) with Agile development, is that the literature makes no distinction between software development and software design, or at least no distinction that makes any sense to dedicated user experience designers.

The common complaint among interaction designers working with Agile is that, with some important exceptions, the design of the “user interface” is seen as a cosmetic final stage in the overall software development process. The fundamental designing of the software itself, however — the interactions, the mental models, the metaphors and behaviors — is built-in to the overall Agile process, woven in with with and indistinguishable from the software architecture and code development.

In Mitch Kapor’s Software Design Manifesto, originally delivered in 1990 and included in Terry Winograd’s Bringing Design to Software (1996), it’s clear that this ambiguity has deep roots:

Software design is not the same as user interface design.

The overall design of a program is to be clearly distinguished from the design of its user interface. If a user interface is designed after the fact, that is like designing an automobile’s dashboard after the engine, chassis, and all other components and functions are specified. The separation of the user interface from the overall design process fundamentally disenfranchises designers at the expense of programmers and relegates them to the status of second-class citizens.

The software designer is concerned primarily with the overall conception of the product. Dan Bricklin’s invention of the electronic spreadsheet is one of the crowning achievements of software design. It is the metaphor of the spreadsheet itself, its tableau of rows and columns with their precisely interrelated labels, numbers, and formulas—rather than the user interface of VisiCalc—for which he will be remembered. The look and feel of a product is but one part of its design.

On my first read, the whole terminology of this felt alien to me. Is the paper spreadsheet metaphor not the “user interface design”? It seems “look and feel” is being equated with “user interface” here, but I think he’s implying that what I consider the user interface is, in fact, the software itself. I suppose this is a more glorified definition of the word “software” than what I am accustomed to, one in which the software design included the mental model of the user’s approach to the software.

On my second read, though, it became clear that Kapor is in fact laying the early groundwork for what we now call interaction design. He still sees it as closely bound with programming, although he is clear that it’s not the same thing. He is also working in a climate where user experiences are far simpler than they are now — graphic capabilities were primitive, network interactions were almost non-existent, and interfraces had few modes, even few features. Today, with the high level of complexity of both computer code and user interfaces, it’s easier to consider the two challenges (user experience and code) separately — or even better giving primacy to the user interface — the part that people actually see and use.

Design and Technology

It’s obviously important that interaction designers are well-versed in what the technologies they are designing for can actually do. I wonder, however, what interaction designers today would think of the degree of technical expertise Kapor requires of designers:

Technology courses for the student designer should deal with the principles and methods of computer program construction. Topics would include computer systems architecture, microprocessor architectures, operating systems, network communications, data structures and algorithms, databases, distributed computing, programming environments, and object-oriented development methodologies.

Designers must have a solid working knowledge of at least one modern programming language (C or Pascal) in addition to exposure to a wide variety of languages and tools, including Forth and Lisp.

In preparing the syllabus for my upcoming course this fall at SVA, I am quite certain that I don’t share Kapor’s technical requirements for a software design education, neither specifically (Forth?) or generally. Instead, I think a firm grounding in a broad range of designed experiences far outweighs any need for hands-on experience in the deepest challenges of technology implementation.

Yes, some designers will delve deep into technology, being hands-on coders and fabricators of interactive artifacts. In fact, some great interaction designers already spend most of their days thinking of themselves primarily as technologists. Others, however, will focus on the design parts of interaction design. These people will most often work closely with other individuals and teams to implement their designs.

In short, great design will come from great designers, and great technologists will make those designs happen. Sometimes these skills will be found the same person, but increasingly not. An interaction design education should support both models, of course.

Interfaces and Software

Despite my difference with Kapor’s admonition, I still think that in a way we are coming full circle. The recently-articulated idea that the “interface is the spec“, or even “the interface is the product“, isn’t so different from Kapor’s thinking. The metaphors, mental models, and processes that users experience using the software are, in both cases, the most definitive and salient qualities of the “design” of the software (not, as many software development processes presume, the architecture of the code or the technical features that happen under the hood).
The important thing that Kapor left out, however, is that the “user interface” — the stuff that comes between human beings and cold hard technology – should be thought of as including graphic design as well as the underlying conceptual models of the interactive experience he rightly praises. In fact, the “user interface” concept should also include the software’s motion graphics, its sound and music, the copywriting, voice and personality, the community that builds around the product, and so many other qualities of software design that, frankly, had not really come to maturity yet in 1990.

We are only recently starting to appreciate the idea that interaction design is really about the intersection of the behaviors of systems and people (a favorite word of mine for obvious reasons). The explosion of new and innovative software experiences brought on since 1990 by the World Wide Web and console video games, I think, has fundamentally changed our understanding of what software can be.

Open source user experience - IxDA discussion

A useful thread from IxDA on Open source user experience useful to use for the further discussion of OSS with ID and the way in which this may continue to be developed further.

"Q - I've been thinking about the open source movement.

I know very little of the UX community's involvement, so firstly I'm posting to ask what has been happening so far. Mozilla, Open Office and some others must have had serious UX involvement. Secondly, if it doesn't already exist, I wonder if there's the potential for us to structure some kind of virtual agency that would allow us to engage effectively.

Few thoughts

- In my opinion, several OS projects are incredible achievements that are hampered by small usability problems or even just language issues. I really believe in the movement. I think some corners of it need our help.

- UX involvement, unlike coder involvement, might be more effective if the people weren't aligned to a single project, so maybe the movement doesn't naturally structure itself to include us.

- Be a good way to spread the UX word, and a good way for us to collaborate and learn from each other. Might be especially useful for people trainign in UX. Maybe meetings like the book club but instead the topic is an open source project that everyone's looked in advance.

Any thoughts? Knowledge of UX involvement so far?

Tom "

And some further comments from the thread

"I just ran into Paula Bach's work on UX and Open Source, in particular:

"Designers Wanted: Participation and the User Experience in Open Source Software"

http://cscl.ist.psu.edu/public /users /pbach /paper1367 -bach.pdf

A nice read ..."

"For more linkage, see http://delicious.com/andyed/opensource+usability The openusability.org site Adrian referenced is a sort of "virtual agency". The Mozilla efforts are I think the culmination of a rising trend here, capping work in Usability sprints, along with more dedicated projects in GIMP, Drupal, and Wordpress.

There's more to the Mozilla picture than described here so far — "Test Pilot" aims to get a representative 1% of the firefox user base for instrumentation aided remote usability exercises:
http://labs.mozilla.com/2009/01/test-pilot-vision/

Cheers,
Andy "

"andy at polaine dot com

Monday 1:57pm

I haven't gone and read those links yet and maybe the answer is there, but I would be interested to hear about how interaction/user- experience design can be worked into the open-source model.

I can't help feeling I'm being naive here, but the checking in and out of code, branching and patching and the control of that process seems to suit code way more than it does, say, wireframes or design concepts.

The latter are, by their nature, rougher than finished code would be, yet would need to go through a typical open-source process of being added to the 'build' in some way and good ideas, or too rough ideas might get killed off in the process.

How have people gone about this workflow and process in existing open- source projects? The Yahoo! pattern library process seems like it could be a good model: http://tinyurl.com/by4bq

Best,

Andy Poline "

"While bring UX to open source is not impossible and there are great people putting up a great fight. These are more the exceptions than the rule.

We need to realize that until the culture of OSS evolves from one where code contribution is king, to one where idea contribution (in ALL its forms, including code) is king, it will remain difficult.

I think there needs to be a bit of a revolution and one I'm hoping to have something to do with (maybe even with Aza's help) . In the spirit of Carpe Diem, I really want to "just do it" and create an OSS project, even if only experimental that starts out with attempting to answer the question, "What would a designer led open source software project look like?"

The goal isn't to negate the developer, but create a space totally different from before. The outcome is not to learn how to lead developers, but to create a space for exploring design in its relation to development in a new way and see what succeeds and what fails. The ultimate goal would be to work towards modeling a new culture where business, development and design can co-mingle/lead OSS initiatives/projects.

-- dave "

A great and useful point made here with how to lead developers to a new space for the design and development of software - this is a perspective that the IEAT process for me is having to incorporate and provide a bridge for the development process into the design/design ethnography process and vice versa.

Again more about dealing with the multiple perspectives that technolgoy design is facing.

Quote to capture work upgrade & other pieces

"[The] dynamics of computational artefacts extend beyond the interface narrowly defined, to relations of people with each other and to the place of computing in their ongoing activities. System design, it follows, must include not only the design of innovative technologies, but their artful integration with the rest of the social and material world. The value of artefacts on this view lies less in their intrinsic features, than in their contribution to particular social-material landscapes." " -- Lucy Suchman

• Some useful discussion from the IxDA site:

Some thoughts on Interaction Design and the Agile Environment from IxDA may have some useful points and diagrams for continuing work

Interaction Design in an Agile Environment -This may also be useful also for future evaluation of research use

Metaphors- A discussion with some of the books in the area and some current PhD work, may be useful in providing insight in when and when not too use metaphors and the cognitive process behind it.

Measuring User Experience - With a discussion on best practice to Measure User Experience,based on 4 key pillars: 1) Branding; 2) Usability ; 3) Content and 4) functionality. Can ignore branding, remaining 3 may prove useful for evaluation later on.

• Stumbled across a very good blog, entitled “The Restless Mind through putting people first feed useful posts from blog.

The design of everyday relationships

MIT Professor Donald Schön [observed] that design is a “conversation with materials.” In many ways users have become “materials” as much as participants. We not only engage them explicitly through interaction design to create discrete features, but also in aggregate as social systems and platforms amplify their implicit actions to create value.

The siren call of the system
Well-designed systems are not, in fact, designed. They are the product of evolution. […] Systems, like narratives, take time to reveal themselves to their authors. Changes in technology, consumer preferences, and markets take years to play out. It’s not clear from day one where the system will go or how it will adapt. […] Systems are so rarely produced because they take time and time is one resource companies don’t have. Most die long before the system is revealed.

Apple and the enigma of innovation
What makes Apple special isn’t design. Or process. Or talent. It’s fear. Fear of the man who is a riddle, wrapped in a mystery, inside an enigma. (And sheathed in titanium. An engineer slaving away on the iPhone SDK isn’t concerned about the industry, his peers, or his boss. His relentless pursuit of “system elegance” is simply an animal’s instinct to avoid pain, manifested largely during the senior management review.


And insight into a designers mind....?