Archive for the 'user experience' Category

Reflections on Emergence 07

[updated with photo]

Emergence was all about service, what is service design?

Another question was also raised: “how is service design different from the other disciplines like user experience design and interaction design?” No one at the conference had a really definitive or confident answer to this question . But some themes emerged in Emergence for me :

A service mindset means designers need to give up control and empower our customer. Facilitate their engagements beyond products and interactions.

Designing for services is a mindset, most products we design are part of a service if you look deep enough. Providing good services requires designers to collaborate and enable others to think on their own, grasping every key moment to deliver to the customers above and beyond. Designers need to stop making crap and start helping people help themselves.

Designers need to speak the business language and be stealth.

A service mindset means more facilitation and more stratetic business thinking, which is not traditionally a designer’s job, we have to step up to it.

Day 1 Keynote: “Visual Thinking at a Global Scale: The Story of Many Eyes” with Martin Wattenberg and Fernanda Viegas, IBM Research Visual Communication Lab

Manyeyes was conceived as a research project to research how information graphics used in a social network context will have effect on people. Go to the site and see for yourself what effect they have on you and notice the comments others have left. This is really a cool project.


Here’s a really great word-based visualization of one of my favorite plays:


This is my latest interest, what motivates people in different cultures?


Activating Consumers with Mark Jones, IDEO, Chicago

