5 reasons why "can we just" should be banned in Digital Agencies

There’s a disease that plagues every digital agency, the sentences that push the assumption-o-meter into the red. “Can we just”, “it’s simple”, “it won’t take long” just to name a few. These sentences induce panic attacks for us developers, beads of ‘panic’ sweat engulf our heads as the words come tumbling from account managers’ mouths. So why are these phrases so damaging?

1. ‘Just’ implies simplicity

‘Just’ is my most hated word in work, and one I hear too often. ‘Just’ implies simplicity, simplicity comes at a cost. What is simple from a usability point for example, usually requires input from a UX team and then development.

‘Just’ implies simplicity, simplicity comes at a cost.

The input from UX means research, testing, user profiling, etc. The development cost is increased when the ‘simple’ functionality touches multiple technologies to implement.

WordPress example, reordering of posts in the admin post list

I was asked some time ago by an account manager “Ste can you estimate a task to make it so the client can drag and drop posts into the right order in the admin screen? It won’t take you long, it’s just straight forward”.

In this example, the AM is making assumptions. He is assuming the task is ‘simple’, ‘straightforward’ and without the technical background, ‘how hard can it be’? Let’s take a look at what we need to do to achieve this:

• Create an ajax endpoint that stores the new post order, and of course, we need to secure this with a nonce field.
• Write the javascript which allows dragging and dropping of elements in the dom to set the order, this will post back to the ajax endpoint to set the order.
• Wait! The endpoint has returned an error. We need the javascript to handle this
• Oh no, the post list is paginated, how do I handle this? “UX guys, I need your help”

The estimate is scrutinised, “why is it so expensive? It’s simple!”. After more expensive time wasting the estimate is approved, the reordering capability is written.

The AM then says “why can’t I reorder pages?”. Another assumption not communicated to the developers. See how this quickly becomes an issue?

2. Assumptions are expensive gremlins

Continuing our WordPress example, the assumption that the reordering will work on both posts and pages means we now need to make further code changes. We have a clear instruction, we specifically want to add the reordering capability to posts and pages. “What exactly was the client requirement?” I find myself asking. “They just want to reorder posts and maybe pages”. This leads me onto the last point.

3. Assumptions and unqualified solutions are sold into the client

The account manager has sold the solution to the client as being ‘quick’ and ‘simple’ to the client, they’ve bought into the idea, yet again I reiterate “it’s just reordering posts”, “how hard can it be?”. After all, we can “just install a reordering plugin”.

At this point, our solution has already gone over budget due to assumptions, the client is upset. We can’t use a plugin because one that exactly fits the requirement doesn’t exist or is poorly written. Who’s fault is it? Somehow invariably it’s the developer’s fault as they didn’t get clarification.

If you are a project manager or account manager, designer, stakeholder, whoever. Developers cannot be expected to ask about every single eventuality and edge case.

4. ‘Just’ and ‘simple’ devalue the skills required

Finally, all this assuming and solution engineering is damaging. It devalues the work and skills required to fulfil the client requirement. The endless battle and frustration are felt, and neither parties want to accept responsibility. This leads nicely onto the final point.

5. The cost of assumptions creates an unhealthy blame culture

The AM believes the fault lies with the developer for not asking about all the possible scenarios and edge cases. The developer blames the AM for failing to ask the client the right questions, for solution engineering and for making assumptions. How do we fix this?

Change the culture

I am going to use the word ‘simple’ here. It really is simple. Everyone in a team should know the limitations of their ability and experience. Solutions should not be sold to the client without the experts in their respective fields being consulted. Finally, understanding what exactly the client is trying to achieve by involving UX and developers in the requirement stage will help inform the task breakdown.

Do you have these same frustrations? How do you overcome them? Hit the comments below.