New camera :D

Notes from IxDA

Alan Cooper, Keynote
Cooper

An Insurgence of Quality

Congratulations, we are interaction designers. We aren't programmers, and we aren't eyeball trackers. We are interaction designers, and we know that deep in our souls, well designed products always beat hastily slapped together products in the marketplace. Best to market trumps first to market. Archos jukebox, sold a year before the iPod came to market. Archos was a market failure - it's impossible to use. Also have the creative labs version, with an identical feature set. Then, Apple came out with the iPod, and obviously a success, creating a dynasty. An example of how best to market trumps first to market. iPod to Apple Newton. Google to Altavista. "We knew that google was going to get better every single day, so the later we tried it, the better it was for us. .. tomorrow would be better (than today)". Best to market consistently brings to us a passionate customer loyalty. Long after the first flush of initial adopters become excited about something, good design sustains: Lotus as compared to Visicalc, or Amazon.com as compared to Virtual Moes (?) and Powells. Java and C++. Nike and Converse. Best to market.
Why then is it that first to market always seems to be more important in the minds of business people? We do we always hear this idea of innovate and race to ship the product? The one thing we don't need to do is emphasize innovation. It's hard to keep innovation out of what we do; there's an abundance of it. Innovation, to me, means new invention. It's come to take on a different meaning in the industry, and translates in the minds of business people to success. The archos was innovative, dramatically innovative. But it's a failure. What creates success isn't raw innovation, but it's considered design.
Most people believe that good design is simply impossible to describe, and the only way to get there is racing to ship an innovative product and then revising it over and over once it's shipped. Business people focus on first to market, because they don't know how to do best. That's where we come in. We can show them how.
Contemporary management skills are industrial aged skills. The tools and skills for managing industrial organizations; but best to market comes about only through craftsmanship, and craftsmanship is quality. The goal is to get it right, not to get it fast. Quality, not speed. It's a pure measure, and a delightful measure. They do it over and over until they get it correct. They build things over and over, thus the training of craftsman is a long, drawn out personal process.
This is a preindustrial thing, which came to its fruition before there were factories. Craft was affordable only by the very rich - only royalty or successful people could hire a craftsman who could spend that much time to make great things. The industrial revolution introduced economies of scale, and industrial products were of lower quality, but were more affordable. This was a reasonable exchange.
The dictum of one size fits all was OK; but in an industrial economy, there's little room for craftsmanship, and craftsmanship lost its role as an honored place in the spectrum of activity.
Now, here we are in the digital age, and software is not an industrial medium. It doesn't have the economy of scale, and there's very little cost of labor and scale and semi-skilled labor.
Programming is not an industrial activity. Programming is a unique activity, that has a lot in common with pre-industrial craft, but yet it has a lot of unique characteristics of post-industrial craft. Programs are made one at a time, and each piece is different. It's not formulaic, and off-shoring doesn't work in a pre-industrial craft, and there's no magic silver bullet - we're "all going to agile and everything will come up roses".
Pre-industrial craft was characterized as a slow innovation. Post-industrial craft is similar but different. Compare a jet to post-industrial craft software; massive interaction between the parts in software, and abstract ideas presented in abstract ways. All it takes is one instruction, and the entire idea becomes crashing down. Software is intangible, as are the people who build it.
But programmers are craftsman. Peter Drucker used the phrase "Knowledge workers". Self-directed; know what needs to be done better than their managers. Respect competence, not authority. You can't tell a programmer what to do. Their satisfaction comes solely from the quality of their work.
Purchase raw materials, purchase labor to transform the materials into higher quality, and sell them offerings based on the economy of scale. That simply doesn't exist in the world of software.
Cost reduction used to occur through efficiency, but there's little notion of efficiency in craft when your goal is quality and not mass production. Hierarchical structures have shifted from delegation (in mass production) to a flatter world; building software becomes the organizational strategy.
The whole nature of post industrial products is different; "form follows function", and that doesn't hold true in software. In the industrial age, behavior is a byproduct of functionality, while in the post-industrial age, functionality is a byproduct of behavior.
Programmers can't be managed, but only facilitated. Ok, we can accept that. But what's interesting about it is that traditional industrial aged management is based on hierarchy and control, and it doesn't admit to facilitation. Paul Glenn goes on to talk about how this is emasculating to industrial aged management. He talks at length about how geeks approach their jobs as a problem and solution situation, where they are constantly breaking down the problem into chunks to be solved. Facilitation is a process to undergo, and not a problem to be solved.
Knowledge workers are struggling with the ideas of facilitation, and it's a clash between different cultures. Post industrial medium, industrial aged management.
This gives rise to zero-sum tactics. Fighting for "apparently scarce resources". But time and money aren't scarce. But we are commonly told that scarcity is regarding time and money. Apparent scarcity; this has been proven over and over again. When you push on any culture is that you get this kind of wasteful fighting and a culture that promotes the idea of a race to market with a scarcity of time.
I think of it as the south American dirt farmer who sets fire to a few hundred acres of forest to set a clearing, which then exhausts the soil, and then they burn out a few more areas. It's a culture of wastefulness present in high tech industries. They bring a product to market, and then spend the rest of their existence nursing a success or worrying about a failure.
We are loathe to say that the failure is what we did, and so we blame it on the lack of a market.
A quest for innovation: the futile seeking for the magic bullet that will make people love our product.

