13 Responses

  1. » Monkey testing aclairefication
    » Monkey testing aclairefication at |

    […] user experience professionals, a wireframe monkey merely churns out rapid prototypes rather than performing ideation and problem solving. Yet another […]

  2. M.M.Vijaiyan
    M.M.Vijaiyan at |

    Let the UX specialist do the Story, Screenplay and Direction and leave the shooting part to the cinematographer!

    Reply
  3. Ray DeLaPena
    Ray DeLaPena at |

    I think another perspective to add here is considering the purpose of the deliverables. Wireframes has become a loaded term of late. What is a wireframe anyway? It’s a diagram to indicate the structure and flow of something (app, site, dashboard, etc.) As Brad says, it can be a prototypes/sketch/doodle/palydoh, etc. What form it takes is largely dependent on who its audience is and what its purpose it. If you are a solo designer on a project that will be built by a remote team and you are only going to be involved at the beginning of the project you will need to deliver something that will allow that team to execute your design without you being around. If you are part of an in-house team embedded with your developers, stakeholders, and other roles all you need to deliver is the proper guidance to ensure the designs implemented. That could be a conversation, a sketch, or an Omnigraffle diagram (yes.. it can be even better than a sketch sometimes.)nnIf we understand our responsibility as being the one to create and communicate our designs in a particular context then sometimes we will have to do those disgusting specs (ugh) and other times we will be lucky enough to work with only pen and paper. The key is knowing when we have to do what, or positioning ourselves to only do what we like.nnAs far as wireframe monkeys goes, I think the term is a misnomer. What’s missing from the life of a wireframe monkey is that creative input or ownership of the design. It’s conceivable that there could be a sketch monkey.. someone who diagrams the spoken output of some super senior designer who only likes to talk. That would probably be as unsatisfying as the guy who spends all day translating someone else’s ideas into an Illustrator doc.nnI think there is definitely something to the idea of having junior designers do some of the “grunt” work, assuming you have the team and are in the situation for such a thing. But I hesitate to back that if it’s only so the more senior designers don’t have to get their hands dirty any more. The analogy I always go back to is the executive chef and the sous chef. If you’re the executive chef an a large kitchen you may have guys under you who will chop the onions and sautu00e9 the greens but if you’re running your own kitchen or doing really innovative things in there you will have to chop those onions, despite the tears it causes. Of course we all want to be the executive chef, but somebody’s gotta chop them damn onions.

    Reply
  4. livebysatellite
    livebysatellite at |

    The large organization that needs specification-level documentation wireframes basically birthed the ‘wireframe monkey’ and sullied the power of wireframing for the purpose of ideation and problem solving.nnSo the value of wireframing depends on the context: thinking tool, something to illustrate a solution? Or specification documentation?nnIn the first situation – thinking tools – we should own them. They may not go beyond well annotated sketches, or they could be full Axure or Keynote or html prototypes, but they are used to think through, and share framework/IA/IxD solutions, ideally collaboratively.nnIn the second situation – specs – it may make sense to outsource them, as you say. As other design specialties have an Art Director/Designer hierarchy, so could we – if the organization was large enough to supported it. For example, in a large ecomm company, a ‘lower level’ designer would do the wires that acted as specs, and this designer could be ‘art directed’ by a UX Lead type that had designed the framework and components (or at least the strategy and concept). nnFor consulting, it can be trickier, because you could have a small client, that won’t need loads of documentation, so wireframes to show frameworks, and IA and IxD solutions (perhaps key pages or key states) will likely suffice. But you may also work for a large organization, who will look for detailed wireframes as a requirements capture for an IT team. Fully detailed to capture every state in every user scenario. The role of the wireframe will need to be framed in the project scoping (if not earlier). And if you can afford to charge the client for it, you could potentially bring on a junior level practitioner to help and cover the detailed specs.nnEither way, I often view wireframing through those two lenses, so their value depends on which lens.nnn

    Reply
    1. Lis Hubert
      Lis Hubert at |

      Totally agree Chris!nnWhen I say wireframe I do mean the more spec like, however I’m even offloading any “formal” wireframing as much as possible. Why do I even need Omnigraffle if I can sketch it on paper and send it over right? So, thinking like a consultant I’m wondering if a client insists on wireframes why wouldn’t i just do all my Ideation then send the documenting of that to a third party who is cheaper. Meanwhile I can work on other ideation and overview of the documentation at the same time.

      Reply
  5. John Labriola
    John Labriola at |

    I have to agree with Brad here. nWireframes are never the only deliverable I show I like to show a progression of how I got there. Depending on the project and audience you have a whole toolbox of deliverables you can use. It also makes it easier to sell the final design solution. They were with you on the journey.nnI definitely agree no one should be a wireframe monkey. If that begins to happen you need to find out why. I never encountered a situation where that couldn’t be addressed.

    Reply
    1. Lis Hubert
      Lis Hubert at |

      But did you need to be the one doing the wireframe? Or could you have directed someone else to do it?

      Reply
  6. Brad Nunnally
    Brad Nunnally at |

    My two cents.nnYou’re jumping to conclusion. UX can’t become an industry of big ideas with nothing to show for it. Things like wireframes, or prototypes/sketches/doodles/playdoh, are all avenues in which we can SHOW our work. nnI just had this conversation with my sister last night thinking back to math classes from high school where I would get in trouble for never showing my work. Yeah sure I’d always have the right answer, but I couldn’t PROVE that I understand the system in which I was working in. I couldn’t show that I could follow the proper steps to get to a correct outcome.nnSo going along with that metaphor, maybe we need to think of our deliverables as those the proof behind the pudding.

    Reply
    1. Lis Hubert
      Lis Hubert at |

      I like where you are going with this. Do you think that by going this route, that aspects of the deliverable would change?

      Reply
      1. Brad Nunnally
        Brad Nunnally at |

        Yeah, because they become more collaborative in nature. Well maybe.nnSo the way I try to work is when tackling a design problem, its a group effort. The TEAM thinks through the sketches and what have you, until we come to an agreed upon conclusion. Then I may go off and crank out the work product. Sure I created the final deliverable, but the actual WORK was owned by the team. nnSo that’s the lens I use when I think about deliverables, regardless of the form that they take. nnA more interesting question would be, should wireframes be the responsibility of junior uxers? So the senior and leads drive the design process, with the junior adding their input when they feel brave enough. (Lets be honest, when we were junior it took a lot of guts to add to the conversation.) And once the design conversation is done, and the sketches are done, the junior goes off and makes the wireframe. Umm…that’s interesting.

        Reply
        1. Lis Hubert
          Lis Hubert at |

          Yes, this is awesome stuff! Iiiiiiii like it!

          Reply
        2. Mark
          Mark at |

          I’m a junior uxer. And the only uxer in a company. I’ve been brave enough to start doing user testing of either live working software or paper prototypes that I prepared (quite complexed). But I was learning. And our CEO knew that. That’s why he didn’t treat me serious while I was deadly serious. I managed to perform about 5 user testing sessions and even recruit people for that and fight for funds! That may be funny for you, but for me it was quite a challenge. Today I’m looking for a job because I’m tired of being under-rated. I’ve been UX Specialist for 2 years now and I’m fed up with this company. It just didn’t make sense to perform all those tests and so on. New functionalities were just passing me by because they had to be ready “now!” and without further delays. I know I moan, but… I believe I know why you Lis are concerned about wireframing. Maybe I should go back to programming where everybody knew what and why I was doing!

          Reply
          1. Brad Nunnally
            Brad Nunnally at |

            Keep the faith Mark. You are in a situation that many other UXers are in. If you want to try to stick it out with your current company, I recommend a google search on “UX Team of One.” There is a lot of great info out that on that topic, including an upcoming book in the next year or so. nnThat said, their is a huge demand for UX talent out there. The demand is way larger than the talent pool. If you want to pursue a career in UX, find one of the many companies that are hiring. nnBest of luck!

Leave a Reply

twenty − 6 =