Posts from the ‘Design’ Category
It’s so familiar in the life of designers, that a coworker, or somebody who owns the project, to say something like, “can you explore more alternatives?”, or “can we present 3–5 alternatives, and let the boss picks one or two?”.
I am one of those designers who believe less and less in “more” and “alternatives”, instead, I believe in a focused yet continuous iteration of one problem or flow.
There are some reasons why design alternatives are bad for the design process.
“Design alternatives” are often insecure, indecisive and wasteful ways of presenting and consolidating on designs.
Consider the following scenarios:
Inability to define priorities. I want to include feature A, B and C. I don’t know which one should be incorporated first. Should I even include all of them? Heck, why don’t we just provide 5 alternatives each sporting different sets of features? Who knows the boss or client might like it?
Lack of user insight. The user might want the ability to shuffle the list of images. Or they might not. Or they might. Heck, why don’t we present 10 alternatives at how we might do this?
Design or product bias. “Well, I did this for my previous company and it worked great!” — well yeah, what about this product you’re doing now? “It certainly is cool to do a visual collage of these! The customers will love it! You know I love it!” —well yeah, are you the customer? Why do you think a visual style works better than the rest? Oh heck, we can always prototype 5 more collage alternatives. Or even worse, “I don’t like this design. Try something else.” OK, you’re the customer.
In the end, presenting multiple alternatives of a design would usually end up in:
Combination fatigue. “Can we combine this cute picture of a monkey with a big type all over it, and then add some augmented functionality in it? Oh, don’t forget that correct blue tinge on the eyes of the monkey.” Suddenly, we’re not speaking the language of the users, but more of personal taste and heavy assumptions.
Micromanagement. Designers have reasons why they do something, be it from technological, cultural or time constraints. It is wise to give them problems, but never micromanage their answers. Even more, if you’re already taking part in nudging or nitpicking the visual elements. Never do that. Depart from the problem, always.
Design by committee. This is the worst, absolute worst thing that can happen in any design or product. While democracy is good, design needs decisiveness and ownership by the designers. There are some design choices that need to be made to assure that the design has empathy to the users, more than the business goals, more than personal goals. And this is achieved by trusting the designers a bit more.
What is a good alternative? Here’s what I am proposing:
Design one thing at a time, then iterate. Depart from clarity, focus, and insight for the users, business and other goals. But mostly, it should be the users first. Create one version of one thing, then explore more at the pace of one iteration at a time.
Set the key question and answer. At the very beginning, set the key question. What am I trying to do? What is the user trying to accomplish? Then, set a few key answers, and follow that strictly.
Focus on the experience, not the visuals. Visuals can come later, and they are the domain of the designers. Focus on the experience, the flow, the information architecture, and nail them down first. Then you can talk visuals.
If things fail and you need alternatives anyway: limit to 2, and be deliberate in the reasoning why you need the alternatives. Never combine features just because you like both things. It has to come from the user’s key question and answer.
First up, disclaimer: I had no experience in building a design team from scratch, although I had managerial experience very briefly, and not in a very large team. That said, this idea is something that needs more experimentation and validation. However, I am pretty comfortable at sharing this to you.
I always found that companies everywhere are struggling with the idea of design. They are confused as how design should be positioned and treated. Mostly, they are part of the “production” process in which it is perceived to be a very mechanical mean to achieve something, and certainly, more often than not, they were not part of the stage where a business or product gets formulated. Most of the briefs we have as designers always come from such people called “stakeholders”. They probably had meetings in the ivory tower or somewhere in the mountains and only after they have a pretty solid idea of what they want, they begin to hire designers (and engineers, project managers, product managers, and the whole team saga).
This presents us designers a very nerving situation where our problem-solving skills are limited to answering the client’s predefined needs. We don’t have the opportunity to challenge the needs, the wants and the vision of the “clients”, because, well, uh, they paid us to do this job?
In the end, people always think designers are just the same as mechanics, and even worse, drivers on a car who don’t get to decide where to go. After all, that’s how business works, right? I pay you and you do work for me as I wish!
As a designer myself, I face constant challenge everyday where most of my design work is mostly client-driven, and this thing, although fun in some regards, is highly dependent on the quality of the client and the product. Once you lose passion or face a problem in that particular environment, you are tempted to move on. Thus, many designers I know are constantly job-hopping or going freelancing. They’re on the constant search for that “perfect environment.”
Thus, I am offering a little bit of solution here, both for companies or clients and the designers themselves.
For companies or clients, I think you should provide designers a room for mistakes. Even if you have a solid product idea, expect to get challenged. Challenge is good for your product to be improved. It also shows that your designers get excited and want to contribute more than just answering briefs. Even better: present your design team with a set of problems than a set of solutions. For example:
We need to find a safe & feel-good way to pay online.
That’s completely a different perspective than if we present the designers this brief:
We believe prepaid cards are the best way to pay online. Data X shows this is how it’s done in the US. We want to try here. Can you design an app for that?
The key difference is that one is an open-ended question, and needs research and validations, the latter one is already a conclusive statement (if not to say assumption).
It’s certainly easier to make-pretty a shitty idea, and if the product fails, blame it all to the designers & engineers who “didn’t do a great job”, and continue moving on to the “team search”, than if you engage your team to continually challenge your ideas and assumptions. You’re paying them to make your product better and loved, not to do what you say.
“But, I don’t have time for a trial and error. I have investment money pouring in with a strict schedule.”
Let’s think about this for a moment. This is actually where we all fail. The whole ecosystem is broken. We need to fix it. How do we fix it? By having a decency to convince our investors to have a bit of a breathing space to formulate the best product experience. It’s your job as a stakeholder.
Better yet, a fundamentally good business is always about bootstrapping. Start small. Nobody can build PayPal overnight.
As for designers, it’s our job to continually fight and make things better in every endeavour we take. Sometimes we have to lose it out, but don’t forget that we need to think beyond mechanical work. It is about building our confidence in defining and pushing for the product design process that works and benefits the users at first.
The idea is: A well-designed product is potentially a well-destined business.
This is not a paid endorsement. It’s a journey that I’ve been through. A surprisingly good journey as a customer who bought a pair of shoes. With this pair, I also learned a great deal about good design and user experience.
Meet Skechers GOWalk for men & women. I believe they’re the most comfortable shoes of all the shoe pairs I’ve purchased in my lifetime. If there’s really a good way the metaphor “best bang for your bucks” could relate to, it would be this.
I’ve had a great deal of experience with shoes. Being an avid walker in some points in my life, I have always considered a good pair of shoes a good investment.
By “good”, I always looked at the durability and look.
Although, honestly, in my first forays into shoe shopping, I’ve always looked for the “look” first. Would it look good on me? I didn’t like thick soles. I didn’t like mocassins. I didn’t like slip-ons. I wanted to look cool. I wanted that cool, expensive brand.
But then, many brands failed me. Either they were uncomfortable in the long run, because of rigid design, stiff soles or irritating materials; or they simply have quickly gone out of fashion, or after localising their local design work, the “good design” has simply been gone. Replaced by awkward, tacky and mainstream designs that are out there everywhere. Even the more expensive brands like Campers didn’t impress me in the long run. They were making my heels painful to wear after hours of use. For a more “polished” look, I also have some slip-on or tied leather shoes. But again, these formal shoes are never for longer use. They’re either expensive or good-looking, but never comfortable in the long run.
One more thing: laces. I used to think laces were cool, until I had a baby. More often, you don’t really have time (or want to) tie your shoe laces. It’s not a difficult thing, but something I’d rather not do, especially when I’m in a rush. In the morning, when I am about to go to work, I’d rather spend a little more time with the baby than doing shoe laces. In other people’s homes, I don’t want to find a place to sit just to tie and untie my shoe laces. It’s becoming a cumbersome chore.
So, I’m in the look out for a good pair of shoes that are comfortable for longer use and more intensive walk or run, don’t have any laces, a relatively good material and a relatively good-looking shape. Design-wise, it should not be focusing on fancy, but rather on function and timelessness.
Skechers GOWalk is a wonderful invention that solves most of these problems.
Skechers GOWalk is a casual shoe product that is made of “a lightweight FitKnit mesh”, “memory foam padded heel” and “high rebound cushioning for comfort and durability”. That’s what they write here.
What those mean and how they make me feel are actually hard to describe in details.
In essence, a combination of those really fit my feet and habit well. It feels like walking on a soft, slightly bouncy mat everytime, without losing your momentum or speed. After fivehours standing or walking, you don’t feel any pain at all, unlike the other shoes which have a flatter sole design, where your heel almost instantly interacts with the floor or surface.
The best thing about it is it’s a slip-on, with flexible entry, which means you can just get your feets inside both easily without having to fix or tuck the back of the shoes. One or two slips and you’re off. No fuss.
If you feel like liberating your feet for a while at work, feel free to do so easily. Slip on anytime swiftly if somebody fetches you for a meeting. Take it off easily again if you’re in a meeting room that requires you to free your feets.
Because it’s not a sandal, you can wear it for client meetings, no problem.
It’s this flexibility and “non-intrusive-ness” that appeals to me over a long run.
So far, it’s the best one-size-fits-most shoes that I’ve purchased in my lifetime. Design-wise, it might not impress the very discerning designers or hipsters, but they do have more options if you wish.
My wife actually bought a pair first before me, and I was not convinced the first time. A doctor that we went to for my wife also wore one and he said it will be the only pair of shoes he’ll ever wear and buy. A guy on the plane asked my wife where to buy one of hers because he thought it looked very comfortable. A best friend also wears one.
I think it’s how good design should be: invisibly good. Something that removes a barrier to your life, not add to it. Something that don’t necessarily be noisy in advertising or growth-hacking, but just enough so that it gets noticed. More importantly, it inspires other people to use it, and love it.
I’ve been following up on the design sprint quite intensively in the past few months, particularly because one of my clients agreed to have it after we offered it, because they didn’t know what to do with their product, and needed our help to jumpstart a revamp. Secondly, I’ve been in a volunteer in a national-scale movement to generate a new spring of startups through a series of mentoring sessions, and finally, incubation.
As a designer, I am sure loving the idea of spearheading design in every possible opportunity, especially the idea of integrating design in the core of businesses. I must say I agree that one of the ways for it is through design sprints. However, I must say that we shouldn’t explicitly conclude that the only way to enforce design thinking is through design sprints, nor the idea that it is just another “gimmicky” effort for make-believe.
A specific counterargument I’ve had about design sprints revolved around the idea that any method or process is useless. You know, that “anti-process” movement. Especially, when you “talk to only five testers in the end,” versus the idea of rolling out a feature or minimum viable product over thousands of users, or doing A/B testing in a quick successive way. That design sprints are a “waste of time”, because “we’ve kind of decided what we want to do.”
I must say this to you: Design sprint is only one method of many. It sprung up lately because it is a very lean activity to jumpstart and validate an idea. As you know, idea is cheap, because most of them are assumptions, and we need to validate those assumptions.
The argument against design sprints
If people argue that “it’s a waste of time” and think they’d rather launch the product first and see the feedback from the people who use the product, then I’d say, be it. Launch your product, and see.
Especially, if you have the time, energy and money to do it.
I suspect Google isn’t trying to force everyone to use design sprints, but I perceive it as a way to democratize design so that everybody in the company, regardless of their roles, can contribute to the design decision. For many years, designers have been in the “sit-in” and silent role. It’s a position where other people constantly question why a design decision made.
Imagine this situation: a CEO comes with a brief for a product concept. He constantly blurbs out amazing data and facts—combined with his enduring experience, most likely 15 years in the “industry”—that this product idea will make the next big thing. Sure, he got that investment money and ready to roll. He just needs everybody below him to see his wisdom and look up to him, and do as he says. The engineers, the designers, the PMs, the business guys, all come in and are obliged to take a nod to the Big Vision.
The “resource” team would do their “magic” and roll things out as the Big Vision tells it. No questions should be asked.
The product launches, after millions of dollars spent, and somehow, it delivers, but only in mediocre scale. What went wrong? “My team is terrible,” I believe that would be somehow in one of those train of thoughts by the CEO.
This is where design thinking should come in and hopefully save the day. The CEO could ask everybody to assess his Big Vision and try to see what would work better. Better yet, the idea by the team then will be validated by the users quicker. From 10 possible directions, they could narrow to 3, and their chance of failure is reduced, or at least, they are trying to answer a better question.
Now, if the CEO doesn’t mind spending millions of dollars to validate his idea, then by all means, skip the design sprint part. I am not going to argue against your business model.
Design sprints have been designed to reduce the wide varying answers for the very basic business & product question: will this work for my customers or people who will use my product? It will not produce the correct one, nor the God-forsaken the destiny of your product, but it will help you reduce your choices into the better ones. Nothing guarantees success!
The 5-day format is also designed so that it can be executed in a short period of time, with the most-readily available tools and space, and with the most compact composition of participants as possible. It is just the right size. It is basically a solid answer to the worry that “design thinking takes a lot of time and my company doesn’t have the time or resource to do that.”
Why is it so structured?
Designers and engineers probably think the way the sprint is structured look very rigid, because they’re used to thinking quickly, acting quickly and the most dangerous thing of all: jumping into solutions and conclusions before understanding the problem. I believe, this also applies to businesspeople as well.
Design sprint is designed so that we can all follow the proper problem-solving flow, one thing at a time, so that we find clarity every single day. It is pushing people outside their comfort zone: the easy way, the jumping-t0-solution way, the non-fussy way. Dive deep into the problem, and let it sink over nights. By the end of the sprint, we all find a common understanding, a common clarity.
It is also structured in a way that it accomodates every single type of personality. Every meeting that I’ve been always focused on the extroverts. The worst meetings are when the bosses are the extroverts. The bad meetings are when one of the staff is an extrovert and he pushes his thinking to everyone. With a voice. So loud. Cutting every conversation. This is truly bad for the team.
Design sprints have varying dynamics of ideation: sometimes it’s speaking, sometimes it silent work, sometimes it’s zen voting an idea. Or, call it “brainwriting” if you will. It makes sure that everybody gets listened to. Nobody gets in a way, regardless of their position in the company. A VP of Engineering will not push his opinion against designers just because he talks louder.
I am thinking that while design sprints are not perfect, and that there are many other methods, they are quite versatile and adaptable. If the team is not comfortable with 5-day duration, I’ve seen cases where people do it in 3 days. Although, I must say that, if your team is just starting a design sprint tomorrow, I’d highly recommend that it will be the 5-day one, and see whether the pattern fits your team. If your team is experienced enough and can think through quicker, 3-day sprints are fine.
Just make sure one thing is being done: validating with customers. Without this, your sprint is just another “self-satisfying” session with no purpose to serve the people who will use your product.
Unless you don’t care about the people who will use your product, or you just have a lot of money and time to burn.
I’ve had the privilege to speak about design thinking and process at startups at Tech in Asia DevTalk 2016 at Bukalapak.com’s new office in Kemang. About 100+ people came in, out of 400+ people who registered but waitlisted. I was one of the two main speakers at the event. The other one is Devita Mira Lestari, a UX Researcher from Bukalapak.com.
I spoke about how to best implement design thinking and process in agile environment in startups. Here’s the deck I shared that night.
Thank you Tech in Asia for the golden opportunity!
I spoke at Google HackFair 2015 as one of their talk session speakers. It was full-house and engineers, designers and businesspeople attended that event. I gave talk on how to reduce friction in user experience to help achieve a smoother user journey.
Here’s what I presented on that day:
I started my design career in 2007, when I graduated from undergraduate school of design. I joined Oracle that time designing for a non-profit web platform for schools worldwide.
Even though I’ve been designing for the web since five years before that, joining Oracle was a point where I had to learn how to work in a big organization and working on their digital product(s). The products are not commercial, but still, they managed to develop and maintain it internally and did so very well. I was working remote from Jakarta, with my manager in San Francisco. I thoroughly enjoyed the “remote working” feeling of it, although I worked in the Oracle office in Jakarta. I learned about product development, user interface design (visual design, wireframes, specs), even learned a bit about persona and user experience methods (although not comprehensive). I also learned how to observe the users of my products, students and teachers, by attending trainings (and actually taught them how to use the product). It was both educational and fulfilling. I felt like I was doing a good thing.
Then, I moved on briefly to a national English-speaking newspaper. I helped them conceptualize one of their digital products — a travel site.
My best career move was the next one. I moved to Bukalapak.com, an Indonesian e-commerce that connects customers in a marketplace. Customers can sell items to other customers. Achmad Zaky, the CEO, is a friend and he gave me full trust in revamping Bukalapak. I was not set a deadline. I was given access and freedom to the team to see what we can do with the product. It was a great year. I learned to do product design from scratch, validate the design with the team, speak to customers, work with very smart engineers and a team full of energy. Everybody was in sync with their work. We came to work everyday with passion and a strong sense of ownership. I was learning to use multiple tools to design, including Apple Keynote — who would’ve thought?
The only thing that lacked from my Bukalapak career was I didn’t learn much about how we should develop products: waterfall, agile, scrum… and all that stuff, but maybe there’s a good side —we were experimenting fully with what we thought best for the product at that time.
As a year went by, I yearned to develop my portfolio and learn more about product development. I thought joining Ice House, a mobile development shop, was the right thing. It had everything that I wanted at that time: client work to build various portfolio, smart engineering teams, good employee benefits, and an agile workflow. I learned to continue my design process & methodology, but also learned how to integrate it with agile. I worked with some of the smartest engineers I know. I enjoyed working with clients (I never thought I would, judging by how difficult I am with interacting with people). The team gave full support and respect for me.
Another opportunity came, and this one was an easy call. It was DBS Bank from Singapore. It was perfect. I wanted to work overseas. It was a really good pay & benefits. I was about to have a baby. It was a solid team, with a long designer friend I admired, and a boss who came from PayPal. While I enjoyed my time at Ice House, I wanted to try this before it went away. Ice House offered me to relocate to San Francisco as an attempt to keep me, but I had a baby coming and the financial benefits of Singapore outweighed San Francisco. Sorry, Ice House. I moved on.
At DBS Bank, I learned how to work with large organization again, and to be a “fox” — how to make my way through the organization, justify, seek consensus and generally be friends with the bank team members to push my design through. It was not an easy process. I was frustrated so many times. However, I feel like I made the most progress at DBS Bank, as a designer. What I mean is that I discovered about myself more than in any other place. I also worked with super-talented team members who continually gave me support no matter what. Thank you, there, Chooake.
Now, I am back in Jakarta — helping some companies in starting up products and businesses. Leaving DBS Bank was a difficult decision. My thought that time was I want to take ownership of my work more and live a simpler life. I want to feel better & happier in general. I was burnt out. I was worried if it was a totally wrong decision. It might have been. Sometimes I feel that I regretted doing it, especially for my family. It was a solid company with good pay, and a good team. Maybe the way I coupled with things was a little wrong. But anyway — here I am, in Jakarta, back at home, with the baby and wife. I would like to make the most of my time while here in Jakarta.
It turned out that by opening myself to opportunities, those opportunities really come to me. Some freelance works came. There are even full-time job offers.
It seems that as a designer, it’s a good time to be alive and working, and I will not worry about not having anything to work on.
Things are getting better.
Designers are often misunderstood in several ways, especially in a company setting. They are perceived as rebels, misfits, or generally a bunch of people who are hard to work with. “Why must we consolidate with designers? Why must they decide what goes on in the page? Why must we hire them?”
Companies that are not design-driven often have this struggle. Engineering-driven companies think everything should center around engineering, and they reward engineers the most, and hire engineers the most. Business-driven companies think everything should center around business, and they reward businesspeople the most, and every other things must follow them. Designers don’t always get the fair share of voices, because they are executors. Only a few companies really care about design and put designers up top in the top level management. It’s hard for designers to make a change if they keep being in the “lowly” levels. They should be part of the strategic levels.
So, why are designers often perceived as rebels? Priorities, priorities, priorities. I’ve had a friend who works as a design manager in a corporation and when he participated in a managerial-level training, they were asked, “What motivates you everyday to work?”. There were businesspeople, engineers, designers and administration staff in the room. Most of the people wrote “money” as motivation. The designer friend wrote “to make a good product”. While money is important, designers come up to work daily not to pursue it blindly: they want to make good products and be known for them. We have a portfolio to build, not just CV, or sales numbers. We want to show case studies, how we succeeded in solving problems with design, and that we carry on towards the next companies. It’s not enough to just think about numbers of years we pour into a company or product. It’s more about what we achieve. To achieve it, of course we need money, but it’s not the goal.
I think this is where the problem lies. Designers care about the product more than anybody else, who mostly think they work just to survive the months. We work towards a life-long goal of being good designers who solved real-world problems, and have a design portfolio that we can be proud of. You can’t talk to designers about career progression only. You can’t talk to designers about key performance indicators only. You can’t talk to designers to go about pleasing anybody, including clients, only. Our work and life goal intertwine, and that is bigger than the sum of all parts — career progression, KPI, making clients happy, bringing in revenues, and most importantly, we breathe in and out everyday thinking about the users of the product.
Hey, travel sites, booking sites, any reservation sites:
What’s up with the small datepickers in desktop websites? Why restrict clicking area while we have big screens today? Are you worried that users don’t see anything else? But, isn’t the primary action for that particular moment is to pick dates?
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.