Why can't business people work with post-industrial craftsman?
Management science lacks post-industrial tools. The first impulse of the high tech business executive is to reduce the cost of programming, because they see them as assembly line workers. Reducing the cost of programming simply reduces the quality of the end product, and therefore, the desirability.
There are no good management tools for software construction. This is the patterning of thoughts in the brains of people who don't think at all like business people. There are no appropriate tools for accounting for the creation of software. There's no good way to track a feature to money. There's no way of understanding ROI calculations on software. There's no good tools for facilitating programmers from a management side, and so people find a vice president who can speak business but hang with programmers, and strategy becomes delegated lower.
Here we have an image of a completely isolated, out of touch management situation with a knowledge worker constituency wandering aimlessly around, trying to achieve goals that maybe aren't relevant to the aims of the business.
It's time for us to fix this problem. We need to create an insurgency to fix this problem, as it isn't coming from business or programmers. Both of these constituencies need our leadership; we need to stop asking for resources and permission, and show them how to create success. Interaction designers need to be revolutionary. Programmers don't respect authority, but they do respect competence.
We are competent. We are rigorous, and we understand business, and we think clearly, and provide actionable data, and written blueprints, and we can facilitate software creation.

We need a plan, visibility, and confidence.
The plan is what we produce from our fundamental work that we do on a regular basis. A detailed, written plan, based on documented research, based on personas; we need to be able to articulate why each decision was grounded in research. The thing about the plan is that it provides visibility. It shows an image of what "done" is. The detailed plan is what the thing looks like when it's done, and then progress can be tracked to it. A list of features and a deadline don't do that. It's like taking an arm and a leg and a brain and create life; you can't do that. A rigorous description of behavior, in scenario form, with personas achieving their goals through actions; it's narrative, and they can understand it, and buy it.
Confidence comes from experience of having done it before.
We need to help programmers with this part of their job. This part of their job, today, is hopeless abused and confounding.
Frederick Brooks, the "great sage" of building high tech systems, wrote a book about this.
Plan to throw away, becomes a mantra for programmers, and they expect that the second way will be better. I would like to recast this, with an emphasis on PLAN. Plan to throw away, and go into the exercise asking "what questions would I like answers to on a technical level"; what strategies can I use to create an engineering process that can make this occur - I can write little snippets of code. This is a well known process: you test your work on a disposable piece of material. Pre-industrial craft techniques to our post-industrial technology.
Today, this occurs: Requirements => Programmers do it all.
Now, we are moving towards an emergent phase of product creation: Requirements => Interaction Design (What?) => Programming (Do).
We throw our pearls before the swine of the deadline-driven programmers.
We want to move to a three phase construction: Requirements => Interaction Design (What?) => Design Engineering (How?) => Production Engineering (Do).
Consider the bridge builder, who is not an engineer, but an iron worker. This is similar in software development.
Design Engineering looks a lot like Agile methodology. It's about treading lightly, iterating rapidly, etc. Agile methods as interaction design are troubled and problematic, as are agile methods about production. But for determining how something should be built, agile is great.
Production looks a lot like rational.
How do we create an insurgency? The key is to start small. Pick a project within your organization that's easy to define, small in scope, and something you can describe easily. Something that doesn't directly affect strategy. Then, work with the programming team, and make a deal with them. You will fight for design engineering, and they will fight for your design. Programmers want nothing more to do software development as described; you need to say "I will go to management, and fight to get you the resources, if you build it with the behavior that I specify". This is the deal programmers are waiting for. This is our role.
Above all, you need to document your success. When you create a success, you need to describe the status quo and explain how your process brought the success.
Putting more money into design and design engineering will be a greater investment of time and money up front, but all of that will come back to you in savings during the production phase. In the long term, you end up with a successful product that can be build upon in the long term, "you don't find yourself with a commitment to an ill-conceived strategy".
The most expensive thing in business is opportunity costs, or the cost of what you didn't do while you were busy doing whatever it is that you did do. There is no constituency of customers out there waiting for you to early ship your bad product.
What I'm asking for is an insurgency - we have a critical mass of interaction design talent, and skill and guts - to step forward and create this insurgency. Instead of asking for permission, let's build the insurgency in part with the programming community. We will give you what you want, the freedom do make craftsman like software, and they will sense what you want.
We are the ones who can do this, because business executives are continually retreating into industrial-aged thinking.

