This is how Bllocc, a visually-focused link-shortener web-app, came to be as an initiative for Perzegi, which is a design studio based in Tangerang, Indonesia.

For around 2 months or so, I was in a team of 4 brilliant people that created the prototype for Bllocc, which was a hub-esque web application that connects primarily social media to multiple sites at once. I handled most of the visual and UI work, with sprinkles of UX inputs here and there. My part in the UX side revolves heavily around prototyping, with an emphasis on making it ready and presentable to future stakeholders.

Bllocc came to be as an exploration that became an actual web app that we wanted to release publicly. The initial idea happened upon us over a simple catch-up between co-workers outside of our work hours.

To say the least, the conversation evolved into a bunch of crazy ideas that it was looking like a brainstorming session instead of laughs and giggles. One of which was the something that can be an alternative for link shorteners (bit.ly, Linktree, etc.) with a more visual output in mind. After noting a few key concepts and some questions that we need to answer, we decided to plan a roadmap for development, and work on it for real.

That random outing ended up with the majority of our team: Bryan (Project Manager & Visual Design), Vinsen (Me! UI, UX, and Visual Design), and Matthew (Full-Stack Dev). We were later joined by Aileen (Visual Design) during the first week.

After that session, we entered our first week of development by focusing on research and analysis. We wanted to polish our data to make sure that there is a possible market for our app and defining the needs and frustrations of our potential users when they use other similar link shorteners.

We divided this process into 3 parts: researching users, analyzing our competitors, and further design sprints.

User Research We spread out a survey and interviewed people who have had the experience of using link-shortening products. Our main goal during this step was to find their personal needs and pain points. What do they value the most in these services? Where did they find features that work and don’t work? Were they satisfied with the plan that they got? Et cetera, et cetera.

40 survey respondents and 15 interviewees answered our call. We got most of our data during the weekend, so our team did most of the data collection online, using Miro. By the next Monday, we had most of it moved to physical post-its, and they were stamped to our office’s walls.

We aim to build the project within an existing market, and so we decided to look at what our competitors do best and where can there be improvements. During this point, our team took one service each and wrote our thoughts regarding these services to eventually be pitched during our next processes (and fill up our wall more with ideas!).

On the first day of the second week, we gathered our findings during the previous week from interviews, surveys, and independent research altogether through brainstorming. We mapped our results with post-its to the wall. There were some key takeaways that we found, the primary ones being:

Most respondents (almost 75%; three quarters of our whole sample) are familiar with link-shortening services and have used them for various reasons. From selling products in different online shops to simple portfolios.

Respondents feel the need of better modifications in their sites, particularly within the capabilities of customizing their links to feel different between each other.

They would go for premium should there be more upgrades in regard to point no. 2, or ease-of-use improvements.

All of this became a consideration during our planning phase, which involved persona-making, mapping the information architecture, and brainstorming for more visual concepts. We also began delving into the customer journey and finding out their high and low points to serve as a reference in our future designs.

We then proceeded to loosely adapt the design sprint method of Google Ventures into our process and set a realistic objective for the next two-weeks: solve the problem through experiments and create a prototype which will be implemented through real-life application.

Around the middle of the week, we began crafting multiple sketches independently based on our findings so far. We wanted to proceed step-by-step from low-fidelity to high-fidelity, with usability testing placed in-between.

Me and Bryan had the same rough idea on how to visualize the product itself: positioning the elements and links as ‘Blocks’. We pitched this idea to our other team members, and after a vote, we decided to go forward with this concept. We then proceeded to find some people who are able to be our ‘test subjects’ in the real world, as well as create a user flow based on this by positioning a user who is creating his / her first batch of Blocks.

By this point, we are around 70% done in mapping how the overall web-app is going to look like. Our main concerns lie in the code itself; since we had to have a library that supports our whole idea. Matthew assured us that he’s found a way but need more time to learn how to implement it, so we decided to focus more on that objective of ours: making the prototype for our potential users.

Oh, and we also decided on the name ‘Bllocc’. It rhymes with ‘Blocks’ and it goes well with .cc as our primary domain extension.

We also conceptualized a few other aspects of the site by this point! Namely, the brand identity, what features would it have, and how users would start using it. We chose vibrant blue to be our primary color just to convey ease of use and non-intimidating vibes, with white completing the palette to signify sleekness and a blank slate that people can tamper freely (this was later confirmed by potential users to have that effect during testing).

Our focus turns to those ‘test subjects’ we mentioned earlier. We got 2 online shop owners that we asked to be our first recipient. The first prototypes were pseudo-static; meaning they work in a way like a finished product would, but we would do any edits manually. This step begins in Figma, in what people usually call high-fidelity prototyping. We made ones for the app itself, the onboarding process, and the landing page.

Side note: that code problem from before? It’s solved (somewhat). We found a library that can handle the customization process (especially the block-dragging motion that we wanted). It’s not perfect; we noted how heavy the product became to load, but we figured that we’re going to try to find a way to lighten it on the way.

During prototyping, we tested each feature and steps internally and externally (the latter mostly spontaneous when we encounter people that falls into our demographic), and tailored based on feedbacks over, and over, and over again.

This process took the most of our third week; the people we asked were quite interested in seeing where we improve, which we are very grateful for. If one of you testers are reading these, you guys are the best.

An example in this improvement can be seen in the block creation process, which was noted by a few testers when presented with it. This took shape in size previews with added flavor texts to help users, especially first-time ones that still need to visualize before creating their intended results.

A lot of what we expected did not come to be realized during this project. Some concepts were cut, some were not feasible to be put into a live product, and many more roadblocks hampered our initial vision. Fortunately, we were blessed with a good time management schedule that we decided ourselves (we were surprisingly very productive working from home) which helped us immensely during chasing prototype deadlines, and the fact that the responses were very constructive and positive even early on. Even those that say outright that our product has a LOT of bases to cover gave us great criticisms that allow us to push and iterate forward. To that, I personally have to thank our great samples and respondents, and also to both Kletek Stickers and Gadis Punya who served as our premier testers.

In the meantime, the work is still on! We plan to introduce the self-creating Block web app in the future to complete the whole kit. With the web app, every user would be able to customize freely and put whatever Blocks they wanted inside of it. Eventually, it will be complemented by a premium version that will have a myriad of other features, one of them being a form of analytic tool that will allow users to view their hub’s stats, optimize their SEOs, etc.

For me, this project helped me learn how a good design is made. It’s certainly not an overnight process. It’s something that you pour your blood and sweat on; initiating zoom calls daily both to communicate with the team and respondents made me feel like a customer service worker at times 😭. But it was all worth it! The project DID help our target users and achieve what they’re supposed to do (albeit assisted, somewhat) even if the results are still interim. And both me and my team are quite satisfied with the results. Doesn’t mean we’re stopping, though.