Noise Between Stations

Author: Victor

  • Thoughts on the Euro Information Architecture Summit 2008

    I’m just back from the Euro IA Summit held in Amsterdam, September 26-27th. Overall it was a good event with many warm, interesting people in attendance. I was considering attending PICNIC as well but as I heard it was “very corporate… lots of white men with PowerPoint” I spent my time with the city instead. Hearing a speech is slightly better than reading it or watching it online, but only slightly.

    The Summit kicked off with a talk from Adam Greenfield called “Why I’m Not an Information Architect and You Shouldn’t Be Either.” Where the community used to be filled with electricity — taking on great new challenges — he lamented it’s now focused on creating wireframes for websites. This doesn’t feel like the field that will create Bruce Sterling’s Spimes. Adam’s focus lately has been Ubicomp, and he talked about how “power and grandeur lie beneath the user interface, in the API” and that “IT has dissolved into behavior” like the swipe of an RFID-enabled train card.

    There’s a lot to react to there. I agree the field is not nearly as exciting as it was seven years ago, and this state makes a lot of us that are comfortable with innovation wonder what communities we should mix in and what IA should be (see Matt Milan’s thoughts for another perspective). At the moment I’m trying to pull back and see information architecture as a new but somewhat established field. Invention used to be necessary of everyone, but now it’s only needed from a few. Compare it to an established field like electrical engineering. At the beginning there was a lot invention, but now we know enough to simply do it. Today, some engineers continue to push the envelope with the design of microprocessors while others specify the wiring in the next model of speaker phone. I would expect IA to settle into the same spread.

    Ruud Ruissaard of Informaat discussed the current state of content management which can be summarized by satisfaction rates around 37%. He advocated for a more holistic approach to address systems and processes and management. I have to think CMS will go the way of portals, with everyone realizing there’s a lack of flexibility in large installed systems. Instead, let’s move content to the cloud and pull it out with flexible APIs.
    (more…)

  • Small Project Management Things I Want to Remember to Do For Every Project

    1. Keep status meetings to .5 hour, but do them every week
    2. Establish a natural way for the team to share what everyone is doing — eating together, or tasks we all do together — while protecting personal time to think and work individually
    3. Set up a team mailing list and liberally copy everyone on everything; make it easy to filter
    4. Have one place for everyone to go to see what is the next action
    5. Folders to set up

      6. – 1. Discover
      – 2. Define
      – 3. Design
      – 4. Develop
      – 5. Deploy

      – archive
      – assets
      – financial
      – project management
      — agendas
      — status reports
      — proposals & SOWs

    6. For important meetings, supply each member of the team with

      7. – explicitly stated objectives
      – the agenda
      – a list of attendees and their roles
      – maps and necessary logistics
      – a list of tasks needed to prep for the meeting

  • No-Click is the New Click

    I’m bummed I’ll miss Dan Saffer’s talk tonight on Tap is the New Click (though happy I’ll finally get to try Five Points as I take a client out to dinner).

    But on that topic, I just came across some examples of interaction design that do away with the click altogether. It’s radical enough to require serious re-learning for most people, but a significant enough time-saver that some of these gestures will inevitably catch on.

    http://www.dontclick.it/ is a fantastic experiment in click-less browser-based interaction

    And there’s three similar concepts for swipe-based text entry out now:

    Swype

    Shapewriter

    SlideIT

  • Four New Business and Design Classes at Smart Experience

    You need a great design to please your customers, and a great business model to pay for the design, so we’re offering classes on both topics to help user experience practitioners, managers, and entrepreneurs thrive in New York City.

    For 10% off any class, enter the code NBS when registering. If you plan to attend with friends or colleagues, contact me for a bigger discount: victor (at) smartexperience.org.

  • A Schedule for Planning a Presentation

    I tend to think and think and think and think and, at the last minute, throw together slides that represent what I want to say. This time I resolved to be more prepared. Here’s my deadlines:

    1. Aug 29 – Make schedule; list all potential points I could make; filter points to ones I should make
    2. Sept 3 – Outline talk
    3. Sept 6 – Collect/make audio/visuals
    4. Sept 13 – Complete draft of presentation
    5. Sept 19 – Revise draft
    6. Sept 21 – Rehearse presentation
    7. Sept 22 – Leave for Amsterdam

    In reality, the outline talk and collect/make audio/visuals steps are happening together, which is feeling like a nice way to craft my story for a conference. Establishing intermittent deadlines gets my ass motivated, and knowing I have time to iterate assures me I can get the quality to where I want it.

    See also How To Tell A Story.

  • How Recruiting iPhone Designers is Like Raising Kids

    When two of the really amazing thinkers I admire — Ken Bain and Jeanne Liedtka — both say they admire Carol Dweck, I figure it’s time to figure out who Dweck is. Her latest book, Mindset, provides some fascinating psychological support for the power of play and prototyping, as she says…

    People who believe in the power of talent tend not to fulfill their potential because they’re so concerned with looking smart and not making mistakes. But people who believe that talent can be developed are the ones who really push, stretch, confront their own mistakes and learn from them.

    Janet Rae-Dupree, writing in the New York Times, reveals an interesting connection between Dweck and the iPhone:

    (more…)

  • Using Real Options to Value Design Concepts

    The common way that financial people will judge the potential value of a project, or a design concept representing a potential future concept, is by building a model, usually a discounted cash flow model like Net Present Value (NPV). The calculation essentially asks, if we do this project and gain the profit we think we’ll gain, how much is it worth to us right now? That way we can compare it against our other options.

    The problem with these models is that they assume the world doesn’t change. The model tries to predict everything that will happen in the project from beginning to end in order to arrive at a single numerical value. But in the technology world, there’s lots of change.

    So peeps at the forward edge of product and service development have started using real options to value projects. Real options essentially breaks the project down into a series of decisions. At each decision point a number of outcomes can occur, and for each outcome there’s a probability it will occur. There’s also a revenue associated with each outcome that we receive if it occurs. By multiplying the probability by the revenue we get the value of the option.

    This is often illustrated using a decision tree, as with this analysis of a drug in clinical trials…

    What’s the big deal? It turns out this is a better way to value investments in Internet services for at least three reasons I can think of off-hand…

    1. Versioning: The Web 2.0 way of doing things is to release our work in stages, the public beta being a perfect example. If the beta is a big fail, we stop there and cut our losses, or we go down a different path of the decision tree.
    2. Uncertainty: There’s a great deal of uncertainty in our work. Twitter, for example, is a big success, but at the cost of a very tricky technical challenge. Instead of an NPV model that would judge the value of the project to be either simply negative or positive, we can model this reality of “large audience / technologically expensive.”
    3. Fast Risk Management: The ease of building betas makes it tempting to skip a big financial modeling activity, especially if it can’t accurately reflect (i.e. predict) how customers will react. Creating at least a simple real options analysis can save a lot of investment before building a beta that is hard to emotionally trash once it’s built. And while it’s tempting to say predictions are impossible so we should just run a trial, few managers with any P&L responsibility will invest in that.

    Real options isn’t a perfect technique, however. Proponents claim it supports decisions with “mathematical certainty,” but the probabilities are derived from managers’ experience and judgment which is subjective and imperfect. Getting a group of people to agree on the probabilities may be difficult, and once a project is up and running a team may be unwilling to revise their estimates downward to reflect new information, much less kill their own project. Still, for the kind of work we do it’s better than the old ways.

    References:

  • Presenting My Concept Design Work in Amsterdam, September 27

    I’m happy the concept design research and development I’ve been doing has received some attention, even though I haven’t had much time to share my work. That will start to change next month when I present some tools for generating concepts at the 2008 European Information Architecture Summit in Amsterdam, where I’ve been honored with the closing plenary position.

    Last year’s German IA Conference had a great vibe and a wonderful group of people, I’m looking forward to more of the same in Amsterdam.

  • The Age of Heretics, Updated in 2nd Edition

    Art Kleiner revised The Age of Heretics and the 2nd edition is on it’s way to my greedy little fingers. It explores heretical ideas in management starting in 1945 through several case studies to find that:

    • People are basically good at heart; they are fundamentally trustworthy. Only workplaces that give their members the chance to learn and add value through their work will succeed in the long run.
    • Aim for quality of work, and money will follow.
    • Industrial growth is not always desirable. Sometimes it can be destructive.
    • Predictions and forecasts are mechanistic substitutes for awareness, and substitutes for awareness lead to bad decisions.
    • There is no such thing as “just business, nothing personal.” Business is always personal, even if it isn’t supposed to be. And we are better off recognizing that.
    • Everything in business is connected to everything else. Business is a complex living system with many interconnections. No one can control the system; one can only learn to influence it.

  • Studio 360 on A Pattern Language

    This morning Studio 360 broadcast a piece on Christopher Alexander, A Pattern Language, and the influence of patterns in software development. If you know the story, you know the story. Still, I always like hearing Alexander speak, and this is the first time I’ve heard Ward Cunningham’s voice.

  • Concept Design: Name the Baby!

    When you create a product or service concept, you should give it a name. Sounds like a no-duh idea, but in the heat of the moment we forget to do this. Sometimes…

    • we give them numbers or letters. “You see the change in materiality here in concept 2…” or “Clearly Concept C is a total paradigm shift…” But this kinda sucks. It’s hard to remember how the concepts map to numbers or letters, and that makes it hard for people to reference the concept. “Um, you know, I think it was the second one, the one with the thingie…” And if people can’t reference it, they can’t talk about it, much less buy it.
    • we only have one concept, so we name it after ourselves. “Our idea is to…” or “The Bixby Canyon Software System, from Bixby Canyon Inc., gives your plants just the right amount of water…” This feels good at first because you can publicize your company and concept name at the same time, and it avoids those messy, expensive naming exercises. But it falls apart when concepts grow up into products. Say when…
      1. you want to change the product or the product name, but people keep referring to it by your company name. You’re stuck, or you change it and risk lose brand recognition.
      2. you introduce a second product which means you now need three names, two product names and a company name, that need different identities. For a long time Symantec was synonymous with anti-virus software, and they had to work hard to be a company known for more than that.

    An exception is when you (intentionally or not) have a naming system. Let’s say your company and your first product name is Super Fantastic. When the next product arrives, you name it Super Amazing, then Super Stupendous, and so on.

    Just as you wouldn’t have a baby (or a company) without naming it, don’t birth a concept without naming it either.

  • Two Things Design Experts Do That Novices Don’t

    In my research on concept design processes, I’ve come across two ideas that jumped out as vital behavior that differentiates expert designers from novices.

    The first comes from Nigel Cross of Open University, UK, who seems to have studied designers and their processes more than anyone I’ve come across. In his Expertise in Design (pdf) he says (emphasis mine)…

    Novice behaviour is usually associated with a ‘depth-first’ approach to problem solving, i.e. sequentially identifying and exploring sub-solutions in depth, whereas the strategies of experts are usually regarded as being predominantly top-down and breadth-first approaches.

    While the protocol studies he cites contradict this, when it comes to digital design I find this explains why I see so little concept design these days. Both product developers and designers have a tendency to jump on the first great idea they generate and head down one path, instead of patiently exploring the space of possible solutions. The pain is only felt far down the line when development makes it obvious what doesn’t work and what could have been.

    The other big idea comes from How Designers Work, Henrik Gedenryd’s Ph.D dissertation. In the third section (pdf), he observes how designers go about defining the problem to be solved, the most difficult part of the project. How the problem is defined can determine the success of the succeeding design task…

    …the two contrasting attitudes make the whole difference between frustration and progress: Quist literally makes his problem solvable, whereas Petra finds herself stuck. The bottom line is that Quist who is the “expert” is acting as a pragmatist, whereas Petra, the “novice”, acts as a realist. And as we have seen, this accounts for a great deal of his superior performance. The choice of either position is not merely a matter of ideology, but has important consequences.

    In short, experts are pragmatists, they re-set or re-frame the problem to make it solvable. Novices are realists, they take the problem as a given and get stuck.

  • Maybe I’m Providing a Better Education than Ohio University

    Someone just brought it to my attention that a student named Feng Xia who received a Master of Science degree in Electrical Engineering from Ohio University in 1998 did so with a thesis paper that steals from others’ works, including my master’s thesis. It’s so bad, that after cobbling together various works, Feng couldn’t be bothered to normalize the citation format, or even make the number of citations match the number of references listed.

    Yet, this made it past the thesis committee.

    Why bring it up? One, because if Ohio University doesn’t take the ethical path here I’d like the Internet archive to show what happened.

    Two, I want to gloat a little that large established institutions with extensive accreditations don’t necessarily provide any better quality — and sometimes much, much worse — than my little Smart Experience.

    Just for decoration, here’s some graphs from my thesis I drew by hand circa 1994, probably in MacDraw, with proper references.

  • Woulda, shoulda, coulda. Didn’t. (The Failure to Beta Test)

    Monitor110 was a business/site that tried to filter information for institutional investors. This post mortem from a founder probably won’t reveal any new lessons, but it’s always powerful to see theory — in this case the value of the beta release — played out in the form of failure…

    …By mid-2005 the system worked, but spam was becoming more prevalent and caused the matching results to deteriorate, e.g., too much junk clogging the output. Around the same time we started to dig into natural language processing and the statistical processing of text, thinking that this might be a better way to address the spam issue and to get more targeted, relevant results. This prompted us to not push version 1.0, instead wanting to see if we could come up with a more powerful release using NLP to mark the kick-off. In retrospect, this was a big mistake. Mistake #5, to be precise. We should have gotten it out there, been kicked in the head by tough customers, and iterated like crazy to address their needs. Woulda, shoulda, coulda. Didn’t.

    …We talked about “release early/release often,” but were scared of looking like idiots in front of major Wall Street and hedge fund clients.

  • How To Tell A Story

    I remember the first time someone impressed upon me the usefulness of storytelling. Back in 2000 a researcher came to Razorfish to study how we worked in order to improve our knowledge sharing. He told me how Secret Service agents studied storytelling so that, if they suddenly found themselves in the back of a car with the President for 5-minutes, they could quickly summarize all the pertinent facts about a situation in a format that was more likely to be absorbed.

    And now, eight years later, I’m finally getting around to working on my storytelling skills. Barry McWilliams wrote a great set of guidelines for storytelling in his Effective Storytelling: A manual for beginners…

    Characteristics of a good story:

    • A single theme, clearly defined
    • A well developed plot
    • Style: vivid word pictures, pleasing sounds and rhythm
    • Characterization
    • Faithful to source
    • Dramatic appeal
    • Appropriateness to listeners

    Adapting to our audiences:

    1. Take the story as close to them as you can.
    2. Keep it brief and simple
    3. Stimulate their senses so they feel, smell, touch and listen and see vivid pictures.
    4. Describe the characters and settings, and help them sympathize with the character’s feelings.
    5. Aim your story at the less experienced when telling to a mixed audience

    (more…)