Dan Brown
Concept Models

During Cooper's Q&A, Cooper said "Designers shouldn't code. We should be able to express our designs without doing any code". I'm inclined to agree with you, and with him. I'm exploring different kinds of documentation. Another thing Cooper mentioned was craftsmanship. In 1740, the biggest problem facing mariners, was that they would crash into land, because they couldn't measure longitude. The royal society in England set up - they sent out an RFP - they asked people help them measure longitude. This guy, John Harrison, set out to solve the problem. If you can measure time at sea, we will be fine. We know how much things travel, etc. The problem was that time keeping at sea wasn't accurate enough.
The poor guy tried to make a clock that was worthwhile at sea. He went through a dozen iterations, and these things took years. The one line that stuck with me for the last decade, was that it took 3 years for him to make the tools to make the clock. There were no standards, and no standard bolt size or spring size, and so he had to make all of these things.
We are at a similar point in our work as interaction designers. We are inventing the tools that we need to make this work. One of these tools is Concept Models. I've got a chapter in Communicating Design about this; I get asked about this over and over.
Consider an assignment: build an application for reporting expenses. It's the "third rail" of interaction design. We know we need it, but we don't want to do it. How do you escape from the standard form? We are designers; we want to do something better than a spreadsheet. You gather some requirements. Maybe you've followed the cooper method have generated personas. Now what?
You could build a flowchart. You could build wireframes, "sketching different ideas". You could brainstorm. Maybe the requirements are unclear, and you don't have a solid understanding of the design problem.
Underlying concepts? What does this mean?
Looking at the requirements, we look at nouns; employees; expense; managers; status; amount. These are interesting nouns and objects, and concepts, behind the idea of an expense report. What do you do with this information? You can produce a concept model. This is the least attractive deliverable there is, but it's meaningful. Connecting elements - nouns - concepts - within the expense reporting application. It could be a useful tool to bridge the gap between elements, but maybe I'm not ready to commit to a design. At the very least, you begin to agreement on a vocabulary.
They are very organic, and you can begin to evolve them into something more interesting, if not organic. Begin to add verbs, to understand the connections between elements.
A little theory: What is a concept model? Consider an owner and a dog. They are connected by a leash, and the leash represents "walks". What's important is highlighting the right relationships. Concept maps came from Joseph P Novak. Concept mapping is a means of teaching science to K-12 children. Concept maps are graphical tools for organizing and representing knowledge. Can allow for new ideas to become integrated into the existing infrastructure of old ideas.
Concept maps, therefore, can be used to analyze and understand, and to synthesize and design. They become a way to bridge the gap between understanding a problem and solving one.
Concept models as a design tool: Consider the Foundations of Interaction Design. Motion, space, time, appearance, texture, trustworthy, appropriate, layout, type, etc. Concept models help define scope.
Additionally, they begin to articulate views into the actual data that will show up on a screen, and also components that show up. Finally, think about the "lines between bubbles": the relationship between elements is articulated by a verb, or a connector.
What if concepts aren't connected by people? The idea may be to illustrate the relationship between elements.
An opportunity exists, to think about the types of relationships that can exist between concepts. Acting upon, belonging, creating, describing, constraining, attaching, annotating, yielding, determining, constrains, transporting.

