Some relevant quotes

Some relevant quotes to help with the positioning of the PCA.

If interaction design is considered only at the end, software is driven by engineering design, of which users are rightly unaware, rather than by representations with which they interact. -- Gillian Crampton Smith and Philip Tabor, in Bringing Design to Software, edited by Terry Winograd, 1996

We encounter the deep questions of design when we recognize that in designing tools we are designing ways of being. -- Winograd and Flores, 1986, p. xi.

[...] mastery resides not in the master but in the organization of the community of practice of which the master is part. -- Lave and Wenger, 1991, p. 94

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.

More maps

Another really intersting map visulisation from Pasta & Vinegar

About digital and paper maps

Mapping is a favorite topic of mine, not only because I worked on locative media, but also because I find they are fascinating objects. Maps are really interesting these days as they exemplify one of the design trend I spotted recently: the transformation of non-digital objects by design techniques coming from the digital world. To some extent, lots of artifacts from the material world can be re-designed by applying insights learned when creating weird interfaces and new sorts of interactions.

This is what happens currently with paper-maps which design is reshuffled by people who grew up with video-games and on-line mapping tools, or by designers who consciously want to apply techniques coming from the digital. What is highly captivating in this context is that it also reshapes the user experience of the object at hands. Maps are a good example of such phenomena.

One of the most advanced project along these lines is certainly Jack Shulze’s Here and There. Although I don’t have the poster version, the Wired UK version will do to exemplify what it is:

Here is the idea:

“Imagine a person standing at a street corner. The projection begins with a three-dimensional representation of the immediate environment. Close buildings are represented normally, and the viewer himself is shown in the third person, exactly where she stands. As the model bends from sideways to top-down in a smooth join, more distant parts of the city are revealed in plan view. The projection connects the viewer’s local environment to remote destinations normally out of sight.“

There is more on S&W’s on-line web log where Schulze describes how he wanted to “exploits and expands upon the higher levels of visual literacy born of television, games, comics and print“. More specifically, he wanted to tap into the satellite representation as a symbol of omniscience and the reason why a platform such as Google Earth is so compelling. The point was to have “a speculative projections of dense cities (…) intended to be seen at those same places, putting the viewer simultaneously above the city and in it where she stands, both looking down and looking forward“.

Reading this in the train yesterday made sense when few minutes after, arrived at my final destination in the city of Lyon (France), I encountered this curious map:

The map depicts the city of Lyon from the train station at the bottom (in this white area) and the city itself in the upper part of the picture. There is a lot to discuss here and I won’t comment about what is not represented (can the white part be absent because it may have been perceived as not interesting for tourists?). What I find relevant there is:

• The sort of bird eye’s view, as if we were in a video game, where the landscape is represented in plan over distance
• The color overlay that shows the subway, tram and bus lines is also curious. It basically maps the public transport infrastructure on the perspective
• The map is fixed and located in the train station, it’s only drawn for this specific viewpoint (the station) and definitely match the context of use.

Can the method provide such measurable insight?

Taken from http://www.ryanjacoby.com/

What if your users wrote your business plan?

"Waiting in the lobby of my hotel yesterday in Cambridge, this headline caught my eye.

What if your users / fans / customers actually wrote your business plan or ran your long-term strategic planning process?

How would they change your estimates?

What would that mean from the businesses you'd be in and how you'd invest your money?

Oh yeah, Go Caps!"

Map incompleteness

Map incompleteness is something that I am very intrigued about. As shown in the example above taken in Paris, the city itself is well represented but as soon as you leave the “périphérique” (the highway-like infrastructure that surrounds the french capital), it’s a blank grey void as if no one leaves beyond this limit. It’s a phenomenon you also encounter with weather maps as you can see below: weather forecast generally stops at the border (clouds don’t go through the customs, do they?). You can see the swiss map as if it was a stand-alone territory (lots of countries do it anyway).

Why do I blog this?

Some very useful issues to be thinking about and when and where to use for my own work, if appropriate? Taken from Pasta & Vinegar

