case study | mereka.io

a ticketing platform for any time & place

how do we simplify event check-ins not just for bookings in advance, but also for last-minute entries at the door?

• view project

case study | mereka tech team

redesigning design handoff

How can we keep our design files easy to work on and easy for everyone to understand?

• view project

product design | the makeover guys

furniture procurement system

a case study on vendor tracking, stock management, and an internal marketplace all in one, in order to speed up the workflow of an interior design agency

• view project

vertex

a portfolio and software preview of Vertex, a tool for construction & engineering that harnesses the power of BIM and CAD data, to make project management and execution easier.

• view project

kyberverse.xyz

one single place to hold my many links and places to find me online. the landing page that leads to this portfolio, my illustration brand, blogs, and socials.

• view project

biji-biji initiative

an environmental-based social enterprise with services ranging from making upcycled merchandise to organising sustainability programs. this website aims to convey the business' offerings to potential corporate clients or collaborators.

• view website

the home(page) is where the heart (of your app) is

2024 | blog post

Product requirements? Maybe not 100% there, but the idea exists. Style guide, design system? Check. Sitemap? Check. Time to design your app, but where do you begin? In the bigger picture, the answer is probably something along the lines of starting with an MVP (minimum viable product) but on a more atomic, design-specific context, the absolute first thing you will design is typically, the homepage.

• read more

The UX of design handoff

2024 | blog post

Handing finished designs over to product and development has got to be the most enigmatic part of the UX process. Figma files tend to be a bit of a mess, and I’m always hunting for ways to keep it clean, clear, and light. I will say part of the mess is my own doing, but there has to be a way to make things make sense for everybody?

• read more

Bondee: The Social Metaverse We Actually Like

2023 | Kreatif Beats

Whether Bondee and the minimal form of metaverse it represents is here to stay, or simply a transitional phase before we all are virtually surfing with the Zuck himself, I do see a few things we can learn from this in the cultivation of new digital spaces. The metaverse is definitely a concept that is starting to have roots, I wonder if it will really grow or fizzle out of the mainstream eye ?

• read more

I took on a three month internship at a local interior design startup, within their Digital Transformation department that focuses on discovering digital solutions to improve the company workflow. The company has a unique mode of operation where they templatise home makeovers to ensure a speedy process and mainly caters to property owners aiming to rent out their apartments/houses.

The team initially searched for off-the-shelf solutions to improve the process of ordering furniture from vendors (which typically consists of the designers going back-and-forth on Excel sheets and WhatsApp with the individual vendors) as the operations team was struggling to continue with the existing flow especially as the company is growing and taking on more projects.

However, we held a design sprint with members of both operations and digital transformation team, and realised that the needs and workflow of the company are too complex for generalised, mass-market solutions, and it was then decided that the best way moving forward would be to tailor-make a solution that fits all those needs.

what

Introducing ways for event attendees to pay for tickets at the door instead of booking prior, be it from their own smartphone or by purchasing it from on-ground event staff

why

SME's and microbusinesses do not always have adequate resources to handle in-person payments and ticket checks while event attendees might be put off by inefficient ticketing and delays to enter the event

impact

Streamline tracking of attendee and sales data by reducing number of offline/cash payments while also reducing wait-time, queues, and other frustrations faced by walk-in attendees

user feedback & interviews

After the initial feedback that promoted this project I continued to follow up with those who were on ground during that incident throughout. Aside from that we also had past feedback and feature requests collected on Canny that served as secondary insights.

competitor analysis

Various booking websites for different purposes were used as inspiration, including Eventbrite, Airbnb, as well as local websites for cinemas and airline tickets in order to understand how different types of services will ask their customers to display tickets at entry.

design thinking

I drafted up a few user flows based on the existing features as well as some proposed new ideas, presented and got feedback from various people, made design mockups, and did many iterations of the above until we reached the final solutions.

long queues, slow entry for attendees

Allowing people to purchase tickets online is helpful from the comfort of their homes. Requiring them to do the same at a walk-in event can be troublesome due to uncontrollable factors such as screen glare in the sun, unreliable internet connection, or slow load-times when everyone is trying to book at the same time.

"can i just pay with QR?"

Although cashless payment by keying in your card information on the website was already available, this was not flexible enough for on-ground use cases. Cash payment is suitable for in-person events, but can become tricky if the crowd is large or if the organiser does not have change on hand.

hosts struggling to track sales

