I’ve been mulling this one over in my head for sometime. We all know that we, as a profession, are in this state where the Wireframe defines us to outside communities. When we interview for jobs we are asked about our wireframing skills. When businesses talk about us they say “and you’ll do the wireframes”. This has been an ongoing problem in our world, and it is one that I see coming to a head.
Of course the big problem with this view point is that we are SO MUCH more than wireframes. We know that, and we also know that what goes into creating a wireframe is so much more than mere drawing skills. But outside of the UX kingdom, our message is not being heard. Instead the message that we are the Wireframe is becoming ever stronger to companies thinking about budgeted projects and setting dollars to project activities. I believe that we are slowly but surely either being folded into the low paying wireframe only business, or that we are being pushed out of it completely, in lieu of more low budget staff.
I think there are a couple of ways to approach this. First we could just all start outsourcing wireframes. I ask you, what would this mean to the UX community? How would this work out for us in positive way, if at all? Another option is that we hold on to the wireframe more tightly and let it take over our entire being, something that I doubt many of us wants.
Therefore, I’m raising the question. Is the wireframe process outsource-able, and should it be outsourced in order to rid UX of the term wireframer (gah I hate that one)? Is it time that we started looking at and dissecting our profession, as other businesses do for us, and shave off the shaveable parts? Can the process even be outsourced? What would the outcome be of this process? Maybe it would just harm the profession overall?
From my point of view I would say Yes this work should absolutely be outsourced in some way, but I’m wondering if I’m jumping to conclusions. So, I’m looking to you, the UX community to tell me what you think… and don’t hold back.
[…] user experience professionals, a wireframe monkey merely churns out rapid prototypes rather than performing ideation and problem solving. Yet another […]
Let the UX specialist do the Story, Screenplay and Direction and leave the shooting part to the cinematographer!
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.
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
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.
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.
But did you need to be the one doing the wireframe? Or could you have directed someone else to do it?
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.
I like where you are going with this. Do you think that by going this route, that aspects of the deliverable would change?
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.
Yes, this is awesome stuff! Iiiiiiii like it!
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!
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!