I have a new website. Check it out!

Skip to content

Another New Chapter

July 5th, 2015

Soon, it will be my last day with DBS Bank, and my last day in Singapore.

I am returning to Indonesia. Not sure what I’m going to do next, at least I am going to take a break for a while and enjoy time with my family and new-born daughter, Janis.

It’s been a rough six-month period. I learned a lot of things, about the company, about myself, about the industry, about design. Bad or good, I take everything as lesson.

It might sound immature to some of you, but for me, it’s just a spice of life. You learn, you move on. You design your life and forget the past. Six months later, the company you worked for would’ve moved on and would’ve forgotten about you.

There is one reason why I leave DBS Bank, no matter how many people say it’s better to be here.

Culture.

Before you think I am a self-entitled guy, let me explain. I’ve been in corporate, but never been in an industry outside technology. It is very difficult to adjust myself in. Even if I give myself time, I am afraid I’d fit to their culture even more and will not be able to “depart” from that culture. I am afraid I will be blended in. I want to stay what I am now.

Corporate environment is where you are not allowed to make mistakes. Your heads will be cut off. Everybody is risk-averse. This is not how design operates. We assume, experiment, prove and iterate. Business environment is different. They never can make assumptions, nor experiment, let alone prove and iterate. They are very strict and money-driven: This is what we want to do to make profit and here’s our projection. Do this our way or we’ll cut your head off. The only measurement tool is profit, profit and profit. Design success is not measured only by money — nor short term benefits — it’s about recognitions, experiences, feelings. These things can’t be directly measured. Only good companies who care can really recognise these benchmarks.

I know you’re going to say that every company has the same problems, big or small. Well, I gotta say you this: I am not expecting to escape all these. I am just expecting to get out of these frustration within a grand scale and find a scale I can tolerate more with — maybe with a smaller company, maybe with a better culture. I know I will always find issues, but I believe there are issues and companies I can deal with.

That said, I am currently open for opportunities. If you are interested in engaging a full-time digital product designer who focuses in user experience and user interface, please email me and let’s talk!

On Making a Dent in Corporate Environment

June 20th, 2015

People still see design as a tool, not a way of thinking. I have to admit that, and often take the red pill.

When corporations decided they need to have a design team embedded in-house, what were they thinking, really? There can be multiple reasons. They might have a little fed up with engaging with the design vendors to execute their programs. It’s either expensive or time-consuming. It can also be energy-consuming. After spending millions of dollars they still get something that they expected. They build a design team in the hopes that they could do design in-house — as a tool — and execute business programs better. They might also need a design team to advance design thinking through the company: changing the culture of work. This is very daunting and it involves changes in all departments.

What I see is that mostly it’s the first. Companies think design just as a tool. They still do business they way the always do it. See, it’s very comfortable way (albeit not the most effective) to do things. They start with business requirements, and the business guys think they are the everything in the company. Everyone else is just executing their programs, thus, they need to listen to the “business guys”. Please, don’t ask any questions and just do whatever the things we ask you to do. “This is all business requirement.”

Because, this has been the way we did it. Business thinks they have a project and the budget has been approved by the management. They formulate things, but only from business perspective. Will it make profit? Will it be different from the past? What “business improvements” can we make? What can we do to make sure that the investments pay off?

Then they spend nights and days working to get the concept right, and put everything in into a humongous deck with diagrams, jargons and whatnots. Oh, don’t forget there’s a requirement document to be made. It has to be 100 pages long. Every scenario needs to be accounted for.

Business will present these things back to the management or to the next in the pipeline: delivery team that includes design and engineering. “Do it as we say, or you’ll die.”

“We’ve spent a lot of thoughts in these and we think it’s the best! Why can’t you do it?”

You know, because design and engineering have different perspectives and limitations, they start to counterargument. They’ve never been consulted previously. This delays the timeline. Business guys are so pissed off.

Things need to be revised! But no, please, timeline is only 6 months! There’s no way we can adapt to these changes proposed by design and engineering! We’re so screwed.

Why can’t design and engineering listen to us?

The thing is, business guys, there’s nothing crappier than assuming that every project only has one dimension to it: profit. There’s a whole lot of dimensions that should poured into one. How can you make profit if the way you present it to the customers lack good user experience? How can you make profits if engineering can’t deliver a single thing because your items live in a distant land of innovation that your company has never invested in?

Do you think design is just making your crappy idea pretty? Should we just lay that long, “corporate speak” text in an elegant typeface and be done with it? Should we follow your business-centric approach and apply blindly to interaction flows? You think designers are makeup artists? Even makeup artists had education and they help you find the best solution.

What I feel is lacking in corporate environment is the willingness to listen and be open to new frontiers, like design and engineering. Particularly design, because it takes time. They don’t want to take the time.

Take the time to listen. Engage design and engineering upfront.

Stop Caring about the Analytics

May 16th, 2015

I have two blogs. One is this, and the other one is a travel blog — which I think is doing quite okay.

I installed analytics in both, with Jetpack for WordPress. Well, honestly, I have removed it temporarily for this blog because of some server issue before. But I have a hard time deciding to put it back.

Once in the past I was obsessed with stats. That was something that propelled me to produce new content and improve the quality of the content. When I used to have comments in my blog, it was even worse. I gauged post quality by the number of comments.