The host would cross-reference attendee names and email addresses on the list to verify that the correct person is being let in, then check off names in pencil to prevent the same booking from being misused by multiple people. This was often slow and also inconvenient to search through if the list was long.

shortcut links, less clicks

Rather than making customers go through the lengthy process of searching for the event on Mereka's website in order to make a booking, having a link that immediately directs them to the checkout page for that event would reduce the time taken to book by about 60% .

support local payment methods

If DuitNow QR, bank transfers, e-wallets, and such were available on Mereka, it would allow more customers to pay the way they prefer to while still having the sales go through the platform.

make offline payments trackable

As much as we'd like to keep every thing on-platform, sometimes people just prefer other payment methods and other times it is good to have an offline failsafe.

virtual tickets

Thus far, Mereka's booking process felt more like a generic e-commerce flow.. A simple way to bridge the gap into being a ticketing platform is well.... providing tickets! These could be shown to the host for quick reference and could contain QR codes for the host to scan and automatically mark attendance.

help the host to help the customer

Sales on Mereka were entirely self-service ; users search for their desired event and then take themselves through the purchasing process. A more "traditional" sales approach where all the customer has to do is tell the host how many tickets they need then pay, and the host handles all the input could also speed this u.

hardware limitations

A main selling point of Mereka is that businesses don't have to purchase any additional hardware and can conduct everything just from their computer or phone. However, this requires solutions to be flexible for different devices. For example, some phones have built-in NFC scanners that you could use for card payments, but not all.

our browser-based platform

Mereka being a web-app rather than one that you download meant that implementing tools that use a phone's camera or NFC scanners would be complex if doable at all.

Third-party payment processing

Although Mereka's userbase is primarily in Malaysia, payment processing was done via a global payment provider rather than a local one for the sake of scalability. However, this limited payment to methods approved by the provider, namely card payments and GrabPay e-wallet. Many consumers here typically pay online via bank transfer or a multitude of different e-wallets.

attendance module

Medium impact, but low effort (at least for the design team) - We cut out the extra step of hosts having to print out their booking lists and rifling through them at the door by giving them a searchable checklist right in their dashboards. As a little bonus, we added a notes feature to it since some feedback we received was that occasionally the host would need to make a note about a particular attendee, which would usually be scribbled between the lines on printed lists.

quick links + QR code generator

Low effort as well, but low impact too. This solution was a sort of band-aid over the other issues that were making the walk-in journey slow. Businesses on Mereka already had to go through the long process of creating their event listing, so rather than leaving them to also need to make posters for "Sign up here, scan the QR code" we added a little template for it that auto-populates based on their listing.
We also added a new entry point to event checkout pages that bypass all the fuss and frills before it, taking you directly to a ticket selection for that particular day, combined with the payment flow.

We streamlined customer signups on the platform to increase the retention rate of walk-in customers to continuous users who browse the platform.

Our dev team optimised the site's code to reduce lag / speed up page load times

Streamlined the UX of our ticket selection UI as well as our checkout page - previously there were many more clicks needed, not all of them being useful or intuitive.

Ticket selling, complete with tap-to-pay functionality

Somewhere along the way the payment processor we were using added a feature to collect payments via NFC if you have a mobile app , so this was a big encouragement towards the idea of building one.

QR Ticket scanner & attendance lists in the palm of your hand

Just like what I ideated earlier on, we started providing customers with an an e-ticket, so once they reach the event the only thing the host has to do is to scan the ticket code and check that it is valid.Although the attendance feature we built in phase 1 was available on mobile web, it was a bit slow on the go since refreshing the list meant having to refresh the whole browser window, so we combined this with the QR scanner to serve as a backup in case the scanner doesn't work, and also as a reference list of all the attendee names and contact information.

research

I scoured the web, watched videos on Figma's YouTube channel of tech companies showing how they use Figma, read through Reddit posts of others facing similar issues as we were, found community files with templates for handoff docs. However, no two teams are 100% the same nor are the products and flows that different companies handle.Through the secondary research I was able to gather a few ideas to guide me, but not one singular direction to go in.

user observation & feedback

In this special project, the users at hand were our internal team. i asked some of them for feedback, and also observed how they interact with our design docs, making note of what sort of thing they were able to easily follow or what they couldn't, what sort of clarifications they would seek from designers after a feature is handed over to begin development, and so on.

trial & error

as i gathered more ideas, i would change my workflow within the design files i was working on at any time - since there were other designers on the team, changing the structure only within my deliverables prevented the changes from being too drastic and left room to improve, gather feedback feedback, and continue changing and improving things until it reached a point where it felt like a solid solution, ready for the whole team to implement.

