Here’s a checklist of what might happen when a client requests customisation of a product supposedly targeted at a generic audience:

  1. Big client (They are going to net us alot of money) – Check
  2. Are they willing to pay for this piece of work (Money, the more the merrier) – Check
  3. Can this be done in line with other priorities (Of course, it sounds simple enough) – Check

And bam, magically it gets done really quickly and there you have it. Done done. Not for SaaS products it isn’t. If you’re making money not through subscriptions and long term engagements, you better think twice, if not thrice. Here are some key considerations:

  1. Complexity cost -  It’s gonna come at a cost. It ain’t only upfront development cost, what about the knock on effect on testing, enhancements, support, user experience etc?
  2. Impact to product growth – When you need to change your product according to new learnings or market trends, will this hold you back? Will you not be able to move ahead when the client you’ve customised for said “No you cannot change this.”?
  3. Overhead – Will this cause the need of overhead processes just to manage and consider this piece of custom work in the product development process?
  4. Sunsetting cost – What happens when this client leaves? How much work will it be to sunset this piece of feature?

It’s not that it’s always a no to customising for such products, but make sure you’re aware of the cost before going full steam ahead. Your call.

Staying grounded

Product development is tough. Executing and navigating through countless roadblocks, uncertainties and distractions is never a piece of cake. So how on earth do you stay grounded and continue to ship value to your customers? To keep it short and sweet, here are 3 rules worth considering:

  1. Being informed – Being in an informed position based on any data you have will be priceless in enabling more certainty and confidence in making decisions. It’s fairly cost effective to test your assumptions so you have little excuse.
  2. Grounded with the deadline – Between scope, resourcing and deadlines, always plan with a deadline set in stone. Your prime candidate for the cut will be scope, most of the time. If the deadline is forever a moving goalpost, shipping will always be derailed.
  3. Aligns to vision – Will what be done today enable future growth or hinder it? Will it contribute to the vision of the company? This is where decisions like customising for specific customers or target markets might backfire and hold your product back from future expansion.

Just food for thought that will most likely be different in your context. More than happy to have a chat over it.


Getting your message across

After reading through what felt like millions of emails for the past month and inflicting the same pain on others, I had the sudden urge to compile some of my thoughts on writing emails.

“Write drunk, edit sober” – Ernest Hemingway

You have something to communicate. It’s important. You need to make sure you have black and white that it is communicated so you start typing an email. It could be a response to an urgent email or a sudden insight you want to get across. Thoughts start going through your head as you type and you spew everything that comes to mind. Within minutes you’ve conjured a gigantic block of text and you’re about to hit the send button.

STOP. Yes, stop right there.

You were just about to commit the sin of not getting your message across effectively. Here are some guidelines:

  1. Write only what people read.
  2. Less is more. Seriously.
  3. Make sure you have the right tone for your target audience.
  4. A short version might come in handy.

People will be thankful for the time you have saved for them. I’ve got to start reminding myself to do more of the same.

2013 in retrospective

2013 have been a hectic yet breezy roller-coaster year. Sounds conflicting but true. Looking back in retrospective, here are a few things I’ve learnt along the way:

  1. User research is crazy, especially when it unearths insights that are either transformative or downright scary.
  2. Innovation happens when we start by understanding what is the problem, how others are dealing with it…and how we can do differently.
  3. UX doesn’t drive product strategy, it influences it.
  4. A great product can only be achieved through concerted and aligned execution of a vision across multiple departments. UX is just a piece of the puzzle.
  5. Healthy compromises are crucial to enable a balance between scope, resourcing and deadlines. 

Happy new year!

Workshop: Rapid fire ideation & design process

Just conducted a 2 hour workshop for college students participating for an Android App Competition, I was asked to talk about design, but rather than talking about UI and visual design, I opted to get them thinking about the actual stuff that happens before that. This kind of works like firming up some minimal design in sprint zero of some agile processes.