"Map incompleteness is understandable in terms of information design: the use of “white space” can be relevant to “balance composition and induction properly”. Designing maps and signage is a matter of simplification so that people could easily grasp the situation at hand. However, in both situations above I am often bothered by the simplification; not that I need to go across the border and would be happy to know the temperature, rather because it discretized phenomena that should be represented as continuous."

Chipchase photo Fare Maps

Fare Maps

Thoughts on Data, design…and soul

Some key thoughts from the blog post ghostinthepixel.com,
it is useful to think of where a model would position itself in relation to this discussion -
Does the model have to be data driven? I would hope not... As pointed out “It is more from engaging with users, watching what they do, understanding their pain points, that you get big leaps in design.” This again is pointing to how a model may lead to such discussions - with the value of data and value of data taken from the context ?
The full discussion is below:

Data, design…and soul

Following up on the initial posting on Google’s “data-driven” ethos by web designer extraordinaire Doug Bowman, and the subsequent heated debate on data vs. design (on ixda, etc.), another web design guru, Luke Wroblewski has published a beautifully compact articulation pointing out the falsity of the debate (which the NYTimes even used in their article title over the weekend–hmm!). Indeed it’s not a conflict, but a parallel dialogue of approaches and viewpoints, working together.

As Luke says:

1. Data informs design
2. A handle on design builds credibility
3. Data is not the only way to make decisions

Nice!

On the same topic, Luke Stevens published this lengthy read teasing apart the issues of “data vs. design”, largely defending data-driven design with thoughtful explanation, but avoiding the typical holy war of righteous indignation.

Ok, that’s fine. However, my issue isn’t really that data drives design or not, but the following:

1. What is meant by data? Seriously. This may sound like a naive question but certainly in light of ethnography, affective studies, personal storytelling, etc (and more from Jane Fulton Suri, Liz Sanders, Brenda Laurel, among others). I’d say the parameters of what constitutes “data” are broadening. I fear there is such rigid attachment by researchers, marketers, engineers to just numerical studies that there is a blind spot to other kinds of data…

In addition to the conventions of web analytics and statistically quantifiable numeric studies/surveys/measurements, there must be room for the data of past professional experience, evolved and applied patterns/principles/guidelines, and yes personal intuition via judgement and thoughtful insight (developed over time with exposure to projects, clients, etc.)

I suspect that a rigid adherence to only numerical data is actually just a snub of contemptuous disrespect for trusting a learned and experienced designer’s judgement, which is multidimensional and dynamic…and evolving.

2. What about the soul of a design? How does extensive numerical data studies enable the aesthetic character, the humanizing quality, the elusive wonderment that makes a design resonate with one’s dreams and desires? “To light a fire in the mind and breathe life into the heart”, as former Sony head of design once described some compelling design concepts, is not something numbers can do. It takes a genuinely inspired and talented human being to elicit forth such qualities in pixels and matter, through a complex messy amalgam of culture, expression, arts, language, style, and so forth. There is an ineffable quality that transcends mere numbers, suggesting a poetic graceful elegance…a kind of equipoise if you will. Hundreds of numerical studies will not provide this no matter how rigorous or detailed. Some of it may be of value, but as Doug Bowman says, “But we take all that with a grain of salt.” And remember… as Jared Spool said once, “any piece of data can be whipped to confess to anything.” It takes the judgement, inspiration, experience, and temperament of the designer(s) to resolve a cohesive blend of the rational and the imaginative into something that people will emotionally connect with and effectively use.

Marissa Mayer may unapologetically say “We let the math and the data govern how things look and feel,” but doing so only confesses the lack of humanity and soul in Google’s products, only a raw Terminator-esque ruthless efficiency embraced by triumphant engineering-centric glee. (Google Analytics–ironically–may be an exception, as is Google Chrome. IMHO per the recent bayCHI talk)