Mark presented a case study on a project they did to redesign the service of a health insurance call center. The methods they used to help their client involved doing observations, domain study, working with stakeholders, experience maps (“the health journey”), workshops on finding a focus (“be clear about your role: guide? teacher? coach? expert? financial advisor etc…”), scenarios, personas. They did experience prototypes and acted out scenarios in workshops with the client. They also delivered a set of service design principles for their client as a deliverable and a prototype (fictional call to show how a the specialist can seize key moments with the customer.


As a result of this project, the client had a create a whole new role in their organization. They also have had to change the way they measure success, prior to this project, they measure how quickly the reps can get off the phone. Now, they don’t. It’s amazing to me the kind of organizational change IDEO was able to make here.

10 Disruptive Trends in Design with Allan Chochinov, Core77

Alan talked about 7 trends in design and showed 3 videos. All good things come in 7s, 3s, and 10s 🙂

  1. Design Memes: camera tosses on Flickr and toilet paper dispenser are some examples of design gestures shared online:
  2. Authorship
  3. Customization (user created)
  4. Omnipotence + Omniscience
  5. Scale
  6. Transparency
  7. Internet of things

The End of Products with Todd Wilkens, Adaptive Path

Todd adapting Peter Merholz’s path, gave a more theoretical talk about how to stop designing products. I think his whole point was that Service Design is a mindset rather than a brand new discipline with totally new methods and techniques. Service design examples he mentioned were: Apple, Flickr, the old tale of Eastman Kodak. Here is something he wrote on the matter. I tend to agree with most of his points. When we design with a service mind-set, we have to look at goals, cultures, relationships and understand people completely, in order to bring to them magical moments in all their experiences with our systems they interact with.

Keynote with Chris Downs, Managing Partner, live|work

This was the best talk at this conference. Chris has a design root and a business savvy demeanor. He knows the craft inside out and has a perfect balance of humility and charisma. He started the talk apologizing to his friend, whose wedding his missing to come to the conference. Then gave preps to the Dott 07 conference. He presented a few case studies: streetcar, GVA, Boots… Chris cut his original presentation off in the middle and took a turn to present something he put together the night before, inspired by conversations at the Emergence party at the Warhol Museum. During this presentation, he asked 3 questions:

  1. What is service innovation and design?
  2. How can we measure it?
  3. How do we make sure it’s successful?

For question 1, he talked about the Baltic museum case study. The museum asked live|work to help them redesign their services. live|work sent them on a service safari, gave them the tools to redesign their own service. What did we learn from this? Service Design is all about giving people the tools to make better services. Designers have to give up control. We didn’t come to any real conclusions on questions 2 and 3. But we know service design is a bit different from other ux disciplines and management consultants in the way we approach problems, Chris used these words to describe this discipline:

  • Facilitate
  • empathize
  • entrepreneurial
  • optimism
  • open
  • collaborative
  • stealth


Pre Conference workshop


Core’s review on the conference


Hey Interaction Designer! Are you a rocket scientist?

I was having dinner with some friends, we inevitably came across some pretty geeky topics: recursion, evolution and relativity were amongst them… To make it more interesting for me, I drew analogies to my work in my mind. The techniques that Turin, Darwin, and Einstein all used to help them arrived at their world-changing scientific discoveries and theories are the ones core to our Interaction Design work. Maybe “design is rocket science” after all? Well, I haven’t figured that out yet, everyday passes, I feel differently about it.

Turing and simplification

Turing, the father of computing, whose work led us to early computing theories like recursion and eventually led to progress in artificial intelligence, used the simplication method to design his Turing Machine studies.

When challenged with the question of can machines think, Turing devised the Turing machine experiment to answer this question. “Turing originally proposed the test in order to replace the emotionally charged and (for him) meaningless question “Can machines think?” with a more well-defined one. The advantage of the new question, he said, was that it ‘drew a fairly sharp line between the physical and intellectual capacities of a man.‘” (Turing on Wikipedia)

What can we learn from this?
Interaction Designers are often faced with trying to answer deeply complex problems. Like Turing, we have to rely on the method of simplification as a way of problem solving. When we are handed a problem, they are often accompanied by a lot of opinions, conjectures, solutions; we are handed documentations written by stakeholders, SMEs, and even customers themselves. We read and listen to all of them, and we have to distill all of that into a very simple problem definition in order to help everyone see clearly what really is the problem that we are trying to solve. My experience is that when we can do that well, we provide a clear vision for a product beyond the design work. And that is when we get to sit in on strategic level conversations. Thus, this ability can help us make huge changes in places we work.

Darwin lets his observation lead his scientific inquiries

Darwin, the father of modern science, began his scientific inquisitions with observation in the field. Like modern day designers and scientists, he spent time in the field. He attentively saw everything around him and let nature be in control of guiding him to answer questions and to raise questions he didn’t know to raise.

(From Wikipedia, “The voyage of the beagle”):

“The Beagle survey took five years, two-thirds of which Darwin spent on land. He carefully noted a rich variety of geological features, fossils. At intervals during the voyage he sent specimens to Cambridge together with letters about his findings, and these established his reputation as a naturalist. His extensive detailed notes showed his gift for theorising and formed the basis for his later work. The journal he originally wrote for his family, published as and living organisms, and methodically collected an enormous number of specimens, many of them new to science.The Voyage of the Beagle, summarises his findings and provides social, political and anthropological insights into the wide range of people he met, both native and colonial.

What can we learn from this?
In a business world, we are taught to focus on figuring out the problem and coming up with a solution with as little time as possible. Designers can find themselves in situations where their stakeholders and those who pay for their work do not appreciate observational research. It’s not just business people, I have even worked with people who are UX professionals who did not have that appreciation. When you are asked to find out questions to a fixed list of questions, you may be motivated to just do that. Well, don’t! That prevents you from doing great things. If Darwin had a preset of questions and only followed them, the world will be a different place today.

Noticing things while we are out in the field is probably one of the most important things a designer can do for his/her own work and for organizations that pay them.

Einstein went with his hunches

When Einstein was solving the relativity problem, he had a hunch about something – “the speed of light is constant”. While it was just a hunch, he was willing to let it lead him for a while on this scientific inquisition and see where it would take him. This flexibility in thinking ultimately led him to the theory of E=MC2 and his theories changed the world we live in.

“A new idea comes suddenly and in a rather intuitive way. That means it is not reached by conscious logical conclusions. But, thinking it through afterwards, you can always discover the reasons which have led you unconsciously to your guess and you will find a logical way to justify it. Intuition is nothing but the outcome of earlier intellectual experience.” (Via article: Einstein’s Discovery of Relativity by John Stachel)

“I soon learned to scent out what was able to lead to fundamentals and to turn aside from everything else, from the multitude of things that clutter up the mind.” (Via article: Holy Curiosity,

What can we learn from this?
Often, when we conduct user research we get these inexplicable hunches – be it some new inspiration, a new idea about the customer behavior you can’t quite articulate and have not enough evidence to back up, a design idea that is premature… If you pay attention to these hunches and let them pull you a bit in your research, they often help you form powerful inspirations at the end for solid design concepts.

Be flexible in the field and let your observations guide you instead of the list of questions your team came up with before you started the research. Because once a problem is better understood, the list of questions you started off with will no longer be relevant. Because as you observe and listen to your customers, they tell you things you didn’t even know to ask.

Simply, if you get a hunch about something, treat it like an information scent. Tirelessly pursue it. Pay attention to it and keep following your instincts. Keep inquiring about it. Notice it in the environment, in conversations, in artifacts, in the way people express their needs, desires and emotions… As you keep paying attention and letting yourself connect, this connection will eventually serve as the ground for your design. It will help you inspire others.

When I let myself do research this way, I come up with designs that have cores. Designs that don’t break. Once you put a core in your design, it is like the personality we develop as children; it’s not something people can easily change. When a design doesn’t have a core, it breaks easily when people question it or when they want to add things to it. The personality you develop as a child stays with you no matter how much you’ve been through, it’s genuine to you, it makes you you. A design that has a core will not be frankeisteined when it grows — all products grow, you can’t help that — but you, the designer can help it grow healthily and beautifully by first providing it a core.

I started to realized the powerfulness of hunches when I had an experience working with someone who doesn’t work this way. When I expressed my hunches, I was questioned, and when I couldn’t back up the fuzziness, I was discouraged to keep pursuing them. I couldn’t convince my team to give up the list of questions and let the evidence lead us. Well, due to my own inexperience, I thought maybe this other way is a more certain way, so I went with their method. Later on in the project, I realized that I should have pursued my hunches because though I managed to give the design as much integrity as possible by articulating the business and user needs to back up the concepts, the design had no core. I know now that it is something that will cause us problems later as the design grows. Certainly, that happened before we even got out of the concept phase and the concept phase dragged on and on.

In conclusion…
So, I didn’t answer the question if you are a rocket scientist or not. But you certainly can use the same scientific inquiry techniques as these great people:

  1. Simplify problem definitions: problems are complex, simplify them, your solution will follow in that course.
  2. Observe and follow scents: when you are out in the field, observe the environment, listen to what people say, follow the information scent they are trying to give you. Put your subjects in control of delivering you questions and answers. Trust them, they will lead you to find what you need to know, not a preset fixed list of questions.
  3. Follow your hunches: following your hunches will lead you to ask questions that helps you get to a good design. This allows you to give a core to your product, allowing it to grow elegantly.

Making research work – Todd Wilkens

Slides & what I got from it:

What is generative research, what makes good user research?
Generative research is good for generating insight and empathy within an organization

Features to Experience is like
Lab studies to Meaning

More qualitative and contextual work = more empathy

It’s NOT about listing what they need or said, it’s about what’s meaningful in their lives. Let’s say that again!

A little bit of empathy in the hands of a designer is hugely more powerful than listing what people need and the features we will offer them…

Case study: People and their possesions.
The magic of things: symbolism and meaning: Motivations (lead to) —> behaviors (establish) —> connections

Interesting stuff doesn’t make research successful, why does good research fail?

Because no one understands its value, its relevance or how to make of it.

Who create successful products?

YOU! You create successful products. Designers, developers, business analysts, customer service, product managrers, researchers, executive manager…. WHOLE ORGANIZATIONS MAKE SUCCESSFUL PRODUCTS

We help organizations make successful products


Throwing research data over the wall -> so little of it is documented and gets thrown over the wall…

Todd calls this the “research martyrdom”

Research has to be actionable and durable:

Actionable: designers should be able to know what to do with it, not the 10 recommendations, they know how to do their job.

Insights should have longevity beyond the research findings meeting. someone else learned something and then someone else goes out and learns the same thing again.


1. Integrate research and design
2. Improve communication


Do analysis with them there

If you can’t get them to do this with you, then the next best thing is to communicate:

research reports: where good insights go to DIE!
Wilken’s law “the effectiveness of research is inversely proportional to the thickness of the binding.

Good research deliverables:

  • Are clear and straight forward —> people can do something with it
  • Engage the audience —> how is this relevant to various audiences.
  • Tell the stories —> stories aren’t told in bulleted lists, we have to be good story tellers: connect with metaphors, values….


  • Insight meets empathy
  • From the persona behavior and motivations drove a lot of the design
  • Obstacles, given situations, triggers, highlight problems
  • Archetype is not stereotype, stereotype loses empathy

Show your ideas to users in the field, even in the mist of research:
Fidelity doesn’t matter, whatever you can do:

  • Comic book
  • Hifi
  • Lofi
  • Prototype a strategy
  • A box
  • A pitch
  • A scenario

Find ways to develop empathy

Example: Dan strapped a pound of rock to himself and walked around with it for 2 days to see how it feels to carry the insulin machines around when he was doing the charmr project.

Keynote: Adapting the path – by Jan Chipchase

Jan is my hero. He’s like the James Bond of user research and design. For the first time, I think it’d be pretty cool to be a bond girl ;D

All joking aside, Jan’s doing some really cool stuff, jet-setting around the world engaging in researching the way people live in emerging markets. His group is located in Japan, tracking technology trends along with human behavior. Answering questions like:

  • Who are you?
  • How can you prove it?
  • How do illiterate people communicate?
  • What do you carry where and why?

Seems like a random set of questions, but I guess Nokia would be interested in that. To answer these questions, he and his team engage in some international investigation in allies and homes. They get challenges like: “you have one month to design a phone for illiterate people.” Turns out delegation is a big deal in that situation, good thing people who do that often live within strong knitted social networks.

He is now involved in the study of the future of urban spaces. Which turns out, as expected, to be a huge, elaborate study involving 20 translators, months to prep, tons of local guides, other experts, creative team, street survey team, running 6 types of social gatherings…

Co-creation (participatory design) is also a big part of what they do. Watching people express themselves can be a great learning experience.

Observations are the most important part of field work. What do things around people tell you about their values, perceptions, and how they will interact with your stuff.

Local norms are telling. For example, in Thailand they sell fake braces, people wear them to show status = being able to afford dental care.

All of this adds up to having an informed opinion. It builds credibility.

Our international man of mystery offered some valuable advice to the young ones:

What’s worked:

  • Make your colleagues smarter: how can I do what I do to make you smarter?
  • Know who you are: what are you interested in? what are you not interest in? Communicate boundaries, use resources at your disposal, shit happens in the field.
  • Let go: we want to know so much about people, let people in control of helping you find out more about them.

Jan’s blog.

Waterfall bad, washing machine good – by Leisa Reichelt

The gist of this talk was about designing product with an agile mindset. Iteratively, collaboratively, and humanistically (use of scenarios or stories). This is not new to us at Liquidnet, we’ve been trying to methodically carry this out in increasingly bigger projects.

Lisa’s background is in project management. I like her sketches, they’re very cute. Here are a few key points:






Sam Felder took notes exactly the way it is, here it is.

Pattern based design communication techniques – Doug LeMoine

It’s always nice to meet friends from Cooper on the road. Doug, a master Design Communicator, talked about how to communicate a design based on patterns you identify. His talk can be found here.

He started the talk with describing the roles of the Design Communicator (DC) and Interaction Designer (ID) in a traditional Cooper team. I work in such a team structure and we are still learning how it works after 2 years of adopting it. We all laugh when he used a Beatles reference comparing DCs to Lennon (the word-smith) and IDs to McCartney. 🙂 Similarly, DCs can also be described as philosophers, like Socrates. They pose questions to move the designer along and help them shape an ideas into a full blown concept. I like that analogy because it is really easy to take this role for granted and simply think that a DCs test the ideas or just communicate them.


The philosopher analogy hints at the most subtle, yet important and probably the most difficult part of a DC’s responsibility – they pose questions that lead a designer in a creative journey with the final stop being an elegant solution. I was first exposed to the Cooper team concept 4 years back. The most attractive part about that partnership to me is that instead of a couple of people throwing ideas down on the table and getting no where in a fury of competition; the team structure sets up roles that have distinct but complementary responsibilities working on getting to a common goal.

I used to have to “DC” myself, (that’s probably true for everyone even if they don’t know it). I turn off my ideation part of my brain and I try to define the problem (although that’s not always entirely possible). Then I turn off the problem definition motors and brainstorm concepts. I imagine that this takes twice as long compared to a team of 2 people doing both together; especially when they are each really good at the one thing they do. This partnership can be really helpful particularly in situations where we are solving problems for really complex applications.

So to sum it up, DC’s have a tough job and they really do make designing a much more fun and collaborative process. That’s why they make the big bucks. 😉

Doug then goes on to explain the documentation methodology with a case study on a project he worked. It’s a web tool used by financial advisors to explore new ways of analyzing portfolios and understanding performance. His client was Barclay’s Global Investors. His design documentation approach uses a problem-solution pattern.


I forgot the persona’s name, but here is a little bit about him:


The big idea from the talk is recognizing patterns in your design and describe them in a way that empowers the reader to think on their own when building a living application over time. An example is to document global behaviors: “things that do this generally have this behavior”. Doug also advised that documenting similar things in similar ways throughout facilitates learning. We should aim to provide a pattern language for a particular system that lives beyond the screen layouts being designed today because every system is a living thing.

The DCs at Cooper ask these questions when thinking about how to tell the story about the design:

  • How does our design help the persona get his work done?
    • User scenarios:
      • Shows behaviors in context of the problem they solve.
      • Communicates the narrative of the design.
      • Facilitates the discussion of the design in human terms.
  • How does the behavior work?
    • Screen layout diagram:
      • Describes important elements and behaviors.
      • Roots the screen in context of the workflow.
      • Provides access to related detail.
  • What is the essence of the solution?
    • Rationale:
      • Tells why is it good?
      • Describes why certain solutions are not recommended.
      • Tells the story of the design.
  • Are elements of the behavior representative of core, repeated behaviors?
    • Global behaviors:
      • Provides principles for solving common problem.
      • Describes similar problems with similar behavior.
      • Draws connections between areas of the interface.
  • How do we make all of this easy to find?
    • Table of contents:
      • Uses clear, consistent nomenclature.
      • Uses descriptive page headings.

Designing evolving products – by Ryan Freitas

Once in a while, I come across people who really impress me. When that happens, it fills me full of hope – “maybe one day, I can be like them.” Ryan is one of those people. His eloquence is infectious.


I related to his talk on evolving products because I am in the mist of working on a project that is, what Ryan calls a “punctuation” of our product lifecycle. Every product we work on evolves. However they evolve differently for many reasons. Some iteratively evolve. Some reach a gradualism stasis,that is when a punctuation is necessary. When he said it, it was much better put 🙂

Ryan’s talk was round the toolset for doing punctuation. I like the word choice here, because people often talk about “innovation”. The idea of “innovating” can really take us off track because people have different ideas about what that means. Truly, when your design connects the business offering genuinely with the people you serve, you innovate on real value. We live and breath this at Liquidnet. However, Ryan was able to offer some new insights into how we can do that better.

This is the toolset he covered in his talk:

1. Restate the value
2. Tell the story
3. Atomize the feature
4. Tidy the seams

Sounds simple right? I know, he’s good. Then he breaks it apart what it all means.

1. How do you restate your value?
You get to know your audience, your benefit to them, your competition, and differentiation. Getting to know your audience, of course, requires user research which hopefully combines interviews and ethnographic techniques. Knowing your benefit to them would come from really getting to know the business and understanding how the business is connecting with their customers. Knowing your competitors may be a simple web search and dissecting a site’s value. In our case, we had to dig deeper. The the differentiators, they should be fairly understood by the business. However, in our recent project, we had to restate it in relation to our new personas and the new industry landscape.

After researching answers to all these questions, you start to dream about your personas, secretly sketch designs in your notebook, your brain is about to explode with myriad of possibilities and directions. That is time to synthesize everything down to an easily understandable message. What is your elevator pitch?

2. Tell the story
Like Ryan, our team develop personas to keep our organization focus on the human behaviors. Each of our personas represent one obvious behavior pattern within our customer base. Personas help us be very specific about goals, desires, attitudes. We do “a day in the life” scenarios for our personas and I hope soon we would storyboard them Kevin Cheng style to bring more context to the useage scenarios.

img_9103.jpg img_9104.jpg

I like what he said “don’t force the user, fit into their lives.” In our current project, we built value statements that work fine for us now. If I have to do it over again, the things I would try to do better are: speak in the user’s language, be very specific by using plain language, keep it as short as an elevator ride of 15 stories (not 60), and give it a core.

3. Atomize features
Just as your value statement needs to speak to the core value of your product or service, so does your prioritization work. Each project comes to a point where you have to start deciding what goes into release 1, 2, 3 and etc. Identifying and focusing on the core will help you “peel that onion”. How? He had some advise:

“Ride the winners” – Rich Skrenta. (rich skrenta,

Work within constraints. This one is most interesting to me. What if your technology you have to build this on was very constrained and you have to work with the basics? What is the thing you must embody in your product? What lies at the heart of your product that people respond most passionately to?
Conway’s law:


“Despite jocular usage and jocular derivative “laws,” Conway’s law was not intended as a joke or a Zen koan, but as a valid sociological observation. It is a consequence of the fact that two software modules A and B cannot interface correctly with each other unless the designer and implementer of A communicates with the designer and implementer of B. Thus the interface structure of a software system necessarily will show a congruence with the social structure of the organization that produced it.”

4. Tidy the seams
So after you have clearly articulated your value and you manage to derive a design strategy and roadmap. It’s time to carry out the design. You come to a “oh shit” moment – you have more product channels or simply more work than one design team can manage, so you have to break up the work. In our case, recently we’ve had to break up one product to manage by different design teams after the design framework was completed by one team. The sheer amount of work and deadlines necessitated the break. We hope that similar philosophies in design and working closely will help us get to the end delivering a coherence experience.

Ryan cautioned that the result of the discontinuity is losing your customers instead engaging them. But he offered some advise: communication is not enough!

  • Emphasize on commonality throughout all key-elements of the experience. If you have a design element that does X in one channel of your product or service, make sure it’s respected across all channels.
  • Reduce noise wherever you can. Find things that will trip users up.
  • Start from the core. Prioritize 3 things that your product must embody, build those into each channel with a level of consistency that won’t lose your customers.

Delivering one experience across many channels done by many different teams is no easy task. I am excited to see what we come up with and how we pull it off! I think it will be worth it at the end.