Here’s a checklist of what might happen when a client requests customisation of a product supposedly targeted at a generic audience:
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:
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.
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:
Just food for thought that will most likely be different in your context. More than happy to have a chat over it.
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:
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 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:
Happy new year!
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:
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.
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.
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:
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.
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.
We design software.
We design products that works with our technology, for our users and businesses.
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:
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.
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?
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.
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
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.
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.
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
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.
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.
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 relationship, website’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.