And finally, since when did a numerical quant study alone lead to some of the grand paradigm-shifting, breakthrough products of our time: the iPod, the Dyson, Tivo, Prius, twitter, youTube, blogs and of course the iPhone. Those dramatic jumps of insight more often involve multiple kinds of “data” mentioned above, and the recently recognized skills of abductive thinking (as Frog’s Jon Kolko described at Interaction’09)…with some curiosity and inventiveness and a good measure of perspiration, to hint at Thomas Edison’s old saying. Indeed, from the NYTimes article: “It is more from engaging with users, watching what they do, understanding their pain points, that you get big leaps in design.”

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

Service design as the design of activity systems

A useful article on the application on the design of activity systems from the blog putting people first

Jeff Howard draws attention to a recent service design paper by Daniela Sangiorgi of Lancaster University:

“Dr. Daniela Sangiorgi’s 2008 presentation from ISDN3 just came across my radar. It’s on Service Design as the Design of Activity Systems (pdf 2.1MB). [Audio]

Here’s Sangiorgi on a key distinction:

I like to consider the origin of Service Design field with the introduction of the Interaction paradigm. Meaning moving the conception of services as complex organisations to the one of services as complex interfaces. In my opinion the perspective that looks at services from the interaction point of view, is different from the one that was trying to define services as ‘products’ and therefore as objects of a design process.

It sounds like she’s framing service design as a third order rather than a second order problem. By “interaction” she’s referring to services as complex interfaces between providers and users. A system of subjects, artifacts, roles and norms.

Here’s a recap of her talk by STBY.

I stumbled across an earlier paper (pdf) of hers on the topic of service design and activity theory a while back. Translating it from Italian proved incomprehensible so I put it aside.

This newer presentation clears up a lot.”

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

UCD considered harmful...

Why blog this?
A very important thought for UCD by Don Norman and where and where not the focus and actual context should be for UCD.
Whether or not it needs to be called 'ACD' is open to debate but the importance is that the context should be recognized, Norman puts forward how this is not so when the term UCD is used. This helps form an argument of what my own design framework is to propose.
- Question the history of 'context' in design methods?


In addition I can foresee how the scenario and persona discussion and existing UI tools may plugin to such a framework method as they 'should be' able to draw upon the context around them. This is now the thoughts and basis in how my own framework and how I should acknowledge the wider fundermentals of context. Own questions again on how and if and what to measure for this within suitable reason...?

- note follow up article HCD harmful? A Clarification just as useful Don Norman further explains why he made such a statement.

Follow up :Plenty of scope to follow up on who else has spoke out of the dangers of the UCD approach?

Article below

Human-Centered Design Considered Harmful
Column written for Interactions. © CACM, 2005. This is the author’s version of the work, the same as the published version except that I have corrected several typographical errors. It is posted here by permission of ACM for your personal use. It may be redistributed for non-commercial use only, provided this paragraph is included. The definitive version was published in Interactions, 12. 4, (July + August, 2005). Pp. 14-19.

NOTE: Please also see the clarification to this article: HCD harmful? A Clarification.


Human-Centered Design has become such a dominant theme in design that it is now accepted by interface and application designers automatically, without thought, let alone criticism. That’s a dangerous state — when things are treated as accepted wisdom. The purpose of this essay is to provoke thought, discussion, and reconsideration of some of the fundamental principles of Human-Centered Design. These principles, I suggest, can be helpful, misleading, or wrong. At times, they might even be harmful. Activity-Centered Design is superior.
KNOW YOUR USER

If there is any principle that is sacred to those in the field of user-interface design and human-computer interaction, it is “know your user.” After all, how can one design something for people without a deep, detailed knowledge of those people? The plethora of bad designs in the world would seem to be excellent demonstrations of the perils of ignoring the people for whom the design is intended. Human-Centered Design was developed to overcome the poor design of software products. By emphasizing the needs and abilities of those who were to use the software, usability and understandability of products has indeed been improved. But despite these improvements, software complexity is still with us. Even companies that pride themselves on following human-centered principles still have complex, confusing products.

If it is so critical to understand the particular users of a product, then what happens when a product is designed to be used by almost anyone in the world? There are many designs that do work well for everyone. This is paradoxical, and it is this very paradox that led me to re-examine common dogma.

Most items in the world have been designed without the benefit of user studies and the methods of Human-Centered Design. Yet they do quite well. Moreover, these include some of the most successful objects of our modern, technological worlds. Consider two representative examples:
The Automobile