In the heyday of web design, you had page hit counters and a remotely-hosted stat site that detected demographic information of your site’s visitors.

It does apply to my tweets, too. I have my personal Twitter account and the travel blog’s Twitter account. I would obsessively check the follower count, the favorite list — whether someone, somewhere have favorited my stuff and how many times. Then, once in the lame past of my tweeting history, I also signed up for a service that detected when a user on Twitter has unfollowed me and it will notify me. I was that paranoid.

Then, came the silly Klout score.

I was dead obsessed about these things.

I decided then not to care about things like those anymore. There are several reasons.

First, obsessing about analytics takes away my focus on creating quality content. Or at least, genuine content. A content that is true to yourself, and one which you do with the ways you believe in. The mission is to have the constant motivation and trajectory to increase the quality of your content without worrying too much about what people say.

Second, analytics is mediocrity. If the content or product is genuinely good, people will come to you no matter what the analytics say.

Third, analytics is “business tell-tale”. It’s everything to do with selling & convincing. See point 2. Good content or product don’t need convincing. You can have fewer audience but greater potential.

You can have analytics tool installed or whatever, but don’t spend your time on that every night. Spend your time creating good content and product instead.

The Insanity of Design Specs

May 15th, 2015

I know — I’ve done this, and it makes me a little crazy. You can do insanely detailed design specifications in the smallest pixel unit possible, defining all that little spaces between text, buttons, boxes and whatnots, so to say, you can help the guys who develop the app better, and that the brand or app or the digital product can have a more consistent and coherent execution later on. When you move on, you’ll leave some sort of a legacy.

I have no objections to these detailed design specs. The question is, how detailed?

Should I use pixels? Pixels are rather dead, because screens are various and we need to cater for responsiveness, or whatever.

Should I define all screens, or just per component? It’s way crazy to define all screens, that’s not a systematic way to work. However, some engineers do ask for it. I don’t know why.

Should I enforce them religiously, or should I cater for some flexibility? Because, you know, you deal with people, and the product is a living product. It never for the good of God be still and set in stone forever like that.

Even if you use exact pixels, ems, percentages… people will deviate. That’s one thing for sure. There’s no use in enforcing it religiously, then. By the end of it all, in big projects, people don’t have time to go through the goddamn documentation. We’re always in a rush.

In the past, I’ve always done just enough spec, which means I try to negotiate the major components that I need to spec, maybe a little component mapping on key screens. They can go detailed in pixels or percentages, but I don’t want to be lofty and say the magic word: “deviate from this, and you’ll be stoned to death.” I try to treat my spec as a suggestion rather than rules.

Design specs must be agile and evolving. They are never set in stone. If the team cannot treat it like that, for various reasons, then the way they work is not good enough.

I’ve worked in small companies and big corporations. The small companies tend to not have design specs and do a one-time design and evolve from there. This is in one-way good. Just build the components and reuse them as they see fit. No documentation, or just little documentation. The big corporations tend to be scared. They put a lot of money into a project and they want a scalable, governing design guideline. They hire someone in-house or outsource the assignment to an agency, then after all that months of sweat and pain, they finally have a design language system and whatnots.

Totally fine for both. The thing to worry is about how we all execute them later.

The small companies are agile, thus they have the advantage of having flexibility to implement their design guideline. The “get shit done” attitude makes it all better, but the presence of a designer to be a gatekeeper is also prominently needed so the design still makes sense even after “deviations”.

The big corporations are slow & lazy. They would cherish the design spec in the first few months. Everything seems to be working well. However, by the end of it, they’re going to ditch the design language system and hire a new agency to do another one because they feel the fault is within the documentation, or the design is outdated. Or, it can be simply a problem of operating in silos: different teams work differently in their own interest of time and resources. Politics.

Enforcing agile design specs sounds like more probably done in small companies and startups, but it can be in big corporations, only if the management realizes how important being agile is, and agility should not be part of just the design team, but of the whole process and various teams.

Meetings Can Be Better If

May 13th, 2015

  • People don’t bring laptops and phones in. Just do sketches. Emails and internet are distracting.
  • No PowerPoint is involved. Alright, Keynote slides are fine. Or even better, just still images.
  • We all keep it lean. Just 5 participants maximum. Odd numbers are best, so in case we go democratic, we can outnumber the rest.
  • It’s done in day-time, before lunch.
  • We keep it short. One hour is the max.
  • We have action plans thought before. Brainstorming for hours isn’t a thing.
  • We plan it a few days before, but not weeks before.
  • We think that the discussion can be relatively longer than a short email.
  • We really need see faces.
  • Internet connection is best — only for conference calls. Anyway, conference calls are painful. So, I’d rather skip them. Do emails instead.
  • They’re actually replaced with emails or digital communication tools or whatever. (Can’t stress enough.)
  • Each participant is given equal or appropriate time to express themselves. Meetings often benefit only extroverts.
  • Prepared. Meaning, each participant is briefed on the subject of meeting and they’re asked to write first-hand solutions to be discussed further. Nothing is worst than coming empty-handed and spend 1 hour talking about nothing.
  • We have whiteboards or stick-its, of course. See point 1.
  • We lose the projectors and replace them with monitors (big ones). Projectors are shitty.