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.
You can say it’s the person in charge of user experience in your organisation chart, but stop for a moment and reconsider.
Yikes, that sounds like everyone involved in shaping, delivering and supporting the product. So before saying you’re accountable for everything a product’s user experience, think again.
A few months ago, the iconnect360 team faced a challenging situation. We have our product out in the wild, and we were rolling out feature after feature, our velocity was ramping up. It all seemed great, but in fact it wasn’t. Support requests were piling up and we’re playing catchup without making any significant progress.
In show & tell sessions, there are times you would hear someone tell you “I’ve never seen this is other systems and competitors, it will not work”. If that convinces you your design wasn’t that great after all, then fine, take on that feedback, scrap it and iterate.
But what if you’re still confident you’re on the right track, firm up your solution and test it with users. Only then will you know if you’ve struck gold with your solution, or got it totally wrong. If possible, involve the “unbeliever” in the user testing session as an observer. You might just turn this person into a believer.
Users don’t know what they want, until they see them. That’s when innovation happens. I’m sure most of us didn’t know how the iPhone is something we would want, until we saw it unleashed to the wild.
How many times have you seen a piece of software being marketing as being easy to use and easy to train…only to contrast starkly with the actual reality, once you start using it.
Who knows it might be due to having “Easy to use” in the product strategy, while executing without consideration of it. The ugly truth is these days, software that are easy to use and train are becoming a minimal expectation of users. Rather than having usability as one of the many documented requirements, set is as a minimum requirement to guide all product decisions. Rather than having hundreds of features, build usable features that contribute to your mission and vision to disrupt the market.
In the end of the day, action speaks louder than words. Your users will be sure to tell you whether your software is easy to use, or not.