Growing the UX team

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.

UX designer banner

How we tick

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.

Be part of something big

We’ve just released Ezypay in Singapore and Malaysia. iconnect360 will soon follow suit and be rolled out across more countries too. Exponentially more people are using our products every single day.

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.

Tallest Midget

“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.

Customisation

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.

Disclaimer

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

UX-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

UX-key-purpose

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