Alexa, Teresa and I recently finished a project that, from the beginning, had all the signs of trouble: a busy client team working weekends on other projects, an aggressive schedule, a tight budget and my own pre-planned vacation during the critical architecture phase. While this project had a lot of challenges, and was quite intense at times, we had fun and came up with some really well executed designs that we all love. The project ended with a very satisfied client team, too.
I was happily surprised when our client made a point of commending my team for our client management skills. At first I politely tried to diminish our part in making it such a great experience “Well you’re a great client!” and “That’s why you hire outside consultants!”, but he pursued his point by illustrating how his other vendors’ relationships hadn’t been handled the same way and more importantly, what we did right. His feedback seemed worth sharing; here’s a bit of a summary:
- We rethought the design problem rather than simply executing their requirements. We took their ideas and vision into consideration and then took a step back and rethought the problem. The result was a refreshing and unexpected approach that they liked much better than their own initial ideas.
- We scoped the project according to the budget and timeline allowed. The client needed a lot of work done in a short amount of time. So much work that there was no way it could all be done in the time allotted. The approach we took was to work closely with the client engineers and UX team to reveal only the essential design elements needed. We delivered only primary screens, a few key scenarios and prototyped interactions that needed more clarification. We also delivered design principles to enable the client team to stay focused on what’s important once we’re no longer there. What we didn’t do, which they appreciated, was deliver a big, fat document of every permutation possible. Instead we delivered high-level design guidelines.
The Team’s Approach — There were a number of client relations techniques we used in making the project a success. Here are just a few:
Trust — We kept our eye on building and maintaining trust with the client throughout the project. We did this initially with a full day hands-on workshop that included key members from the Product Management, Engineering and UX teams. This built rapport, inclusion and unified our vision of the product and our goals for the project. We maintained the trust through frequent review periods and showing our thinking along the way (even half-baked ideas were shared).
Listening — We listened to the client’s ideas and vision, but didn’t limit our designs to how they thought that vision should be executed. We took their vision and added in our understanding of user needs, consumer behavior and context of use as the launching point for our designs.
Setting Expectations — We had an extremely aggressive schedule for this project. We set a schedule with reviews and milestone deliverables, but we communicated heavily on the idea that “things may change” and we would “see what we can get done by x date”. This prepared the client for when we delivered sketches and rough ideas instead of polished designs.
Flexibility — When the client called and asked for a redesign a few days before our last big deliverable, I didn’t let it phase me. I welcomed his need to get the designs right. I didn’t even mention the impact to the schedule/scope, I focused on simply listening to his needs. What was missing in the current designs? We immediately set a face-to-face meeting with the client and his Director to better understand their concerns. It was a hands-on design session, where we sketched through ideas on the markerboard. After that meeting, we talked about schedule impact. The question I asked was if we could slip the schedule and if not, where would we need to cut scope?
Under-promise, Over-deliver — This is a technique I try to employ with all of my projects if I can. Of course my clients reading this will now know, but hopefully they won’t hold it against me! I try to scope a project that is realistic in what my team is capable of in the time allotted, but I pad in a little time for unplanned client meetings, idea gestation periods, wait time and general unknowns. In most cases, that padding time gets used up by unforeseen circumstances, but that’s OK because we don’t go over the budget or beyond the schedule. Sometimes there are extra hours to which I try to over deliver: more screens, more scenarios, more concepts, more interaction explorations, more annotations - what ever might be needed to wow the client.
Since the schedule was so aggressive with this project, I was honest with the client and explained that I wasn’t sure how much we could deliver, but I promised a minimum amount (which was safely low). Not surprisingly, he figured out this technique mid-project and luckily he saw the value in it and we had a good laugh about it. He appreciated how flexible we were throughout the project and the only reason we were able to be so flexible was because of the extra hours I had included.
Desire for Success — Philosophically we all have to remember that everyone involved in a project truly has the best interest of the project at hand. They may not be approaching the project in the way we’d like, or they may have bad ideas, but their intentions are for a successful project. Rarely do clients or colleagues knowingly and willfully undermine a project. We need to always remember that their intentions are good.
Last but certainly not least is in how to be a good client. Dan Saffer composed a great essay on how to be a good client, but I thought I’d share a few specific traits our client possessed that enabled us to take the approach we did. These traits allowed us to deliver the best possible designs:
- We had a client who set a vision and was open to the possibilities of where that vision might be taken.
- The client gave us access to all the right people. Their program manager did an astounding job of getting the right people in the room with us each and every time.
- They also had a system for decisions by proxy. If a decision maker was unable to attend, they identified a proxy who would speak on the behalf of the decision maker.
- The UX, Engineering, and Product Management teams all have a deep respect and regard for one another. Yes they disagreed (lots of heated debates!), but they did so respectfully and with humor.
- They leveraged our time together as efficiently as possible. Issues that didn’t pertain directly to our design problem were tabled for later discussions (without us).
I’m heading to Europe for three weeks for 2 must-attend conferences! The first is 
I head over to Malmö, Sweden the 2nd week of June for 
Entries(RSS)