People all over the world learn to drive quite successfully with roughly the same configuration of controls. There were no systematic studies of users. Rather, early automobiles tried a variety of configurations, initially copying the seating and steering arrangements of horse-drawn carriages, going through tillers and rods, and then various hand and foot controls until the current scheme evolved.
Everyday Objects

Just look around: kitchen utensils, garden tools, woodworking tools, typewriters, cameras, and sporting equipment vary somewhat from culture to culture, but on the whole, they are more similar than not. People all over the world manage to learn them — and manage quite well.
ACTIVITY-CENTERED DESIGN


Why do these devices work so well? The basic reason is that they were all developed with a deep understanding of the activities that were to be performed: call this Activity-Centered Design. Many were not even designed in the common sense of the term, rather, they evolved with time. Each new generation of builders slowly improved the product upon the previous generation, based on feedback from their own experiences as well as from their customers. Slow, evolutionary folk design. But even for those devices created by formal design teams, populated with people whose job title was “designer,” these designers used their own understanding of the activities to be performed to determine how the device would be operated. The users were supposed to understand the task and to understand the designers’ intentions.
Activities Are Not the Same as Tasks

Do note the emphasis on the word “activity” as opposed to “task.” There is a subtle difference. I use the terms in a hierarchical fashion. At the highest levels are activities, which are comprised of tasks, which themselves are comprised of actions, and actions are made up of operations. The hierarchical structure comes from my own brand of “Activity Theory,” heavily motivated by early Russian and Scandinavian research. To me, an activity is a coordinated, integrated set of tasks. For example, mobile phones that combine appointment books, diaries and calendars, note-taking facilities, text messaging, and cameras -- can do a good job of supporting communication activities. This one single device integrates several tasks: looking up numbers, dialing, talking, note taking, checking one’s diary or calendar, and exchanging photographs, text messages, and emails. One activity, many tasks.
What Adapts? Technology or People?

The historical record contains numerous examples of successful devices that required people to adapt to and learn the devices. People were expected to acquire a good understanding of the activities to be performed and of the operation of the technology. None of this “tools adapt to the people” nonsense — people adapt to the tools.

Think about that last point. A fundamental corollary to the principle of Human-Centered Design has always been that technology should adapt to people, not people to the technology. Is this really true? Consider the history of the following successful technologies.
The clock (and watch)
An arbitrary division of the year and day into months, weeks, days, hours, minutes, and seconds, all according to physical principles that differ from psychological or biological ones, now rules our lives. We eat when our watches tell us it is meal time, not when we are hungry. We awake according to the harsh call of the alarm, not when we are rested. University classes are taught in one hour periods, three times a week, in 10 – 15 week sessions, not because this is good for education, but because it makes for easier scheduling. The extreme reliance on time is an accidental outgrowth of the rise of the factory and the resulting technological society.
Writing systems
Consider printing, handwriting, and typing. All are artificial and unnatural. It takes people weeks, months, or even years to learn and become skilled. One successful stylus-based text input device for the Roman alphabet is Palm’s Grafiti -- yet another unnatural way of writing.
Musical Instruments
Musical instruments are complex and difficult to manipulate and can cause severe medical problems. Musical notation is modal, so the same representation on a treble clef has a different interpretation on the bass clef. The usability profession has long known of the problems with modes, yet multiple staves have been with us for approximately 1000 years. It takes considerable instruction and practice to become skilled at reading and playing. The medical problems faced by musicians are so severe that there are books, physicians, web pages and discussion groups devoted to them. For example, repetitive stress injuries among violinists and pianists are common. Neither the instruments nor the notation would pass any Human-Centered Design review.
Human-Centered versus Activity-Centered: What’s the Difference?

