Entering a design project mid-stream? Sometimes, you just paddle.
Design work isn’t always glorious. Recently I had the good fortune of being tossed into the middle of a project that had been going on for quite some time. Much of the “designerly” work was finished, and the team had already switched into production mode. They handed me a stack of wireframes and asked me to expand them in some modest directions.
“Great! Can do!” I said.
And then I stared at them, paralyzed, for an hour.
“I do this all the time!” I kept thinking. “Why can’t I figure out what to do with this?”
I began to realize that the reason I didn’t know what to do with the wireframes was because I didn’t know anything about the context in which I was supposed to work. This, despite the fact that the project room was covered in sketches, concepts, Post-It notes, and all sorts of artifacts from the design process. “Why don’t these things mean anything to me?” I wondered.
Design is thinking through doing.
As designers, we think through doing. Design is a reflective practice between the designer and her design materials. When you sketch something and commit it to paper, it moves from being an abstract thought to something that is more concrete and real. Perceiving this concreteness, in turn, influences your thinking, leading to new questions that spawn new ideas. It is this reflective conversation, between a designer and the medium in which she designs, that is central to the design process.
It is the act of creating these design artifacts, rather than the artifacts themselves, that is the most valuable aspect of the design process. These artifacts are the physical manifestations of our thinking. This externalization of thought, this act of making tangible these abstract ideas, is the core of what we do as designers.
And this is why it is so difficult when we find ourselves diving into the middle of a project.
We are surrounded by artifacts of the design process that preceded us, poster boards covered in Post-It notes, sketches of potential layouts, but since we were not actively engaged in their creation, none of it means anything to us. Viewing these artifacts does not grant us the same knowledge as having created them.
If you didn’t do the doing, how do you do the thinking?
The challenge I have been faced with lately is getting rapidly up to speed on a project where most of these design activities have been conducted, and the designers are already engaged in production. They have a rich and meaningful understanding of the project which I currently lack, and yet I need to help wherever I can in producing deliverables. Having not participated in most of the design process, it is difficult to orient myself towards solutions that would be contextually appropriate for this particular project.
All is not lost, however! I have discovered a few valuable survival tips along the way that have proved indispensable in getting up to speed, and productive, when tossed into a design project mid-stream:
Ask questions. Especially dumb ones. - Not only will this help you nail the core principles of the project, the act of explaining it to you will help your fellow team members re-internalize these priorities. Plus, your fresh eyes might identify some tacit assumptions that have not yet been broken open.
When in doubt, sketch it out. - As a kinesthetic learner, I can’t simply look at a set of wireframes and know what’s going on. However, if I grab a Sharpie and spend a few seconds recreating the wireframes on paper, I will suddenly begin to understand them. The trick is to make this activity as absolutely lightweight as possible. No matter if the wireframes are in Fireworks, InDesign, Photoshop or OmniGraffle, I will still deconstruct them on paper. Through this activity I can eventually understand and internalize the other designer’s work well enough to interpret and extend their wireframes in the digital medium of choice.
Make it and talk through it. - You’ve done this before, so give yourself some credit. Don’t be afraid to draft up a proposed solution, present it to a veteran designer on the project, and talk through the reasons you did what you did. Together you may uncover some mistaken assumptions you held about your users, or some core business requirements you were missing. As a designer you already have some pretty good rationale for the decisions you make, and you simply need to adapt them to this particular project. Over time, you too will develop the same intuition that guides the other designers on your team.
Have you discovered any survival mechanisms for when you dive into the middle of a project? If so, please sound off in the comments!
There are 9 comments on this idea.
Dane, I liked your post. I just had a little to add.
I would say before asking the “dumb questions”, which I feel would need to be asked, we should add a step to familiarize yourself with the project. Every good design team will document their work and decisions; even 5 minutes of glancing through what they worked on will answer some of the ‘dumb questions’ as well as clarify answers that the team may give you. Of course, it is always best for the team to explain the project to the newcomer; I just feel it is equally important for the newcomer to have the initiative to ask for materials to review as well.
Hope you are doing well, Dane!
Hey Dane, thank you for the post.
I have been running into a similar situation: coming into a project, of which the structure is already built by the client and the developers are starting to chunk the parts and plan for production. I was suffering because I have to learn the new language of the project in a short time trying to make sense of the existing and enhance the workflow before it goes to the production phase. I resonate with the three survival tips you brought up! I don’t know if I have something concrete to contribute to the list, though. All I have to say is to live the project in every way and own it, so whatever it takes will help moving forward.
Hi,
thanks for your article!
I think asking questions is very important - and making sure that one talks to several people in the team. For me it is always helpful to get more than just one point of view, it makes it easier to understand, why the team came up with a specific workflow and the wireframes.
Thank you all for your comments!
I totally agree with you, Kathleen, that “dumb questions” should follow after a bit of familiarization with the project. If you don’t have at least some pre-existing orientation within the project, you risk being selfish in requesting answers to your questions… it’s the questions, and the answers to questions, that help everyone re-internalize the project that are most valuable.
Yuebo mentions the challenge of learning the “language of the project”, and I believe this is one of the most important things to clarify. If you’re working on a project for a website that sells snacks, for instance, a dumb (but important!) question would be, “What is a snack?” Addressing that question, and any follow-up questions, can help the team identify tacit assumptions that they have potentially held about the subject matter of the project.
You may know what “snacks” are in real life, sweet, salty, packaged, from a vending machine, eaten without utensils, etc… but it’s important to learn and really internalize what snacks mean in the context of this particular project. In the last few weeks we’ve been able to blow open a number of tacitly assumed ontologies, because I questioned them… bluntly at first, but those blunt questions eventually led to extremely detailed, nuanced conversations about the project, that helped all of us move forward.
It’s motivating to know about this. Thanks Dane! Happy Designing!
Really nice article.
I think the type of “paralysis” you experienced when coming cold to a set of design products also highlights the the value of working collaboratively with clients when designing, otherwise we end up presenting design products as cold artifacts, and asking them to unpick a thought process they have no insight into. The same goes for throwing things at developers and expecting them to just-do-it.
I am not an interaction designer, I mostly work on design strategy and research - but If I’m ever asked to help with a project that I didn’t help start I do what most people do - read everything I can, ask basic questions about the needs we’re trying to meet, why what we’ve done is a good way to meet those needs. If we know why we’re doing something, for whom hoe - and we can connect the dots between those things then we shouldn’t be too far off course.
This article - and the title of it especially - was very timely for me. I too was recently thrown into the middle of an existing project that is in the production phase, however this project really didn’t have much in the way of design at all. I was asked to investigate the design space, conduct user research, come up with insights, and design a solution - inside a product that already had set requirements and was being coded.
Even though my first instinct was to “jump ship”, I decided that I should “just paddle.” I did exactly what you did, and found it to be immensely helpful. For the first week my workspace was filled papers where I simply rewrote existing documentation in my own words.
But ultimately what helped me the most was to look at the situation as a set of design constraints, and challenge myself to find ways to contribute to the existing product. I think the key is to remember that not all designs get to be glorious and elicit “oohs and ahs” from the masses. Sometimes the best example of design work is when the designer can impact the product in a small way despite heavy development and process constraints.
Dane, excellent post. You know how the topic “making/doing is thinking” is dear to my heart.
I wanted to emphasize the importance of conferencing with your peers/veterans/team members. When new to the team, it always takes a while to adjust to the tempo and rhythm that comes with working with that particular set of people.
As much as design is challenging, working with your team can sometimes be even moreso. Without referencing and acknowledging the thoughts of the persons who came before you, it is that much more difficult to make your ideas, opinions, and judgments heard and accepted. And as you said, the act of talking through the design is another form of doing, which brings clarity.
Any method of engaging in the project will be helpful because it is in the act and application that we learn.
Unrelated: it sounds like you’re having a blast at AP, I’m really glad for you!
[...] more consumer value by providing half finished products – “The IKEA effect”. Some thoughts on how to graciously enter a creative project that’s already halfway through. A good book summary and review of Roger Martin’s The design of Business (2009). Three basic [...]
Add to the conversation.
Commenting is not available in this channel entry.