Gretchen Anderson
What's a concept?
If you are trying to create a new concept, a revolution, you need to be aware of and be able to speak to your concept. If the product is going to do some change, change within the organization, you will have different kind of audience. Business people are different - they don't understand what you talk about, and they don't care about it.
Set an intention. At the beginning of the conceptual part of the project, we aren't doing design yet. We are just going to talk about what this thing should be, and that will contain a cast of thousands. I don't know what they do, and they don't know who I am, but we all need to have buy-in. Commander's Intent: I want to inspire my teammates to buy into that vision with me, so we can all design.
Boxes and Arrows aren't a universal language. Your CEO does not understand boxes and arrows. The software people might; industrial designers glaze over if I show them words. We can be really jargon-heavy. "I've never really been moved to tears by scenarios". They aren't inspirational tools for a whole team of people; they can be, put I've been challenged to think about how I use my basic tools when dealing across disciplines.
Forest, not trees. At the concept stage, people don't care about the trees. We are good at knowing, and understanding, and talking about the details, but it's about taking a step back. Going wide; thinking about the concept of the project. People; hands; rooms. You need to sell your material, and inspire people to buy into it.
Talk about people, and business. Emphasis is on forest, and not trees. Trees turn senior people off.
A narrative weaves together cool bits of interaction.
Go big. Think less conservatively. "We don't have the budget... we don't have the timeline... it's scary. You are on the edge; you've done the research, and now you have to formulate a view of what the "thing" is. You need to build momentum: Oversell, don't undersell.
Harness the power of stories. When I started at lunar, I began to look at what was behind story telling, and behind scenarios. Think about how a story can change someone's life; exaggerate. Think about the aspects that will change people. Make the viewer care about someone.
Have characters. Personas; profiles. Your product also has character. By giving your product personality, we can understand what something feels like. The character - we all love to cast our products as fresh. But our products are likely not the star of the show. The people are.

Chris Conley
Gravity Tank
Dramatic Features in Interaction Design
These are brand new ideas for me. I want this session to be exploratory, in the sense that I want you to help me think through some of these ideas. I would like it to be a little provocative, and collaborative. I don't want to get into an argument, though - I would like alternative points of view as we make it through the content.
Volkswagon advertisements. Showing "safe happens". Comic strips grab you with an emotional connection in three or four frames. I want to talk about dramatic features, and how we can start grabbing people in different places and at different times.
A bit of drama.
Does drama have relevance to little screens, big screens, software? Now we are seeing people come on board and start to capture imagination in ways that we haven't yet seen. The iphone has a few examples. Something resonates - it's not "easy to use", but it's something else.
Drama - an exciting, emotional, or unexpected series of events or set of circumstances. A composition intended to exhibit a picture of human life tending toward some striking result. The key is that people get it. You don't have to explain it to them - it makes sense - it's somehow relevant in every day life.
Bill Moggridge, cofounder of IDEO, made a video about interaction design in the mid 80s.
GS Choi. "Why is the iphone so popular? We have phones with those functions..." (CEO, Samsung).
Very crass overview of interaction design: Function - does it work? Usability - can people use it? Aesthetics - is it nice? Drama - Is it meaningful?
Additionally, I spend a lot of time looking at the creation of "creative industries" - gaming, movies, etc. They develop their products and services in a very different way than we develop ours.
The Nikes of the world, that are extremely successful and keep reinventing themselves and their products, might have an interesting way of working. They don't do email and meetings; they work on the film for six years. And each time, they build a billion dollar business. They bring an amazing product to market, and they have no function to fall back on. It's pure resonance with people.
Advocating for bringing the creative and tangible back, and not just focusing on the analytical and verbal. They should be equally distributed. The problem is that the creativity has been completely crushed out. At the end, it's about everyday people. To the degree that we abstract markets and target users, and start talking about them in quantitative terms, we forget what people care about and what they know.
Caught in an analytic, recursive circle of if something is right or wrong.
The interaction is choreographed - the art of planning movement and steps. If you are to move things around, you are planning how that would happen. Not that you can move things around - planning how, or designing how, it would work. Turning the machine into a new mode or new state. Wiggling. Moving. Getting out of the way.
The state and transitions are embodied in the behavior of the elements.
Character. Goals, or purpose. Action, reaction, and behavior. Emotion.
But how do we write requirements for things like this?