What is going on? Why are such non-Human-Centered Designs so successful? I believe there are two reasons, one the activity-centered nature, and two the communication of intention from the builders and designers. Successful devices are those that fit gracefully into the requirements of the underlying activity, supporting them in a manner understandable by people. Understand the activity, and the device is understandable. Builders and designers often have good reasons for the way they constructed the system. If these reasons can be explained, then the task of learning the system is both eased and made plausible. Yes, it takes years to learn to play the violin, but people accept this because the instrument itself communicates rather nicely the relationship between strings and the resulting sounds. Both the activity and the design are understandable, even if the body must be contorted to hold, finger, and bow the instrument.

Activity-Centered Design (ACD) is actually very much like Human-Centered Design (HCD). Many of the best attributes of HCD carry over. But there are several differences, first and foremost being that of attitude. Attitude? Yes, the mindset of the designer.

The activities, after all, are human activities, so they reflect the possible range of actions, of conditions under which people are able to function, and the constraints of real people. A deep understanding of people is still a part of ACD. But ACD is more: it also requires a deep understanding of the technology, of the tools, and of the reasons for the activities.
Tools Define the Activity: People Really Do Adapt to Technology

HCD asserts as a basic tenet that technology adapts to the person. In ACD, we admit that much of human behavior can be thought of as an adaptation to the powers and limitations of technology. Everything, from the hours we sleep to the way we dress, eat, interact with one another, travel, learn, communicate, play, and relax. Not just the way we do these things, but with whom, when, and the way we are supposed to act, variously called mores, customs, and conventions.

People do adapt to technology. It changes social and family structure. It changes our lives. Activity-Centered Design not only understands this, but might very well exploit it.

Learn the activity, and the tools are understood. That’s the mantra of the Human-Centered Design community. But this is actually a misleading statement, because for many activities, the tools define the activity. Maybe the reality is just the converse: Learn the tools, and the activity is understood.

Consider art, where much time is spent learning the vagaries of the media. If you want to do oil painting, then you need to understand oil, and brushes, and painting surfaces — even how and when to clean your brush. Is this the tool wagging the dog? Yes, and that is how it always is, how it always shall be. The truly excellent artists have a deep and thorough understanding of their tools and technologies. It isn’t enough to have an artistic sense. So too with sports, with cooking, with music, and with all other major activities that use tools.

To the Human-Centered Design community, the tool should be invisible, it should not get in the way. With Activity-Centered Design, the tool is the way.
WHY MIGHT HCD BE HARMFUL?

Why might a Human-Centered Design approach ever be harmful? After all, it has evolved as a direct result of the many problems people have with existing designs, problems that lead to frustration, grief, lost time and effort, and in safety-critical applications, errors, accidents, and death. Moreover, HCD has demonstrated clear benefits: improved usability, less errors during usage, and faster learning times. What, then, are the concerns?

One concern is that the focus upon individual people (or groups) might improve things for them at the cost of making it worse for others. The more something is tailored for the particular likes, dislikes, skills, and needs of a particular target population, the less likely it will be appropriate for others.

The individual is a moving target. Design for the individual of today, and the design will be wrong tomorrow. Indeed, the more successful the product, the more that it will no longer be appropriate. This is because as individuals gain proficiency in usage, they need different interfaces than were required when they were beginners. In addition, the successful product often leads to unanticipated new uses which are very apt not to be well supported by the original design.

But there are more serious concerns: first, the focus upon humans detracts from support for the activities themselves; second, too much attention to the needs of the users can lead to a lack of cohesion and added complexity in the design. Consider the dynamic nature of applications, where any task requires a sequence of operations, and activities can be comprised of multiple, overlapping tasks. Here is where the difference in focus becomes evident, and where the weakness of the focus on the users shows up.
Static Screens Versus Dynamic Sequences
We find that work in the kitchen does not consist of independent, separate acts, but of a series of inter-related processes. (Christine Frederick, The Labor-Saving Kitchen. 1919.)

The methods of HCD seem centered around static understanding of each set of controls, each screen on an electronic display. But as a result, the sequential operations of activities are often ill-supported. The importance of support for sequences has long been known ever since the time-and-motion studies of the early 1900s, as the quotation from Frederick, above, illustrates. Simply delete the phrase “in the kitchen” and her words are still a powerful prescription for design. She was writing in 1919: what has happened in the past 100 years to make us forget this? Note that the importance of support for sequences is still deeply understood within industrial engineering and human factors and ergonomics communities. Somehow, it seems less prevalent within the human-computer interaction community.

