Working with clients is challenging. There are a few reasons for this, the most important ones being skill sets and communication. Before I go into detail about how to make the most of your client interactions let me first start by highlighting the different types of clients you can face.
In my personal experience/opinion there are 4 possible types of clients:
- A client that doesn’t know what they want
- A client that doesn’t know how to express what they want
- A client that doesn’t know what’s possible
- A client that wants everything
There are benefits to each type of client; in general having a client is better than not having one. But in terms of possible challenges, each type of client has its own.
Based on my experience and for the sake of time, for the rest of this post, I will be focusing on the third type of client, the non-technical client who doesn’t know how technology can be used to achieve their goal.
Some possible identifiers of this type of client include:
- They don’t know what can and can’t be done with the technology you are working with
- They don’t have clear opinions on mock-ups or visualisations you show them
- Point of caution, there is a difference between having a client that is indecisive, and a client that doesn’t know enough about what you are doing to form a concrete opinion
Based on my experience from my last Imago project a few challenges you might encounter are:
- For the first few weeks of your project, you/your team don’t fully understand the project specification
- This might be evident either by you developing something that the client later says they don’t like
- Or when discussing the project, the client starts mentioning things you didn’t realise were part of the specification
- The client or the development team bring up completely unrelated remarks, thus highlighting the gap in understanding
- The client realises after you have removed a feature that they wanted it in the final product
- Members in the team start having contrasting views on what the product description is or what features should be implemented
There are obviously more case-specific issues you may encounter but these are a few examples I encountered this summer.
To overcome or prevent these challenges I have come up with a small list of suggestions based on my experience:
- Having/fostering effective communication. This can be done by doing the following two things:
- Have a unified language:
- I cannot emphasise this enough: you need to be using the same language. You can’t be saying “UI” when they say “front end”, you can’t say “factors” when they say “causes”. The less that is lost in translation the better. This is because one small word change might mean the difference between a search engine or a search bar.
- Be approachable and friendly:
- Make a point (at least early on) that you are not emotionally attached to the code. The more feedback they give you the better. This is especially important when you are trying to understand the software specification. Your clients can’t be too scared of you to tell you that the current version isn’t remotely related to what they want.
- Have a unified language:
- Setting realistic expectations and clear goals:
- You don’t want to tell your client you can build them the next Amazon in a week. Be sure to be realistic about what is achievable so that the client continues to trust you. Even if this project is small, they might recommend you to someone they know, so don’t get rid of a good connection.
- Get them involved in the process, the more they understand the more they can help:
- This is especially important early on when you are trying to come up with the product/software specification. The clearer the requirements are the easier it will be for you to turn their idea into code.
- Meet regularly:
- As regularly as your development cycle allows, ideally frequently enough that you do not end up spending time developing something on an iteration they didn’t like in the first place.
- For this, I recommend using an Agile development strategy, because development and release cycles are quick so it’s easier to get more real-time feedback from a client. It’s always better to show a client a working prototype than a fancy wireframe.
- Get external opinions from your side and the clients’ side:
- When all else fails and you or the client aren’t sure how a user would interact with the software/product, get an unbiased third party who has never seen it or only knows a little about the project to beta test it.
- This can be especially helpful if your client has a very fixed view on an area of the software that you believe users won’t be able to grasp upon initial use.
It’s impossible to prevent all possible challenges that come with working with clients. However, the above recommendations should help mitigate them to an extent that they won’t have a big negative impact on the life cycle of the project.
Having the chance to work with clients is a great opportunity, so even though it comes with its challenges, it’s a great learning experience and allows you to broaden your skillset while showing your clients that things they never knew were possible can be done with technology.
Because of this, I would like to thank the research team at Alliance Manchester Business School, for giving the Imago team and I a great learning opportunity and for bearing with us as we figured out how to effectively work and communicate with clients. To learn more about the incredible research they have done about how to effectively move your operations online you can visit their web page.