Let’s jump right to the point. We are expanding the UX team and looking to get on board some UX designers in the coming months. Whether you’ve actually thought about designing SaaS and enterprise solutions or not, think about it now.
Our UX team comprises of generalists that span many design disciplines. We have UX designers that turn conceptual ideas into solutions, test them with users and mould them into end-to-end experiences that meet and exceed the needs of users, enabling business outcomes and work with our technology. The aesthetics and visual excellence of our UI is governed by our front-end engineers that work across our products to ensure a consistent visual language and pleasing experience across multiple platforms. UX research informs how our users use our product and enables to see the world from their end. Training is also very much an area of focus to facilitate self-learning by our users, especially for areas of complexity in our systems.
We collaboratively work with developers, product owners, testers, support and many other areas of the business. It is all part of our design process that we are constantly improving and tweaking every week. And a small part of the AGILE end-to-end product development life-cycle.
Payments and club management software might seem like a small niche, but I can assure you the challenge we face on a regular basis on simplifying complex experiences, driving innovation and challenging the status quo of the industry is simply inspiring.
If that sounds cool, apply today by sending your resume and portfolio to kok.chiann[at]iconnect360.com.
“We’re like the tallest midget. Really tall when compared to others in the industry, but still a midget. I’d rather us be the shortest giant.” said one of our potential clients when describing her company.
I must say, that sentence could not be more apt in describing most companies. Pretty effective message to rally everyone towards building the company into a giant too I must say.
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