Many of the systems that have passed through HCD design phases and usability reviews are superb at the level of the static, individual display, but fail to support the sequential requirements of the underlying tasks and activities. The HCD methods tend to miss this aspect of behavior: Activity-centered methods focus upon it.
Too Much Listening To Users

One basic philosophy of HCD is to listen to users, to take their complaints and critiques seriously. Yes, listening to customers is always wise, but acceding to their requests can lead to overly complex designs. Several major software companies, proud of their human-centered philosophy, suffer from this problem. Their software gets more complex and less understandable with each revision. Activity-Centered philosophy tends to guard against this error because the focus is upon the Activity, not the Human. As a result, there is a cohesive, well-articulated design model. If a user suggestion fails to fit within this design model, it should be discarded. Alas, all too many companies, proud of listening to their users, would put it in.

Here, what is needed is a strong, authoritative designer who can examine the suggestions and evaluate them in terms of the requirements of the activity. When necessary, it is essential to be able to ignore the requests. This is the goal to cohesion and understandability. Paradoxically, the best way to satisfy users is sometimes to ignore them.

Note that this philosophy applies in the service domain as well. Thus, Southwest Airlines has been successful despite the fact that it ignores the two most popular complaints of its passengers: provide reserved seating and inter-airline baggage transfer. Southwest decided that its major strategic advantage was inexpensive, reliable transportation, and this required a speedy turn-around time at each destination. Passengers complain, but they still prefer the airline.

Sometimes what is needed is a design dictator who says, “Ignore what users say: I know what’s best for them.” The case of Apple Computer is illustrative. Apple’s products have long been admired for ease of use. Nonetheless, Apple replaced its well known, well-respected human interface design team with a single, authoritative (dictatorial) leader. Did usability suffer? On the contrary: its new products are considered prototypes of great design.

The “listen to your users” produces incoherent designs. The “ignore your users” can produce horror stories, unless the person in charge has a clear vision for the product, what I have called the “Conceptual Model.” The person in charge must follow that vision and not be afraid to ignore findings. Yes, listen to customers, but don’t always do what they say.

Now consider the method employed by the Human-Centered Design community. The emphasis is often upon the person, not the activity. Look at those detailed scenarios and personas: honestly, now, did they really inform your design? Did knowing that the persona is that of a 37 year old, single mother, studying for the MBA at night, really help lay out the control panel or determine the screen layout and, more importantly, to design the appropriate action sequence? Did user modeling, formal or informal, help determine just what technology should be employed?

Show me an instance of a major technology that was developed according to principles of Human-Centered Design, or rapid prototype and test, or user modeling, or the technology adapting to the user. Note the word “major.” I have no doubt that many projects were improved, perhaps even dramatically, by the use of these techniques. But name one fundamental, major enhancement to our technologies that came about this way.

Human-Centered Design does guarantee good products. It can lead to clear improvements of bad ones. Moreover, good Human-Centered Design will avoid failures. It will ensure that products do work, that people can use them. But is good design the goal? Many of us wish for great design. Great design, I contend, comes from breaking the rules, by ignoring the generally accepted practices, by pushing forward with a clear concept of the end result, no matter what. This ego-centric, vision-directed design results in both great successes and great failures. If you want great rather than good, this is what you must do.

There is a lot more to say on this topic. My precepts here are themselves dangerous. We dare not let the entire world of designers follow their instincts and ignore conventional wisdom: most lack the deep understanding of the activity coupled with a clear conceptual model. Moreover, there certainly are sufficient examples of poor design out in the world to argue against my position. But note, many of those bad designs are profitable products. Hmm. What does that suggest? Would they be even more profitable had Human-Centered Design principles been followed? Perhaps. But perhaps they might not have existed at all. Think about that.