Gabe White
Ethics of Everyday Design

Bringing ethical thinking into everyday design practice. There's a lot talk about socially responsible, environmentally sustainable design. There's also a sense of "how the hell do we deal with these problems". There's a sense that we should be doing something about it, but we don't know how. I want to talk about how it may be brought into practice.
Ethics as professional behavior. How we behave towards our colleagues, clients, etc.
Ethics as object of design. Is there an inherent ethical and social value in the things we are producing?
Ethics as how design is done. How can we bring the question of ethical evaluation into the things we are designing every day.
By structuring the actions of people - be creating the field of possibilities - we are determining the right way to act. There's a burden of ethical responsibility that we have as designers. We focus on the big questions: the environment, the planet, etc. We need to get out of the high level view and get toward the actionable, but we frequently don't have the time given the project work we have to do.
The system is to look at ethical principles, and to derive a set of heuristics. Designers are all about tools - the tools that make us smarter, and help us produce better results. What is the toolset we can use to apply to this problem? It's a rule of thumb - it's useful only in how it can have an impact on the work you are doing. You can use them and discard them.
Ethics is about what's coming from your heart; a set of ethical rules makes us "rule following monkeys". That's an unreasonable criticism. We have rules of thumb about enacting a principle, "don't harm people", that we follow in our every day, in order to bring those into actions.
People should be in control of their lives. What heuristics can we derive from that principle? People need to be aware of how they are behaving: provide an understanding of behavior patterns.
Discourage addictive or compulsive behavior.
Help develop desired skills and abilities.
Provide positive reinforcement when goals are realized.
Another principle, is the idea that we should take care of our planet for future generations.
Create awareness of how activities affect the environment.
Surface features that make it easy for people to reduce their impact.
Make efficient use of digital resources.

Jenny Lam
Hit it with the pretty stick

Visual design is more important today than it ever has been.
Came to Microsoft with visual design training, hoping that visuals can make a difference in people's lives. But visual design is derisive. Experience with how one interacts with devs - how people take your suggestions, and perceive your work, visual design can be difficult. I came to Microsoft not knowing what UI is, or what UX was. Drawing pictures all day; people were drawing smart looking diagrams and pictures and scenario flows. Not that any of these tools are wrong, but it was hard for me to get behind it in a compelling way, because I couldn't picture the end state.
All meaningful design begins with a compelling vision. We have a secret weapon, because we can envision the end state by drawing pictures. We are charting the course for how to get there. Vision gives your team the clarity to act, and the ability to get through those tough cycles. It gives you the ability to believe.
We sometimes compare products to relationships. Most of the time, if you are dating, and you meet someone, there's a sexual attraction; sometimes when it's really strong, it overwhelms you and you behave outside of logic. But it takes a value to allow it to sustain. For Vista, we demonstrated that belief. The design team envisioned the end state through dozen of vision prototypes; I started out as a ui designer, but held a hybrid role in the project. I was creative director for user experience, and it was this time that I began to understand that the role of designer had the biggest impact on creative projects. They were seen not as a necessary evil, but as a peer to interaction designers to create that vision.
In hindsight, I can appreciate how profound some of the tiny changes that were just visual made a difference in people's lives. It's interesting to talk to people who have a hard time going back to the old version.
Microsoft was great, and taught me a lot about how to build software, and for that, I'm greatfull, but now I'm making hand crafted software that is customized. The products we seek - our goal - is to create experiences that have a legacy and create an emotional impact on people. My partner's grandfather's store was a fishmarket, and in the store, they sold a variety of fish, groceries, etc that were high quality.
Was run by a family with everyone pitching in. Quality, quantity and variety.
I think about what is going on the world to make us come to this point. When products hit their stride, design becomes the main differentiator. Users expect the products to be designed and not just function.
It's time to start differentiating.
The iconic example of utility vs. utility plus personal expression is the initial Ford model T. You could only get it in black, but a few years later, GM put out a car that used the same parts, was a few hundred dollars more, and they offered it in different colors.
A lot of products speak to that premise; mini cooper; dyson; starbucks.
Software is both art and craft. This debate has been going on for a long time; what is art, the definition of craft. Does art become craft when it has a function?
Craftsman think with their hands; they work with that process to create something. Most of the time, these people work in a tradition, learning from past histrocial forms, and they become so in love with the craft and the materials and the process, so they lift that medium to a new level of understanding. But there's another side of that spectrum, where people think that emotion and idea are supreme. Individuals of vision and depth - people who can see stuff in the world; they are called artists. These quotes and examples made us think about software is the perfect medium to be both artistic and to allow for ideas that are supreme and execute with craft. Think about the context of art and craft, and software - this is the crux of the talk - is the medium for creativity. It's new, and it's still forming, and we don't have that historic form to borrow from. We've just scratched the surface of what software is capable of. Software can tell a story.
Software can be artisanal. When we look at artisanal products that have reached mass production, there's a ... someone making wine, in their basement, a level of self expression. The cheese artisans, take their job very seriously; tobacco has even an artisan side. Furniture. An interesting genre, as it makes one think about how, to a certain extent, this craft came out of a necessity. People had to put wood together to form something that works; think about software, as we don't have that heritage to borrow from. The eniac; was put together by humans, but it doesn't have the same craft that someone put into making the chair. It's interesting to look at software as an artform, but there's not a lot of history to borrow from, and so we can define what that means. We don't have to mix the colors in photoshop to paint each pixel; there are tools there to express these things, and a lot of opportunity there.

