Noise Between Stations

Category: Design

  • Finally, The Iraq War Ends

    Iraq War Ends

    …not really, unfortunately. But that was the headline on a “special edition” of the “New York Times” today. The credibility was in question from the start, as the paper was handed out free at the subway which is never the case with the Times. The production is quite accurate, but a quick glance at the date reveals July 4, 2009.

    I love it as a clear example of a tangible future. But the editorial is so far to the left that we’re not really fooled. Only those that already hold these positions will think, “Yes! This is what we could create by July of next year!” So essentially, it’s propaganda. Personally I would have liked to see an editorial stance much closer to reality but with enough difference to be inspirational. (Just for the record, I’m fairly progressive socially, and excited about the results of the elections.)

    Of course, we’re talking about the future, so I could be completely wrong about what happens.

  • A New Service: Future Practice Webinars

    We’re pleased as punch to partner with our good friend Lou Rosenfeld at Rosenfeld Media to offer you Future Practice Webinars. Our first two events are Modern Web Form Design with Luke Wroblewski and Using Mental Models for Tactics and Strategy with Indi Young.

    When we created them we wanted to accomplish two things:

    1. Provide a forum for advanced practitioners in the field of user experience design to share with us their best thinking on topics that have immediate practical value and to show us where the practice is going in the long-term to help us prepare. Hence the series title, Future Practice
    2. Enable practitioners like yourself to benefit from this education at a lower price than in-person seminars and conferences, without having to travel and emit all that nasty carbon.

    For more information and registration, go to the Rosenfeld Media webinar page. For 20% off, use discount code NBSWBNR

  • Did You Know Brainstorming Is 70 Years Old?

    That’s right, Alex Osborn started popularizing brainstorming in the late 1930’s. It’s a classic tool I still use, but I have to wonder if there’s something better.

    Brainstorming is simple, and I would bet this simplicity is the key to its popularity. Yet even the basic rules that Osborn set out aren’t very common. Brainstorming is too often reduced to sitting around a conference table discussing a topic rather than storming an objective.

    I tried a little experiment with my Business & Design students tonight, introducing them to three different idea generation tools: brainstorming, “yes, and…,” and question the brief. Brainstorming and Yes, and… were slow and stiff. Part of this is probably due to my skill as a facilitator, but I also think these tools require some experience to use proficiently. I liken it to building muscles; it takes some time doing it to see results.

    Question the brief, on the other hand, more easily generated plenty of usable ideas, and there were even some explicit comments preferring this method, so that we returned to it. My theory is that it’s simple enough to remember but has just enough structure to produce specific kinds of ideas. That’s a balance I’m going to seek with my other concept design tools.

    question.the.brief

    See also my concept design page at Smart Experience.

  • Spontaneous Interaction Design Group Work Styles

    There was a New York City IxDA event at Roundarch last night that challenged 10 teams of designers to invent the portable electronic ink magic paper of the future. In addition to the usual functional stuff, fun ideas emerged like using it as a yoga mat, a DDR mat, or modules that could be connected together to make various sizes.

    There wasn’t enough time to do a lot of critique of the designs, but it was fascinating to see how each group of 3-4 people self-organized. One group compared their process to speed chess — each person took a short time to iterate on the design and then ‘hit the clock’ passing the baton to the next person. Two groups talked about working together to define the problem and environment, then working independently on separate tasks. One of these groups actually moved apart physically.

    The composition of the groups of course was pivotal. One father of a 3-year old was inspired by his son’s toys. A business analyst on another team ensured specific requirements were achieved.

    And the methods varied too. Most accepted the advice in the brief to prescribe and describe scenarios, but others just picked a strong theme like “magic” and riffed on this pleasingly, having the device learn your gestures and automatically load images from a camera. It was a great reminder to me that the questions you ask determine the conclusions you reach.

  • Three Resources for Learning Web Analytics from Marko Hurst

    A friend is contracting with a design firm for work that will include web analytics, so I asked my colleague and expert Marko Hurst for resources that would provide a gentle introduction, mostly from a marketing perspective. He recommends:

    1. Web Analytics Demystified — A bit more technical, but not a tech book geared for someone who wants to learn analytics
    2. Call To Action — Good mix of marketing & analytics
    3. Waiting For Your Cat To Bark — More of a marketing first, then analytics, but a fantastic read that everyone should read regardless. Introduces Persuasion Architecture, very cool stuff.

    btw, congratulations to Marko and Lou Rosenfeld who are teaming up to write the Search Analytics book.

  • New Article on Concept Design Tools

    The nice folks at Digital Web Magazine published my new article on Concept Design Tools. It’s already received some nice reviews in the Twitterverse…

    For those of you who haven’t seen Victor Lombardi’s new article on concept design tools, it’s a must read…

    …it’s brilliant stuff and super accessible. It’s great to see solid thinking around the topic. There isn’t enough of it.

    …great article on concept design!!!!

    Here’s some reactions from bloggers I keep hearing over and over, confirming why I think this topic is important for digital designers. Steven Clark asks, Where is the breadth of our design?…

    where is our design process preceding the implementation phase? The moment we receive the brief we’re practically falling over ourselves to push forward, and implementation seems to go on at the same time that we’re figuring out what the product should do. This is as applicable to web solutions as to applications, we jump in boots and all with predetermined assumptions.

    And Martin Belam writes…

    One strong theme that came out of it for me personally though was that, unlike industrial designers, when we make web applications and sites we tend to rush to wireframes and ‘colouring in’ before we have explored multiple potential solutions. Victor’s championing of questioning the brief looked like a good way to try and break out of that vice.

    Since writing it I’ve already discovered similar work that’s been done over the past several decades. My approach is different in that the tools are simple and fast enough for any designer to use without having to learn a lot about method, but I will be spending some time with the masters to learn how I can climb onto their shoulders.

    selective memory design concept tool

  • 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:

  • 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.