The user centered process of mostly everything

Manuel Toscano and I have drafted out a rough prototype of a possible generic user centered process that really be used to create everything from a branding strategy to a marketing launch of a new product in a new market. Do chime in what you think… niblettes could you please pick logic holes in this?

Immersion –> Analysis & Synthesis –> Insights –> Rapid prototyping & tweaking–> rollout

I’m so tempted to name it something exotic like "Bode Plot" or "feynman process" for the fun of it.

This entry was posted in Business. Bookmark the permalink.

7 Responses to The user centered process of mostly everything

  1. Uhm, how about adding “Incorporate user feedback” here and there (or, in this age of perpetual beta, at least at the end)?

  2. niti bhan says:

    *grin* ah yes, the arrows that show the cycle of feedback leading to improvements, I was waiting for the graphic version to have that!

  3. Yes, I agree about iteration. During Insights & also during Prototyping and even at the end as Peter rightly says. However this is not limited to user feedback since the professional team also learns and the customer also learns. That feedback also loops as you iterate.
    In general this is how we explain it here at RMHQ although we’d break rollout into more phases if we were involved in implementation. I wouldn’t do that for this process definition though, it’s nice and clear as it is.

  4. Ok Niti, you asked for it…
    First, yes iterations. But i think we can assume iterations to occur both within and between the identified phases without cluttering up the diagram with arrows
    Second, synthesis follows rather than precedes insight; otherwise what exactly are you synthesizing?? Analysis deconstructs, revealing insights into how things work, which drives synthesis of available elements into new possibilities, that become manifest in prototypes.
    And lastly many generic design processes begin with “discovery” and then move into “definition”. I’m assuming immersion and discovery refer to the same activities.
    However I’ve always felt discovery then definition to be backwards. A solid, repeatable design process really has to begin by clearly defining the business goals to be achieved, the market problems to be solved and the resources. Only then can discovery (or immersion) be appropriately focused, and deliver the most actionable results. Focus is critical because nobody wants to fund a fishing expedition.
    Oh yeah, and I think you may be missing the actual development phase, where designer dreams and engineering/business realities negotiate with each other. Prototyping and tweaking are not full scale development.
    It might be worth unpacking the meanings, values and activities of each of these stages. For instance, do you mean these to be functional stages, with gates between them? where hand-offs and responsibilities change? Or are they more like loose overlapping clusters of philosophically similar activities?

  5. niti bhan says:

    niblettes, to answer your questions, let me explain the vision in my head,
    immersion is the immersion into a new product category or market or brand – either through secondary research or in the field. I see immersion the process by which we would begin to understand the context in which the problem is to be solved.
    analysis and synthesis in this context then is the ‘digestion’ of all the information you’ve immersed yourself in – what is useful, what isn’t, and then the bits fall into place i.e. synthesis
    which leads to insights or opportunity spaces in the problem area defined above.
    this in turn leads to prototyping alternative soltuions in those opportunity spaces, applying all kinds of feedback to tweak and turn it, after which the solution is launched in the mass market.
    development falls into the space between insight and prototyping.

  6. ok, two more holes…
    your first step is immersion. but even your explanation of it assumes an already identified and modeled problem. unfortunately a design process that focues just on the solution is only half a process. The first half models the problem to be solved, the second solves it.
    Furthmore immersion must be guided by firm, clear and measurable business goals. Without these you’re doing pure research, and that’s a different activity from design, with different metrics for success, different expectations, and very likely different financing models (at least in my exp).
    Even Norman has similar ideas(http://www.jnd.org/dn.mss/why_doing_user_obser.html). And while I disgree with much in his article, the notion that pure exploratory research should be conducted outside and prior to any idividual design process both makes sense and agrees with the reality of new product development. What is important to note is that while pure research may be important to identifying precise problems, modeling and understanding those problems is no longer pure research–its applied, and belongs within the context of design process.
    Where do these guiding business goals come from? Well the goals themselves should be clarified as the design process kickoff, rahter than coming in over the wall from some nameless, faceless department drones.
    I also see a problem with putting devlopment prior to prototyping. What are you developing unless its one of the prototypes? Or, what’s the point of prototypng if you’ve already developed the solution? Unless your working definition of development differs from mine.
    Hopefully some of this at least makes a little sense 🙂

  7. niti bhan says:

    niblettes, if the process is not for developing a product per se, or for innovation in the context in which it is understood today, then if you were to look at it as a means of approaching the developmet of a marketing strategy or a rebranding exercise, would the same gaps apply?

Leave a reply to john trenouth Cancel reply