They're Beautiful.

Designing Information
Anh Dang
Narali Patel

Information Visualization. A representation of data, that can be interactive. "I don't get it; what am I supposed to look at"; "it's too artsy". Clients are responding to poorly designed and presented representations.
Virtually unlimited manners to represent data, but how best to represent it? Expose patterns and relationships in data that may otherwise not be seen. We tend to gravitate towards patterns as humans, and the goal for a designer is to tap into the common knowledge that is already known. Too frequently, designers jump into a visual mode without thinking about the information fully. We need to explore all of the possibilities, and consider how we can differentiate the experience.
A first approach; allow ourselves to identify information that is important, and highlight information that is relevant. Data visualization is a way of creating easier access to information. Our job is to highlight the information that we are looking for.
A second approach tries to understand the data a little more. Data is broken into objects and relationships. A data type can be quantitative, nominal (can be used to label unique objects), ordinal (can be ordered). Data types can be transformed. We might thing of city as nominal, but when alphabetized, it becomes ordinal.
Visual features can be considered, then, as a method of calling out the data types.
Mackinlay's visual features; position can be thought of as quantitative, ordinal, or nominal. Then, length, angle, slope, area, volume can be quantitative. Density, saturation, hue, texture can be ordinal. Hue, texture, connection, containment can be nominal.
Tables, essentially, are using position as a visual feature (primarily). Color and hue can be used to guide people to look at the data in particular ways. Hue can be used for totals, min, max, and grouping. This transforms quantitative information into qualitative (nominal), through the use of saturation.
A third approach to looking at data; create an overview first, zoom and filter, and understand details on demand. Information Seeking Mantra. Various interfaces can then be used, and the data can be applied on them, in order to understand and build meaning.
Gapminder.
Understand the data, and data types, and visual features; this helps not only create better visualizations, but it also affords better analysis and effectiveness capabilities of looking at other people's data.
We are looking for the "aha moment" where people can be delighted without being negatively affected by lack of comprehension. We can see patterns evolved, and we can better communicate a message through data visualization. A solid framework for visual designers to "take it to the next level".
We can create better experiences for users, so things aren't overwhelming, but people can play with data and pick choose.

I'm back in Savannah for the IxDA conference, and this is the type of strange serendipity that occurs here:

Sitting at dinner at Vinnies with a bunch of conference attendees, including frog's Gabe White (speaking on Sunday) and Marie Hwang from Trilogy, I ran into my old friend Bob Fee. And who should *he* run into? None other than Billy Milano, lead singer for the 80's hardcore band MOD:

Sun is shining, and I can't wait to wander around and get lost at some of my old haunts.