It was a fairly interactive workshop, where people were broken into teams of 6-7 people each (maximum size for agile teams) and given the challenge of creating an app to replace a TV remote. We then went through the following areas:

  1. Creating personas
  2. Scoping and prioritisation
  3. Sketching concepts & wireframes
  4. Testing it with peers, discerning feedback, meaningful critiques.

Building UX Teams #2 – Setting up your design process

A long, long time ago, I’ve used to believe that the fastest way to get things done is to jump right in and get things moving. Need a new control? Just whip up the code to make it happen. Need a new feature? Start sketching, wireframing and photoshoping it pronto.

That works fine….to a certain extent. It starts stuttering when there is need to scale. What if we need to make it work across multiple products, projects and teams? Going with the “just do it” mentality just wouldn’t cut it anymore. Add to the fact that there is always uncertainty on whether what we roll out would work or not for existing users.

What we need is a design process that enables visibility, more predictability and governance on the outcomes of the design team,a streamlined way of working with the overall product team and allows us to consistently meet user needs.


Over here, I’m just sharing what we do here at Ezypay and iconnect360. After trialing various methodologies, we’ve settled with a process that takes bits from Lean UX, Agile Scrum and Lean Startup that works for us and have it implemented in our design process.

The design process


For every feature that is prioritised, it will first flow through the design process where we firm up business requirements, get user research and competitor research done if necessary, and then continuously iterate based on internal feedback and external tests (We find guerilla user testing to be highly effective) while moving through the stages of concepts, prototyping and documenting specifications.

There are some features where we’re more certain of how it should work, for these, we would skip research or external testing and go ahead with them.

Roles involved in the design process

It’s also crucial to firm up just what, when and why different roles are involved to optimise everyone’s time. This is how it works in our context:

  1. UX Designers or Business Analysts – Does everything from working with stakeholders & product owners/managers to firm up business requirements, conduct user research and competitor research, sketch concepts to a solution, prototyping, user testing, to documenting specifications.
  2. Product Owner or Product Manager – Provides high-level requirements, user stories & epics in the requirements gathering phase, involved in internal validation and after external validation.
  3. Tech Lead or Architect – Involved during internal validation and after external validation, to provide insights on technical feasibility, estimation on costs (upfront dev, future enhancements, support, etc) and implications to the overall system.
  4. UI/Visual Designers – Involved after external validation, to provide input on aesthetics and visual design.
  5. Developers – Usually not involved in the design process, only briefed during sprint planning.
  6. QAs or Test Engineers – Usually not involved in the design process, only briefed during sprint planning.

Your mileage may vary

Your design process will most likely be different, as it depends on your teams expertise, size and roles. It should not be set in stone as everyone should know the process, and also know when to change course.

Relevant reading

Building UX Teams #1 – Summarising what we do

UX is such a cryptic term. The job roles are so inconsistent between companies that there is usually a vast difference in job scope and expectations. The term UX is a jargon to most people as well, I hate inflicting jargon on others.

So when people ask me what my team does, even within the company, I’ve been trying out various alternatives, but here is what I’ve settled with.

The short version

We design software.

The short-technical version

We design products that works with our technology, for our users and businesses.

The presentation version


We do user research to understand user needs and goals and design solutions that enable a persistent focus on business outcomes, building only what is necessary to meet user expectations and supported by our technology. Our aim is to consistently hit the “Solution sweet spot” in our everything we design.

Here is an example of a solution that hits the sweet spot:

  • User expectations – Our users want to let members pay with direct debit for merchandise, so it’s convenient for them in accounting and cashflow management.
  • Business needs – Our business wants to enable more direct debit transactions as that’s how we make money
  • Technology – Our systems can only allow direct debit transactions to happen on the next weekday.

The solution sweet spot is we will support merchandise sales to be paid with collected with direct debit, but the transaction will only happen on the next weekday. We will charge a transaction fee for the payment. We test it with users to see if it works with them, if it turns out good, then….sweet.

There are times when solutions will skew towards any one of these 3 tips of the triangle, like if it’s skewed towards user expectations – If there is no transaction fee. Happens immediately. Our business won’t make money out of it and the cost to make the transaction immediate will mean a huge change around our systems.

