As an app developer, we work in that strange and wonderful space between hard logic and imagination. And as with any space where you have intelligent, autonomous, and often strong-willed, individuals working together, we experience our fair share of differences in opinion. In this article, we share how we manage our internal disputes, to find good, workable solutions, and make sure everyone still gets along at the end of the process. Some of these will be applicable to any startup (or in fact, any small organisation with loose power structures), but the examples we’ll use are particularly relevant to app design.
1. Assume everyone has good intentions
This should be your philosophical point of departure when dealing with any potential dispute. Remember that there is never a good time for problems — you’ll always be busy on something, and any problem will feel like a distraction. But realise that no one wants to bother you with trivialities. If something is being brought to your attention, it probably means you’re integral to the solution, or at the very least, the person thinks you can point them in the direction of the solution. So, before you tackle any problem (or shoot the messenger), remember: you’re all on the same team.
2.Pick the right time for discussions
f Point 1 is the baseline emotional requirement for solving any disputes, this is the baseline practical requirement. Check in with people first thing in the morning to see if any issues have cropped up the day before. If an issue can be addressed quickly, resolve it then. If more complex discussions are required, schedule this for later in the day. This way, quick problems are dealt with immediately, and complex problems are given the attention they deserve.
3. Discourage stubbornness
Collectively, you’ll make the best decision based on all the available data you have at that stage. However, if a decision doesn’t turn out for the best, know that it’s not eternal, and can be relooked. Maybe not immediately, and it may take time to fix, but most things are reversible. That’s why no one has to stubbornly stick to their guns. If everyone on the team knows that when a solution they don’t agree with is adopted, but they can make themselves heard at a later stage, disagreements become less intense.
On a side note, if a decision turns out to be irreversible, you should spend as much time as necessary hammering out a solution (bearing points 1 and 2 in mind).
4. Figure out what can be objectively evaluated and what can’t
Some things can be assessed using solid data e.g. how many users do we have on our platform, but others can’t e.g. which design option should we adopt? For the former, we use the ‘best solution’ technique, and for the latter the ‘most convincing argument’. We’ll discuss these below.
5. Find the best objective solution
We like as many people as possible to propose as many ideas as possible. We don’t restrict opinions to speciality either. A copywriter is as welcome to suggest a layout solution as a designer. And a designer is just as welcome to give marketing input as our marketing expert. However, we do defer to the specialist in the field when it comes down to picking the winning solution. So, we spitball as many ideas as we can, and then whittle them down to the best solution. For us, the best solution is the one that satisfies the most of these:
5.1) Supported by external data — We’re diligent about sourcing as much independent and diverse data as possible on a subject, and then making a call based on the information out there.
5.2) Supported by internal specialist opinion — We have experts and professionals in the team who are bringing their years of experience and knowledge to the solution. What they say counts for something.
5.3) Gives best user experience — If something can be made easier, quicker, or clearer for a user, this is the preferred route. You can gauge user-friendliness (and we often do) through random testing, or focus groups. We’re also very aware that IOS and Android users have very different behaviour patterns, so the best solution is one that can cater to both populations.
5.4) Can be done quickly and responsively — A solution might sound great, but require time and resources which the average startup can’t afford. Keep lofty ambitions on a back burner. You can get to them in time.
5.5) Easy to maintain — How much regular maintenance will this new product/feature/service require? How quickly can we fix bugs? It’s important to take a long-term view of the problem.
5.6) Minimal third party involvement — Occasionally, we’ll roll out a feature that’s dependent on the service or architecture of a third party. We’ll test the waters with a third party if we need to get something done fast, but if we have time, or have been burnt before, we try to minimise our dependence on external players.
5.7) Fits best with our current philosophy — Kalido is a platform based on trust and mutual respect. So, when we were choosing whether to prioritise user matches based on distance, or mutual connections, we chose the latter.
If two competing solutions score equally on all of the above (which doesn’t happen very often), we’ll see if one of our founder’s has a strong preference for one. Only if objectivity fails us, do we resort to this, and we try not to rely on this method too much, as we believe team problem solving brings insights that unilateral decision making doesn’t.
6. Find the most convincing argument
Some things are a matter of taste and personal preference. In fact, most creative things are, which means there’s no obvious right or wrong. When we’re faced with these situations, we’ll go with the most convincing argument.
‘Convincing’ in this case usually means majority view. Particularly for UX issues, it’s important to know how most people think, or would react, so you can accommodate the majority of users. Using our own team as a litmus test, if more people choose A over B, it’s a good indicator that A is the more viable option.
7. Never leave an issue unresolved
When you’re discussing something, discuss it until you’ve reached a resolution. The last thing you want is to have open issues floating around. These will most likely be forgotten or ignored until it becomes a much larger critical issue.
The only exception to this rule is when extra data (or just breathing room) is needed. Then we let people go and do their research (or take a few minutes or hours to compose themselves) before we look at the issue again.
Whatever the dispute, and whenever it arises, it’s in your best interest to find a practical, cost-effective solution. But doing so at the risk of civil war in your organisation is shortsighted. So, remember that when handling disputes, you always have 2 goals: finding a good solution, and doing it peacefully.