If I could add a superpower to my web design skill-set, it wouldn’t be perma-inspiration or psychokinetic coding, but the ability to Vulcan mind meld clients.
One constant I’ve experienced over the years is that it isn’t a particular technology or design style that determines the success of a project, but how well the collaborators—clients, web designers and developers—understand each other.
Collaborators project small parts of themselves and their talents (business knowledge, user experience, front-end code, personal opinion) onto a common, virtual workspace. Throughout the process, these projections take shape and manifest themselves in a web browser. The clearer these projections are, the better the work will be. In other words, by seeking to understand each other (and to clearly explain ourselves) we begin to define the constraints, objectives, and working relationships that lend purpose to what we build together.
Obviously, the more time that teams dedicate to this aspect of the process the better they’ll collaborate. Whether it’s a co-founder, full-time, part-time, or contracting working relationship, dedicating time to discovery, planning, and morale is key—how that time is spent is just as important as the amount of time.
Discovery should be fun.
As web designers we need to know more about our clients than what typically fits in a brochure. So, if you get a .zip folder full of outdated tri-folds and TPS reports, ask for more. After all, no one really wants to build for a business he’s not excited about. And because it’s a two-way street, why not tip the scales of equal disclosure in your favor and start by telling your client about yourself or your team. Swapping backstories, working styles, values, and talents builds trust and sets the team up to become effective consultants. This can be conducted in whichever way works best for you. Make a webpage, video, pdf, or simply get on the phone.
In doing so, keep in mind that sparse or inaccessible discovery content can be just as unhelpful as the excessively wordy or over produced. To me, brand deck presentations with lens flare transitions, unsubstantiated info-graphics, and words like synergy, leverage, and the cloud are smoke and mirrors. If teams are going to work well together they’ve got to get real right off the bat. Be yourself and tell it like it is. What are the problems with the business or website currently? What aspects of either underperform? What are the stakes and criteria for evaluating success?
Show & Tell Listen
Early in the planning process at Paravel, we love to show sketches or rough wireframes. The goal isn’t to get something approved as much as it is to start a discussion. It’s a simple, tiny thing, but within this discussion much can be achieved. With sketches, everyone is going to be less invested (in every sense of the word) than with fully comped layouts or fully built prototypes—therefore, team members aren’t afraid to pick things apart. As they share & debate ideas, the collaborative working relationship is established.
It’s amazing what you can learn by listening carefully to someone’s take on why something doesn’t work instead of cherry picking the things that do. Then, once a team agrees on where they are headed, they can start a dialogue about how best to get there, airing out specific differences in opinion and perception along the way.
Correspond Effectively
I spend a lot of time trading feedback & planning via email or basecamp. I try to consistently edit things down and carefully consider tone as much as possible. It’s a valuable part of the work because it shows respect for both the collaborator’s time and the clear communication of ideas. Because Each person is different, so much of the correspondence is nuanced in tone to suit each personality.
However, certain topics can be more straightforward. I have, for instance, written the same message about the difficulties of implementing video on the web properly at least 6 times this year. The same goes for explanations on why we set responsive breakpoints to content rather than to device, or how no design technique or UI enhancement will ever make up for bad content. I’ve noticed that both the content and quality of these responses are influenced by focus levels, schedules, ringing phones, etc.. Ideally, I’d be able to take all the best points from each message and edit them into one concise response.
I have therefore decided to start indexing these brief explanations with links to supporting articles so that I can A) save time by reusing them, and B) build an easily updatable Paravel knowledge base. I should emphasize that something like this is not an attempt to automate collaborative relationships, but rather to enhance them by freeing up time to focus on the personal & specific parts of discussion. Also, I feel like an ass when I link to my own blog. That said, I’ve got a few ideas for how I might go about this.
- I could create a group in TextExpander, populating it with snippet explanations paired to hotkeys for quick access.
- I could create a folder of Markdown files, one file for each topic.
- I could create a simple WordPress blog, hosted either locally or online, creating a post for each explanation topic. Each entry would be tagged for quicker access if the amount of information grows over time.
I love TextExpander, but think I’ll want more text-formatting & editing options than it can easily provide. I also love WordPress but don’t want to fiddle with a CMS to maintain this. So, the plan will be to go the Markdown route. It’ll make pasting things to Basecamp easy, and I can always beg Dave to build me a tagging system later with all the free time he’s got.
Avoid Feedback Loops
As important as fostering open discussion and collaboration are, I’ve found myself in situations where things may, perhaps, be too open. Momentum is important, so don’t be afraid to be decisive and assertive when a team has tried everything and needs to make a decision.
Smart Scheduling
I love to get projects on the schedule weeks before they need to kickoff with full team engagement. Typically, we’ll have spent some time on discovery and the proposal process, so the basic objectives will have started to take shape. Having some time to simmer on ideas, step away, and simmer some more can make all the difference. And if that’s not reason enough, get things scheduled ahead of time because ASAP sucks. No one likes hearing it. I’m not against being timely with deliverables, but as a rule, I don’t tell my team anything I wouldn’t tell my barber.
Morale is important.
Teams do their best work when they’re enjoying it. This is easy to understand, but hard to consistently put into practice. Under the weight of to-do lists, deadlines, and pressure to perform, the work still needs to be fun. Nishant Kothary is a master in this department. I’ve worked with him twice and don’t know if it’s all the animated gifs, enthusiasm, or the fact that he trusts and defends the team’s vision unconditionally, but the tone he set affected every aspect of the projects. Don’t be fooled—just because something isn’t a line item on an SOW doesn’t mean it isn’t integral to the success of a project.
Don’t over-engineer the process.
I swear, just when I’ve got my process finely-tuned, life throws a curve ball. Doing things for the love means that we’ve got to be willing to throw our process out the window from time to time.
So, perhaps doing the work isn’t enough, at least for me. How we work together affects the outcome just as much as any actionable to-do item. Every project is unique, from project deliverables and technical constraints to personality quirks and collaborator talents. Working to create the right environment for all those variables helps to ensure that they collectively go as far as they possibly can.