a growing product means growing files

Creating and introducing new features all the time created pressure to organise things better. In the beginning, most of the platform’s designs could fit into one file. However, as improvements, bug fixes, and new additions came into play, we shifted to organising files by sprints: The old initial file served as a master document, whereas any changes would refer to a sprint file if/when a feature was worked on within that time. That worked well for keeping track of different iterations of things, but became ineffective because sometimes, development would only begin months after a design task is completed , and not necessarily in the same order.

gaps in understanding between design + tech team

A lot more goes into designing a single screen than some realise, especially when designing a complex dashboard, a form, or even an interactive list. What me and my fellow designers were doing, and what I commonly see in blogs or demo files aiming to teach new designers how to arrange their work, is just one linear display of frames in a particular user flow. However, this was messy when it came to flows that branch out into multiple different outcomes, before even considering different edge cases and error states
Sometimes design team would think something is straightforward, but rarely does that also apply to the devs viewing the file later on

poor readability

Our designs were arranged in a way that was difficult to navigate - this came to light when devs were constantly reaching out unable to find specific designs.We had certain designated areas in our documentation template to add descriptions, but it became a habit where those would only contain a main point, then any further notes were scattered as textboxes floating near screens.

Screens that branched out into multiple scenarios were also difficult to follow as we did not have a way to display every flow clearly. Plus, desktop designs would be grouped in one area, whereas the mobile counterpart of the same flow would be separated somewhere on the side, making it hard to view both together when developing the front end UI responsively. It also likely exacerbated a separate issue of us designers forgetting to design mobile-responsive layouts, since the earlier phases

information hierarchy & readability prioritised

A small yet impactful change was making our documentation read from left to right over being top to down — the initial idea was that computers scroll vertically, so we should arrange things as such. but these got messy as long flows would mean scrolling very far, the horizontal orientation of monitors making there be excessive empty space on the sides.Evidently, mobile is just as important as desktop. Sometimes, it should take priority. Therefore, every page, popup, and so on should have the designs for both devices side by side and presented as two pieces of the same puzzle rather than independently entities, unless a feature is exclusive to one device or the other. This not only was easier for devs to follow, but also helped keep us designers in the habit of considering both devices at the same time

break things down for easier digestion

If a single page branches out into different flows, they can be broken up, displayed one by one, and sorted from most to least common — each one can also be labelled to clarify if it’s a different path a user may take, an optional step along a key flow, an error process, and so on. Since Figma had just rolled out their section feature not long before I embarked on this, I took advantage of it to box things up nicely, and also color coded the different paths to make them more searchable at a glance.
Aside from that, I split up our design docs into different sections, one for UI specs and another for user stories. This makes it easier for different devs to all look for what they need, for example the front end team can check on the UI specs to do the page layout and back end can refer to the user stories and notes to create the back end logic.

keep everyone in the loop

i updated the other designers plenty along the way, then gave a walkthrough of how to arrange their designs once i had finished creating a final template. i also assembled a guide to make onboardings easier and so that anyone reading our docs such as the devs and PM could also get to know all the improved ways to find what they need.

i had been saving inspiration pics for MONTHS, narrowing down my ideas into 3 styles:- neobrutalism : this is something that would likely go out of style soon, but the essence of it is pretty minimal and wireframe-esque. i just think it's way cooler than other web design trends of the past couple years- something fun and cute : think early 2000s toy websites. i spent a chunk of my childhood playing games on barbie.com and the like, plus this sort of childhood nostalgia and playfulness leans into the kind of things i do with my illustrations.- standard modern minimal UI that's on just about every big app : what can i say i am a UX DESIGNER !!!!!! this one is not as exciting as the others, but a good transition screen between the other two.

design:
colour & layout as a common thread

each style theme had distinct use of fonts, shape, and white space, but similar layouts so that things don't jump around the page when a user clicks to another theme. i used the same 3 colors for all themes, but applied them slightly differently in each be it the container and text colours or use of shadow.

navigation:
one hub to link all my links

i have a lot going on, digital footprint wise. my professional work. my art hobbypreneur thing. my blogs (plural!) social media.
essentially, what I made is a DIY linktree - a homepage that branches out to the different sites compartmentalising everything I aim to share.

development:
bare bones & basic

the whole thing is just HTML, CSS, and a tiny bit of Javascript to control the theme change button.i made use of root variables in the CSS to set the styling for each theme, inspired by how light/dark mode toggles can be made.