Yes, we all know of disastrous attempts to introduce computer systems into organization where the failure was a direct result of a lack of understanding of the people and system. Or was it a result of not understanding the activities? Maybe what is needed is more Activity-Centered Design, maybe failures come from a shallow understanding of the needs of the activities that are to be supported. Note too that in safety-critical applications, a deep knowledge of the activity is fundamental. Safety is usually a complex system issue, and without deep understanding of all that is involved, the design is apt to be faulty.

Still, I think it time to rethink some of our fundamental suppositions. The focus upon the human may be misguided. A focus on the activities rather than the people might bring benefits. Moreover, substituting Activity-Centered for Human-Centered Design does not mean discarding all that we have learned. Activities involve people, and so any system that supports the activities must of necessity support the people who perform them. We can build upon our prior knowledge and experience, both from within the field of HCD, but also from industrial Engineering and Ergonomics.

All fields have fundamental presuppositions. Sometimes it is worthwhile to re-examine them, to consider the pros and cons and see whether they might be modified or even replaced. Is this the case for those of us interested in Human-Centered Design? We will never know unless we do the exercise.
Don Norman wears many hats, including co-founder of the Nielsen Norman group, Professor at Northwestern University, and author, his latest book being “Emotional Design.” He lives at www.jnd.org.

NOTE: Please also see the clarification to this article: HCD harmful? A Clarification.

Some useful process related notes

Konigi - process Notebook

Schedule and Cost Summary Calculator Template

How Software is Built: Interview with Liz Danzico

The Language We Use

20 Steps to Better Wireframing

Is Good Design Replicable?

Designing by Writing

User Centered Design Work Process Toolkit

Doing Sketch Iterations

Software Tool Design: Design by Sketching

How do you design? Ebook

What Goes into a Well-Done Critique

Cockburn's Basic Use Case Template

The what, when and why of wireframes

Bill Buxton Lecture on Sketching and Experience Design at Stanford

Problem Analysis is Not the Key to Successful Design Process

Small Design Teams Are Better

Questions for IA/IM vendors

nForm UX Trading Cards

Denning and Yaholkovsky on Real Collaboration

The Fine Art of Wireframes

Design Eye for South By

Apple's Design process

10 Ways To Get Design Approval

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 ?

The role of software design

A useful quote to draw on for how the act of a designer for software should
be perceived - is this where the role of the interaction designer defines itself to exist within?

"Software design is the act of determining the user's experience with a piece of software. It has nothing to do with how the code works inside, or how big or small the code is. The designer's task is to specify completely and unambiguously the user's whole experience"

. -- DavidLiddle, From Bringing Design to Software, edited by Terry Winograd, 1996

A Communications Primer: a Film by Eames (1953)

A inspiring talk on conveying information narrated by Charles Eames himself


The Eames’ “A Communications Primer” from FI$H 2000 on Vimeo

What is Information?

A very neat and original animated infographic film about the concept of information. It was created by Maya Design, a design consultancy and technology research lab. Although most of us think we know what we mean when we say "information," the movie claims we sometimes confuse the medium with the message.

What is Information?

What is Systems Design?

An useful definition to be aware of for my own process and the overlap that software developers have found themselves in. The lack of clarity that has gone before and continues to go on in the understanding of the system design I feel is connected to the thoughts of Alan Cooper and the goal directed design process. (More thoughts on Goal directed design documented in the next post)

The following text is the pre-edited version of an interview of Hugh Dubberly by Dan Saffer. The interview was performed via email in February of 2006, and was later published in Designing for Interaction: Creating Smart Applications and Clever Devices.

What is system design?

Systems design is simply the design of systems. It implies a systematic and rigorous approach to design—an approach demanded by the scale and complexity of many systems problems.

Where did it come from?

Systems design first appeared shortly before World War II as engineers grappled with complex communications and control problems. They formalized their work in the new disciplines of information theory, operations research, and cybernetics. In the 1960s, members of the design methods movement (especially Horst Rittel and others at Ulm and Berkeley) transferred this knowledge to the design world.

(This can be used in the background in the literature review)

Systems design continues to flourish at schools interested in design planning and within the world of computer science. Among its most important legacies is a research field known as design rationale, which concerns systems for making and documenting design decisions.