This is how it works for us

Many used to have a perception that job of the UX team is to make pretty UI. But as we all know, that’s just one of the many functions of the UX team. The most important bit is still around designing things that work for users, business and technology.

This definition rather different from the user-centered process but in the end of the day, it’s far easier to understand for businesses set in their ways, but delivers a same level of outcome if managed appropriately. Unless you’re running a non-profit organisation, your business still needs to make money, and your designs will still have to work with the technology you have.

But of course, things will differ based on your context, so it might be worth a think….what does your UX team do?

Kind of related links

Why is UX a necessary part of product development?

As part of my internal presentation to step through our UX roadmap, I’ve put together some crude pointers on why User Experience (UX) is taking off as a crucial part in product development processes and becoming a requirement to stay afloat as a technology solution provider these days.

  1. Companies that have a shitload of features are getting disrupted by competitors with less features, but a better experience
  2. Customer demands have shifted from deciding based on the number of features only, to also expect an improved user experience
  3. Businesses cannot afford the risk of investing and building the wrong thing, one mistake might mean the end of a company
  4. Validating ideas early is crucial in enabling insights and evidence of user needs, so businesses are investing in building only what’s necessary
  5. Businesses are maturing on understanding the roles they need to build and maintain products

To be honest, its isn’t far off from applying traditional design principles in crafting digital products so rather than seeing it as something new, I prefer to see it as more of an evolution of how products are built. I believe this is applicable for all digital businesses regardless of whether you’re playing in the B2B, B2C or B2D ocean.

Here are some interesting links

What to build next?

Just a few days ago at Webcamp KL, I gave a talk titled “What to build next?”. Here’s the summary & slides

When was the last time you and your product team dealt with the dilemma of deciding what to build next? Here is a quick presentation stepping through some stuff to consider before jumping right in and getting things going.


Designing with the 80/20 rule

As a designer, I have found the 80/20 rule to be one of those weapons in my arsenal that is used almost every other day. Here’s it is defined in Wikipedia:

The Pareto principle, also known as the 80/20 rule, states that for many events, roughly 80% of the effects come from 20% of the causes.

Sounds simple, but you might be questioning how on earth it can be applied to design. To make things clearer, let me lay out some scenarios where the 80/20 rule can be applied to both Ezypay and iconnect360.

80% of our user’s daily activities centre around 20% of our product’s features

Surprising maybe, but true. One of our flagship products, iconnect360, is a business management suite that is loaded with almost everything needed to run a health & leisure business – CRM, direct debit billing, memberships, POS, bookings, access control…and the list goes on. But the feature that are used the most are two things – access control and direct debit billing.

What does this mean? It means these are the areas we have to invest more in for our product to have any chance of succeeding, in areas like usability, performance, etc

80% of sales come from 20% of our clients

As a B2B SaaS solution provider, this common rule of thumb for business very much applies to us as well. Our core revenue comes from processing direct debit payments. Big clients have more members, more members mean more payments, which means more revenue to us.

What does this mean? It means they are the ones that we want to make sure we retain, please and potentially also give in to their feature requests, while managing the risk of customisation.

80% of our support requests are usually due to issues around 20% of the features

Most of them are all around direct debit billing. Money movement is one heck of a complex thing, couple it with a load of other features and it’s seriously a beast to manage. I’m sure there are issues around all the other features in the system as well, but its more tolerable compared to roadblocks in features that are used alot.

What does this mean? It means it might be worth investing in optimising the resolution of foreseeable issues like training content, and improving how insights can be gathered from these support requests to inform product decisions.

If you think about it…

In everything you design, consider the 80/20 rule in to help you focus on what is more important and compromise more on what is less important. Use it to decide what to build, inform business decisions, etc. You can even apply it to relationshipwebsite’s content, etc.

The great thing is it even makes sense to everyone from the average joe, tech geek and savvy businessman, making it a very effective weapon indeed.