Pairing for designers (Agile)
It's important to collaborate because it allows the team to become a powerful unit, full of common knowledge and questions. Each individual has a clear view of what is going on and has the power to affect the product direction and evolution. If as a designer you do not collaborate with the rest of the product team, you essentially deny yourself this right. By pairing with the QA, (front and back end) developers, BA, PM and anyone else who is part of your team, you gain all of the necessary perspectives on the project to really understand the product you are making. You should ideally always be working with another person and never alone. This allows the team to cut out a lot of time draining and uninspiring inter-team formal communication, and actually focus on the product.
More importantly, the design then belongs to the whole team, and is no longer treated like a sacred cow.
How to pair with a developer:
You will need a whiteboard and a few whiteboard pens, a shared screen and a mouse and keyboard between you. Use the whiteboard to communicate your design ideas, and work together on solving design problems that crop up and technical problems that you encounter as well. This way you are designing that is feasible technically, every single time. You don't have to have meetings about the design, where you show wireframes or photoshop files. You don't have to have talk about possibly trying this or that to get over a hurdle....you can just do it right now, together. Experience design needs to be user-centered but also technology centered. Weirdly enough, a lot of designers forget the latter. If you need you need to make something in photoshop to go into the design, then do it together and then make it into working code right away. Working this way is a LOT of fun and the product that you are making comes to life quickly. Your client will be super happy because you have made something tangible in record time, and you now have something that works to put in front of users. Yey!
It is tough though. Be prepared to sweat. As a designer you have to know your job well enough to do it on the fly with little preparation. You have to let go of perfectionism and aim for a minimum viable product that still fulfills your user needs. Remember that you will iterate. Better still, because you have a working product to put in front of users really quickly, you can include solid feedback in the next iteration and not make all those features that nobody ends up using.
Why you shouldn't code (even if you can):
The whole point of pairing is that you can share the load together, and bring a wealth of expertise and experience to the product. Imagine that you are designing a login screen. It's always useful to start with the action, so tell your programmer pair to make a login button. While s/he is focused on the button, and on the minutia, you are focused on how the entire design hangs together across the whole product...all the other screens that you know about, and all the design decisions that you are about to have to make. You are the big picture person and the other is the small picture person. If you are coding, you will pretty much only be focused on that button. While that button is being made, maybe you are drawing out the login interaction on the whiteboard and the next screen.
Where to start?
"Build what you can with what you know" is the slogan I like to use. It is tempting to want to get all of the information about everything up-front, but the reality is that by actually making something you put yourself in a better position. You can modify, start again or carry on the next day. Iterate. remember that there is never really such a thing as an "End product" because if it's any good, it evolves and there is no end. The more you think about it, the more the whole team thinks about it...the more it is misunderstood by the team. Everyone forms their own assumptions and ideas of what it is and how it works and what it looks like. It all becomes more like a field of dreams. Sometimes we even agree as a team, whilst all thinking we are agreeing to whatever we each have in our heads. Actually we are more confused than ever before. Keep it tangible. Make the product now and keep making it. When you talk about it, point to it. Everyone can see what it is, what colour it is, what shape it is and how it works. It couldn't be clearer. All of your focus should be on your product and not on your process. Show your work often to your client, and let them use what you have made so far. It makes for a better conversation than a meeting that refers you to wireframe 180(a).
But what if it's all wrong?
Throw it away and start again. You are throwing away some code, that's all. This is far preferable than the potentially huge cost of a design lead time (where developers are twiddling their thumbs waiting for you to come up with a design). You may have made some mistakes or maybe yes, t is all wrong, but by collaborating you now have shared experience as a team, you have learned to make something together, and you have probably alos won client trust because you have shown that you can make something that works in a morning rather than a week or month. Even if it is wrong, you have failed fast and learned something valuable from that experience. The team will be a lot closer. You will share your valuable design knowledge with team members and learn things from them as well. You all win. A lot is to be gained from jumping in and making something that is wrong rather than spending a lot of time making nothing, trying to fill in all those gaps (we talked about those in the last post). At the end of the day, you might find that you have pursued 3 different approaches and made all of them in the same time it would take to go away and wireframe everything meticulously on your own.
What if you have layers of management to get approval from before you can make anything?
Working in an Agile way requires the client to work closely with you, so that you can make decisions quickly. If your client is very removed from your project, then it will be hard to be Agile. You will have to make documentation that gets sent up the management chain for approval and this might take some time. In this case, you have fallen into a waterfall. Fear not though, this is fine. As a good BA friend of mine says: This is exactly the situation for which waterfall was designed for". If this is not the way you and your team want to work, then you need to have a chat.
How do you ensure that the product remains user-centered and ends up being right?
If you are in an Agile environment, you need to ensure that while you are making, you are also discovering and learning how best to evolve your work. The diagram below shows that you should be focusing all of your energies around the product. The further you are from actually doing code (making), the further you are from the center of the concentric circles. Tasks on the outer rim might include user interviews for example. That isn;t to say that these tasks are less important or devalued, they remain deeply and crucially important, because they give you direction and ensure you make the right thing. Anything in between the outer disc and the inner one are things that...we...fall in between. To ensure that you are not just blindly making or lost in a world of research and no making you should be working on tasks on the outer and on the inner discs simultaneously. The stuff you do in between is up to you. Additionally I split the whole thing into examine, define, create, verify. Most tasks will see a full revolution.
To finish: Cultivate Li:
Jade cracks along its natural contours, which adds to the artistry in working with it. Jade carvers incorporate the breaks into their work, bringing into evidence the natural elegance and great beauty of these lines. They are said to rely on the stone's natural "Li". Each and every project has its own "Li". Allow it to be there and learn to work to turn all of the challenges into something beautiful in the end. Take advantage of them. Drop the fear and the resistance, trust the integrity and capabilities of the team. It takes more than just your immense capacity to make logical decisions to succeed. You need to be invested fully so that you can trust your instincts, trust your heart and trust your gut. (More about "Li" in this excellent book: "Awake at work")