Working With Clients – What Could Go Wrong?

Even amongst teams, communication breakdowns will cause major issues during development of any project. For our third project this trimester, we are creating a music-video-game, where an Audio student is envisioning and leading a project which we will create. This project is an interesting twist given that as game developers we are normally the clients of other disciplines. Working under Audio team members continues to be an interesting and valuable learning experience, since a lot of my communication issues working with others are reflected back at us. For example, Audio students don’t know the gamedev language that we use – so how do you compensate? How do you explain and guide the client through the development process without them feeling out of their depth? Communication in all disciplines is paramount – so how do you make sure you do it right?For the most part, our collaboration experience has been very positive. Our client is patient and understanding, and has allowed us the time and space we need to create their project. There are always risks associated with collaborators, applicable to every client. To make things easier, we’ve done the following:

1. Document your Design

Documentation is really important for your team first the foremost, but secondary to that is making it readable to your client. As the touchstone for your design by all involved parties, creating a comprehensive GDD where the Client can observe all of the aspects of their vision will reinforce their confidence in you and your project. Nothing feels better in group projects than knowing that you’re speaking plain English. To improve the readability of your documentation, include diagrams and reference imagery to visualise the more abstract aspects of your design. Keep it organised with a Table of Contents, and be careful and deliberate with your wording.

Our documentation is readily available to our client, and they are able to leave comments and feedback as we edit it. From the conception of the HCD, the product has undergone changes, all of which are reflected in the GDD. If the described product in the GDD isn’t what the client wants, they can easily reach out to us.

2. Tell Them About Your Progress

Clients probably don’t know how to read commit messages in BitBucket, or how to interpret your project management systems in Trello or Hack’n’Plan. That means you have to tell them your progress as you g0. They only need to know the really important visual things. So it’s good to send screenshots/gifs/videos where possible to show your major milestones coming together outside of meetings.

Additionally, during problem ideation sessions, letting them know all of the problems associated with their design can be a really helpful for both of you to work towards design solutions. For example – how can you guarantee that players will understand the purpose of your product? It’s an open ended question with unlimited solutions. Chiselling those out of your initial design will create a more robust end product, and create a better understanding of the product between you and your client.

We try to keep a very open channel of communication with our client. We try to answer questions right away, and ask if they have any after and during a meeting. After our problem ideation session, I informed our client on the results, and how we can improve. As a result, we kept the client in the loop and our product is stronger as a result. I also try to use plain English when discussing changes to the client, so they can understand. It is hard to avoid gushing about your custom particle effect, though… :/

3. Meetings

Meetings are a really valuable opportunity to eliminate all misunderstandings right away. If there’s even a slight chance your client or teammate won’t understand what you’re saying if it’s said over text, then it should probably be said during a meeting. You should always aim to keep a continuous flow of feedback, questions and information.

Our meetings with our client are good and productive, and there’s always something to show off and something to clear up, there’s never a dull moment. But not all meetings are created equal. According to Drake Baer of businessinsider.com.au, to prevent our meetings being ineffective, we should avoid the following:

  • having too many meetings too frequently
    • You won’t have a productive meeting if you have hardly anything to talk about. Once a week works for us.
  • Nobody leading and facilitates the meeting
    • Someone has to bring the discussion back from tangents and structure the flow of the meeting to solve the right issues.
  • Not setting any rules
    • Every meeting needs rules that facilitate a productive flow of conversation. Marlene K. Rebori suggests that you separate people from their problems, respect everyone’s viewpoints, and share responsibility for the ground rules.
  • The expert isn’t the one giving input in their discipline
    • The University of Utah uncovered that some people have a difficult time distinguishing from the expert from the loudest person in the room. Often they will distinguish these characteristics from the person’s noise level and boisterousness instead of the content of their input.
  • Breaking down your meeting by time, not tasks
    • Meetings aren’t about hitting a ‘personal best’, they’re about clearing up the lingering issues from previously in development. Don’t aim for time, aim for results
  • Being late
    • Nobody likes starting things late. Your productivity may suffer if everyone’s upset that you’re late, and you’re not feeling confident lending your input when the meeting does begin.
  • Being in a bad mood
    • A bad mood won’t help anyone. Bringing your bad mood into a meeting with stifle your productivity and might even spread to your colleagues. Leave it at the door.
  • Inviting more people than can be fed with two pizzas (credit to Jeff Bezos)
    • I learned this the hard way. Ordering pizza for half a class takes an hour, but ordering for yourself and someone else takes 2 minutes. Decisions are quicker when only the people needing to enact the decision are present.
    • While we’re here, don’t eat during meetings. It’s gross and disruptive, plus unprofessional. Stay away from garlic as well. 🤢
  • No clear agenda
    • IF you have a list of topics that can’t be sorted out via email, then you need a meeting. Do us a favour, don’t organise a meeting for menial tasks, it’s a massive waste of time.
  • Being distracted
    • Have you ever felt a conversation lose its momentum because you checked your phone? It’s the same with meetings. Alerts distract everybody (and everybody is guaranteed to check their phone, too) and it ultimately takes your focus from the task a hand.

Thankfully, we’ve stuck to all of these principles, and had meetings that are efficient and successful.

As I mentioned above, questions are super important, especially for clients who don’t share your discipline. The only stupid questions are the ones you’re too embarrassed to ask. I try to help everyone to feel safe and confident in clearing up uncertain details or misunderstandings. If nobody clears anything up, you may end up presenting the wrong product.

Our client is great and easy to work with, but that doesn’t diminish the risks inherent in collaborative work. By maintain effective communication channels, documentation and meeting methodology, I can ensure our product is the best it can possibly be.

References

Baer, D. (2014). These 12 Meeting Mistakes Cost Companies $37 Billion A Year In Lost Productivity. Business Insider Australia. Retrieved 10 March 2017, from https://www.businessinsider.com.au/common-meeting-mistakes-2014-11

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s