"The customer is always right" - that is the creed of modern capitalism.
And indeed, if one goes to a restaurant to buy lunch, who else but the customer is qualified to choose the “right” product?
Not so with a client.
A client doesn’t expect to be 100% right.
Quoting the above article, customers buy on price and value whereas clients buy on experience and trust.
In the demanding and unforgiving world of professional software development this principle is particularly visible on every stage of the project. From an idea, through to establishing business needs and creating designs to developing a successful application, a client should be professionally advised and guided throughout the project for a mutually satisfying conclusion.
My colleagues have already described their take on UX research and its advantages - we also have some thoughts and insights on product design, feel free to check those out as well.
Done reading? Brilliant - how about we move on to how a programmer can contribute.
Get Involved Early
The client’s expectations are usually simple and straightforward - they want their solution good, fast and cheap. After they learn that they need to pick two of the above, negotiations occur and compromises are made until finally, an agreement is reached.
A specific set of features, created in accordance with specific standards, before a specified deadline, for a specified amount of money.
More often than not, a programmer is not involved in this early stage.
And that’s bad.
If a new, greenfield project is starting, get involved right away. If you are not invited, ask to join.
As a programmer, you are a stakeholder in the project. You are expected to take ownership of a significant part of it - yet what if some part of the project just doesn’t make sense from a technical point of view? Owning a broken feature isn’t fun. Especially if it could have been made right with a few chosen phrases, instead of a few hundred lines of code.
The Power of Insight
In the process of creating an application, every stage adds more misunderstandings:
UX designers misunderstand the client.
UI designers misunderstand UX designers
Programmers misunderstand all the above.
And PMs need to pretend to understand them all.
After all, some business requirements are so obvious for the client that they don’t even mention them. Well, if they are not mentioned, then designers will have no reason to design them. And that means the programmers will not implement them. And then comes customer testing and a real user gives the app a try to uncover the big, steaming pile of whoops.
However, the programmers have one thing going for them.
The number of spotted problems is a simple function of the spotter’s experience and time spent.
In most cases, the programming phase takes the longest. In order to do our job, programmers need to “go deep” into every feature, every view and every single icon on the most forgettable button. We spend a lot of time considering every diagram. Another thing programmers have going for them is the “think outside of the box” attitude. That, combined with the time spent, often leads to many “what if” moments.
What if the customer would like to use this app in a different way we haven’t planned for?
Is this visibly exposed feature something that the customer really needs most?
What if the customer’s 4 year old child gets hold of the phone? Are there some features we should prepare extra protection for in such cases?
You might get these insights from time to time and push them back, in favor of some fascinating technical problem you are now facing. Don’t. These “what ifs” can actually be worth more than an entire day of your work. In fact, asking them before implementing can actually save you from having to rewrite days’ worth of your fascinating code. It's happened to me :-)
Remember to ask your “what ifs”.
Ask Your Questions
What is the difference between a junior and senior programmer?
Junior programmers already have a lot of hard skills. They know modern programming languages, can list more frameworks than you would imagine existed and don’t need to waste many hours for luxuries such as sleep. Give a junior a programming task and often he/she will just ask one question - “When do you want it done?”. And right before the deadline you will get what you asked for.
A program.
Scalable? - “You didn’t ask for it.”
Test coverage? - “No time.”
Commented code? - “It’s self-explanatory”
You found bugs? - “Works for me”
I know I'm being unfair here to many junior programmers, who have a mix of soft and hard skills as well as the experience. Let’s just say the above is an exaggerated example of the proverbial junior’s work.
The lesson here is that an experienced programmer knows he needs to ask questions. A lot of questions. Not programming ones - StackOverflow has those covered. Business questions. Time questions. Budget questions.
Such as:
How important is this feature? Maybe we should move it to a less prominent position?
This Call to Action is not instinctive enough. Would you like me to emphasize it like this?
Who are your target customers? Are they tech-savvy? Do they have special needs?
How important is accessibility in this app?
What are the next planned features? How can we prepare this app for scaling?
And many, many more.
The Art of Compromise
The above paragraph covered some of the non-technical questions you might want to be asking. However, some constraints might force you to also revisit the more programming-oriented aspects of the application.
That would usually be the deadline.
For example, it’s common knowledge that applications should have test coverage. It is also common knowledge that many clients commissioning small applications are not exactly eager to pay for it. Frankly, for some small projects they may even be right.
From my personal experience, it seems that ensuring test coverage is a rule more honoured in the breach than in the observance. Do your best to convince the client about the benefits of keeping the application maintainable, but in the end, be ready to cut your losses as in an untested app there will be many more battles to be fought.
In general, in any project where the client is particularly concerned about saving money, prepare for a scenario when you have to cut some corners, or even features.
Plan ahead:
Talk with the PM and client about establishing an MVP.
Set priorities for the features outside of MVP.
Be aware (with a PM’s help) of your velocity, so that you know how likely meeting the deadline is.
Always add extra room in the plan for bugs, misunderstandings and the release process
When planning time to implement a feature - take your first estimate and add 50%
Internal vs External Customer
Let’s say your client commissions an application from you for their customers. As a programmer, you might believe that you don’t need to know or care who the customer is. After all, you got your diagrams from the UX and UI teams, who obviously did discuss everything with the client, got their work approved - your job is to start coding and not ask business questions, soldier! Isn’t it?
There is one specific situation where asking questions can lead to a huge benefit for the client, and, indirectly, your company. This is because there are two distinctive types of customers (or your client).
External customer - one you have to woo and charm into even opening your application and then strive even harder to keep hooked and spending.
Internal customer - one that you send a memo to saying “This is the application you will be using from now on”.
Different types of customers look at different aspects of the application. Achieving success with external customers requires appealing to their taste, outperforming your competition in their eyes and providing a useful service. For the internal customer, you must focus on utility - everything else is extra. Here is where an experienced programmer can make a huge difference.
"Different types of customers look at different aspects of the application"
The designers know and prepare for the business needs communicated by the client. They are professionals who know how to do their job. However, for better or worse, designers also have standards. They just won’t do a sloppy or unaesthetic design, much like a good programmer won’t write sloppy or ugly code. So if a view looks better with rounded edges, then it will have those rounded edges, come hell or high water.
You see the problem now - rounded edges, fancy composite icons, non-trivial animations… all these graphical fireworks, which take just a moment to create in Figma, can actually mean hours of programming and testing work. Work that does help to sway an undecided external customer, but will just be ignored by a HR professional using your app to arrange another batch of job interviews.
Not that an app for internal customers shouldn’t look good - after all, your client might want to brag a little before potential investors or actual competitors. However it's just not as important.
It’s not the designer’s job to know the programming cost of their designs. It's yours, as a programmer, to let them know that and come up with a solution together.
Provide Extra Value for Free
We do appreciate designers as professionals who uphold their aesthetic standards, but also try to keep the amount of required programming work within pre-accepted constraints. They try, as far as they can guesstimate it, naturally.
Sometimes they underestimate the cost of creating a rounded corner on a composite view - and sometimes something seemingly difficult is practically free. Especially due to the power of libraries.
For every programming feature in existence, there are at least 10 libraries promising it. Half of them obsolete, half unusable or incompatible, but that still leaves 2 or 3 for all but the most obscure functionalities. The thing with libraries is - they provide a lot of features. More than a designer (or programmer before getting to know it) is aware of.
That means that once you get the library to work with your codebase, you have at least a few features that you can provide to your client for little to no programming cost.
Remember to anticipate what the client might want to use from what you already have.
If you'd like to learn more or need an experienced team contact us today!
Ziemowit Pazderski
Android Developer