What can designers learn from system design?

Today, ideas from design methods and systems design may be more relevant to designers than ever before—as more and more designers collaborate on designing software and complex information spaces. Frameworks suggested by systems design are especially useful in modeling interaction and conversation. They are also useful in modeling the design process itself.

This is significant to the IEAT process in order to ask and further test my own ideas against how system design communicates the information in the design process?

What is the most important thing to be aware of in system design

A system design approach asks

For this situation, what is the system?

• What is the environment?
• What goal does the system have in relation to its environment?
• What is the feedback loop by which the system corrects its actions?
• How does the system measure whether it has achieved its goal?
• Who defines the system, environment, goal, etc.—and monitors it?
• What resources does the system have for maintaining the relationship it desires?
• Are its resources sufficient to meet its purpose?

A initial comparison draw from this and applied to the IEAT process?

A systems approach to design asks: - to help provide questions/perspective for a developer ?

• For this situation, what is the information ecology?
• What is the ecology?
• this asks what goal does the system have in relation to its information ecology?
• What is the feedback loop by which the system corrects its actions?
• How does the system measure whether it has achieved its goal?
• Who defines the system, environment, goal, etc.—and monitors it?
• What resources does the system have for maintaining the relationship it desires?
• Are its resources sufficient to meet its purpose?

Is system design incompatible with the user centered design approach?

A systems approach to design is entirely compatible with a user-centered approach. Indeed, the core of both approaches is understanding user goals. A systems approach looks at users in relation to a context and in terms of their interaction with devices, with each other, and with themselves.

What is the relationship between system design and Cybernetics?

Cybernetics (the science of feedback) provides an approach to systems and a set of frameworks and tools. Among the most important ideas for designers:

• Definition of a system depends on point of view (subjectivity)
• We are responsible for our actions (ethical stance)
• All interaction is a form of conversation
• All conversation involves goals, understandings, and agreements

Are there times when a system design approach is inappropriate?

A systems approach to design is most appropriate for projects involving large systems or systems of systems. Such projects typically involve many people, from many disciplines, working together over an extended period of time. They need tools to cope with their project’s complexity: to define goals, facilitate communications, and manage processes. Solo designers working on small projects may find the same tools a bit cumbersome for their needs.

- A difference noted here is that system design deals with 'projects involving large
systems or systems of systems.' With the information ecology the purpose is to reduce down the complexities and have the focus upon the information movement within the ecology.

Will the IEAT process required similar identification to say when and when not it is
appropriate for the perspective of selling the idea to a software developer, interaction designer?

IA Summit Keynote: Journey to the Center of Design

A interesting presentation from Jared Spool that is talking of some interesting aspects for the evolving concept of UCD.
(seen on the usability engineering website )

Here’s the description of the talk:
"Journey to the Center of Design User-centered design was born in the 1980s, amidst a world filled with frustration with blinking VCR clocks and computer command lines. Up until this time, developers focused on making the devices work, giving little heed to how they’d be used. Terms like “user friendly” and “easy to use,” buzzwords for the UCD movement, soon became as common as “new and improved” on laundry soap. Fast forward 25 years and it now seems the foundations of user-centered design are now disintegrating. Notable community members are suggesting UCD practice is burdensome and returns little value. There’s a growing sentiment that spending limited resources on user research takes away from essential design activities. Previously fundamental techniques, such as usability testing and persona development, are now regularly under attack. And let’s not forget that today’s shining stars, such as Google, Facebook, Twitter, and the iPod, came to their success without UCD practices. Is it time for user-centered design to evolve into something else? Or is there something else happening in our world of experience design that makes UCD obsolete? Should something else occupy the center of design? These are just the questions that this year’s keynote presenter, Jared Spool, likes to answer. Especially after a few drinks. And while a Saturday morning keynote may seem early for the kind of heavy drinking these particular questions demand, Jared will have just arrived from Italy, a nation with a long tradition of philosophical intoxication. This will set the perfect stage for an entertaining and insightful presentation to open our conference."

Journey To The Center Of Design

View more presentations from Jared Spool. (tags: paradigms design)