The Framework: 5W1H (with a twist)

Let’s start with a simple framework of project information gathering, then we can drill down into some fun stuff like where’s the pitfall, what techniques could be useful. The basic framework I’m introducing is the classic that’s taught in project management books: 5W1H, stands for What, Who, When, Why, Where, and How. You’ll need to know WHAT you’re try to build for WHO, and WHEN it needs to be done. More importantly, WHY are we building it? Then the implementation details like WHERE the end result is gonna be delivered (e.g. mobile app? other distribution channel?), and HOW it’s gonna be build (e.g. what kind of technology?)

You might have heard this 5W1H framework numerous time and are good at it. What I’m going to do is to bring in a bit of twist in it. The other side of the 5W1H, a team-focused, productivity-driven version of 5W1H analysis.

WHO are the contributors and decision maker

Assuming as a product manager or UX lead, you probably spend lots of time to expose to users in order to get the best insights out of them in order to make great product or service for them. However, just knowing what the users want doesn’t guarantee that you can create what they want. A lot of times you need to get the internal approval before you can launch a product to the market. Or if you’re in a startup environment, you’ll need to know where the funding comes from and how to get the next round of them. By knowing who the decision makers are and how they think, you will get a better chance to persuade them with your big plan.

As Aristotle’s rhetoric taught us, people have individual differences and they think differently. By knowing who you need to convince and what type of people they are, you can choose your way to approach them accordingly.

HOW do we work together

If you have ever worked in a big project team, you’d know how important the collaboration model is. I once worked in a project that consists of 4 product managers, 6 business analysts, 3 tech analysts, 4 UX, 5 SMEs, and 40 engineers. Without a clear collaboration model, what actually happen was lots of time people were just busy trying to find the right person to talk to in order to move things forward. For example, some engineers didn’t know that interaction designers only deliver wireframe but not visual design; or a UX didn’t know the difference between business analyst and tech analyst therefore kept asking the wrong questions.

In a situation like that, a RACI matrix could be very helpful to communicate “who’s doing what”. Below is an example chart of RACI matrix:

As you can see from the figure above, it clearly points out who’s responsible for what tasks, and where the accountability lands on, or who needs to be consulted or informed. A typical question that I’ve been asked a lot: what’s the difference between responsible and accountable? In Wikipedia’s definition: “Responsible” are those who do the work to achieve the task, and “Accountable” are the one ultimately answerable for the correct and thorough completion of the deliverable or task, and the one who delegates the work to those responsible. Simply put, responsible is the doer, and accountable is the delegate-er/approve-er.

WHY is it important for the business

Now that we know who you need to work with, it’s good stepping stone to get to know what everybody wants from it. It’s one of our most important responsibilities as a team member to capture the business value through our delivery. At the end of the day, unless you’re a business owner, we’re all hired to achieve a certain business goal. By working as a team with the business side and technology side, we will be able to achieve greater good with the combined knowledge and expertise. Simply sitting down with the business partners and discuss the goal they are trying to achieve helps inform better design decision and align the delivery to the business vision.

In terms of how to make it happen, I found Google’s OKR framework helps facilitate cross-disciplinary goal alignment. Other tools like Service Design Impact or UX Strategy Canvas also help outline the value proposition that’s key to success.

WHEN are we going to test and enhance

Now, moving on to the details. Since we know the high-level goals, the next question will be, how do we make it happen in a given timeline. How do we allocate the resources? Do we have a product roadmap? If yes, does it make sense to you? If you’re lucky, your product manager will consult you before s/he finalize the roadmap. If not, you might see a roadmap that didn’t account the level of effort from either the UX or tech side. As a UX practitioner, I try to work closely with the product team and tech team in order to construct a meaningful and feasible product roadmap. By meaningful, I meant seriously considering the release strategy that help us gain the best insight from our customers without risking too much of brand value. By feasible, I meant considering the actual effort in order to GOOTB (Get out of the building, test your product in the market).

With a better understanding of release strategy, the team can plan the effort in order to achieve separate goals in beta version, MVP, etc. For example, the UX team might sketch out the rough idea of the framework for the full version of the product, but only focus on the detail interaction for the beta of MVP release. The tech team will get to know what’s needed for the short term and work on the back end or middle ware strategically, so that it support the features in the earlier release but in the mean time scalable for the future releases.

WHAT do we want to learn (through user testing and product release)

From the UX side, there are many different type of research tools that can help us learn more about how users see/ use our product. In order to communicate the value of the data to the product team and tech team, I found Google’s HEART framework very handy.

The HEART framework help explains why the metrics are important in a non-UX-textbook way which can be easily understood by the business and tech team. Therefore, UX researchers or data scientist can focus on their great work without worrying that nobody understands the value and the impact of their work. This is not only important through per-launch user testing or beta test for qualitative feedback, but also for setting up the analytics metrics so that we can capture quantitative data.

WHERE do we pay detailed attention to

Often times we utilize different methodologies, design frameworks, in order to strategically deliver meaningful results. For example, if we’re designing a new product that requires lots of exploration, we might choose IDEO’s Design Thinking framework which emphasize upfront user/ product research, and prototyping/testing before product release. In my previous post, we discussed that it’s quite important to understand what type of project we’re dealing with, and carefully choose how to approach it effectively. One of the valuable things I learned throughout these years is that you will need a big UX toolbox in order to work with your stakeholders, your tech team, and your own UX team members. For example, some of the UX team members are eager to do more research work, and some would rather spend more time on iterating different ideas. Some of the stakeholders need to see pixel-perfect wireframe, while some others are happy with a napkin sketch for idea discussion as long as the prototype or build looks tight and neat.

Knowing how to meet stakeholder’s expectation is half way there of getting approval or funding. Some care about the big idea or break-through concept, some care about the aesthetic of delivery, some care about the way you communicate your progress/ process (e.g. present more than one ideas with pros/cons analysis), and some care about the implementation details (like typo, or the accuracy of sample data). As the driver of the project, the leadership really relies on how much you care about the team and stakeholders and how to motivate them to move toward the vision.

Summary

Obviously it takes time to figure out all the details you need to know as a project leader to drive the project with efficiency and efficacy. If you’re willing to spend some time to listen to your team, understand how they work, and provide the platform and environment to work happily, you’re not far from success. As former Apple CEO Steve Jobs famously said “it doesn’t make sense to hire smart people and tell them what to do; we hire smart people so they can tell us what to do.” It’s our role as project leader to figure out where to look at and pay attention to details, in order to remove the blocker and move things forward.

What are some valuable lesson you learned through your project experience? I’d like to learn from you.

Image credit:

http://www.smetoolkit.org

https://www.pinterest.com/pin/158400111870081322/

https://interaction-design.org/

https://open.buffer.com/

http://mikewiggins.design/napkinsketch/

Cover photo by: rawpixel.com

Paint by Numbers

Let’s start with the easy one, Paint by Numbers. For readers like me who’s still learning western culture, paint-by-numbers refers to a children activity in which children will use crayon or other colorful drawing tool to paint the picture with colors that follow a sequential order (e.g. 1 is red, 2 is orange, 3 is yellow). Since it’s an activity for children to follow simple orders, Eddie Obeng uses this analogy to describe that the type of project that is  fairly simple, and participants just follow the existing rule to complete the tasks.

A typical Paint-by-Numbers project is something that the project goal is clear, and the method or process to achieve the goal is familiar enough. In short, low risk, no surprise. It doesn’t require much effort around understanding the requirement, nor finding ways to gauge if the problem is solvable. Therefore, mostly the effort is expected to spend on perfecting the quality of product, process, or services

Back to the UX design world, a Paint-by-Numbers project might be a good chance for several things: to test out your new hired employee, an opportunity to mentor junior designers, also good for  the team to try new process/tool/concept, or simply serve as opportunity to “breath” if you just finished a big project. I once leverage a Paint-by-Numbers project to test out new process like Google Design Sprints with a team that’s eager to learned new design process, and as a result both the team and the stakeholders are satisfied with the results.

Pro Tip: Since a Paint-by-Numbers type of project usually is easier to lead, often times the emphasis is around how to get marginal gain compare to existing process or product. It’s important to find a way to make the project exciting to the team so that the morale can stay high and the quality can be ensured.

Movie

When you’re equipped with all the skill set you need to tackle most types of projects, you might find yourself in a situation that you’re ready to go, but your business partner and project leadership team doesn’t really know what the direction is; And that’s what we called a Movie project, in which you’re ready to go but just don’t know where to. The reason why it’s called movie is that, think about the movie industry in Hollywood, you have all the great talents in town, all you need is a great script to start rolling the camera, but you just don’t know where that golden script is.

In a movie project, it’s imperative to help the project leadership team to clarify the decision as soon as possible. At the end of the day, nobody wants to see their work being thrown away simply because the direction is not clear. If the root cause of not having clear direction is because of communication issue, Google’s OKR methodology usually helps team member to communicate goals and key measurement. However, if the goal is not clear because the business reason, you might want to evaluate the cost and risk of kicking of work without having a clear direction, and communicate back to the stakeholders as soon as possible

In the UX world, we sometimes get unclear requirement in which the business value or users expectation are not clearly communicated. Especially in a waterfall process without savvy UX team leading the conversation, UXers could be treated as “talents that put lipstick on a pig”. It’s our strength to utilize design thinking to help stakeholders think through the value proposition of the product, and it’s our responsibility to urge the business side about the importance of clear goals.

Pro Tip: A workshop with the stakeholder, with some root cause analysis like 5 whys or Fishbone diagram could help sort out the problem statement, and using affinity diagram could help prioritize the issue therefore come up with great business opportunities. User research also helps to find the pain points and new ways to solve things.

Quest

Quest project happens when your stakeholder has a brilliant idea that’s totally different than your day-to-day job. You have a clear high level goal, but you’re not familiar how it could be achieved. And the reason it’s called Quest is using the metaphor of a dragon quest: You know you have to eliminate the dragon as a clear goal, but you don’t know what kind of danger you might encounter in a huge dungeon or maze, therefore it’s hard to prepare for.

It reminds me a TV show I recently watched on Discovery channel, called: “Phelps vs. Shark, Great Gold vs. Great White”. The show is about letting Olympic gold medalist swimmer Michael Phelps to compete with a shark to see who swims faster. Seems pretty clear, isn’t it? But how exactly are they gonna make that happen? Do they just swim together in a Olympic standard swimming pool? with salt water or not?

Since you don’t know how exactly you can achieve the goal, inevitably there’s an element of experimentation in it. What you might want to do is to limit the risk of the experimentation(s), by using a lean and agile approach. More prototyping to verify what works and what not, breaking down a big chunk of task into smaller testable tasks to get early feedback, and a clear communication channel and documentation to report back to the team and stakeholders, so that you can swiftly adjust your approach before it’s too late.

When we encounter a Quest type of UX project, we tend to do competitive analysis and see if there’s any resolution has been done and proven successful. Also we might look outside to see if other industry have solved similar issue in a creative way that we can leverage. After exhausting the options above, we will try to set expectation with stakeholders to let them understand that this is going to be a trial-and-error process, but we can utilize Lean UX and other agile methodology to learn fast and adjust quickly.

Pro Tip: A picture says a thousand words. By having white-boarding session or create mock-up, prototype, it helps stimulate the conversation so that the team could potentially discuss different ways to solve the problem. Early-stage brainstorming session also helps us look at the problems in different way, so that when we realize one direction/method doesn’t work, we can quickly adjust.

Fog

Probably the worst scenario you could image: You don’t know where you’re going, and you don’t know how to get there. Needless to say, it’s frightening, no one wants to be this situation, and everyone just wants to get out of it as soon as possible.

When you encounter a fog project in which there’s no clearly defined goals, nor you can image how we can possibility get there by leveraging existing process and skill-set, the best thing you can do is spend more time on communication. Sometimes there’s could be a hidden goal that hasn’t been explicitly communicated. By engaging more with stakeholders, you could potentially move a Fog project into either a Movie project, or a Quest project

In the UX world, thankfully Fog projects rarely happen to me. A lot of time the issue could be resolved through clear communication. However, in a large team that everyone has their own agenda, or a hierarchical organizations where asking questions might not be encouraged, Fog project could happen. It’s important to reflect to the team of the risk of having a Fog project, not only for the project success, but also the potential damage to the team morale. I’d use the combined skill sets for Quest and Movie project solutions to ensure clear communication among silos, and small experiments quickly adjust to define the best approach

Pro Tip: It’s hard for anyone to be stuck inside a Fog project. In that scenario, constant support for the team members and the team morale becomes the top priority. Having in mind of the damage that’s caused by the uncertainty of the project, constant communication to the team to maintain the morale, also showing progress of getting away from the Fog nature, will help your team to stay longer with you.

Do you have any interesting stories about your project experience? I’d like to hear from you.

Photo Credit:

https://sarahlulabella.wordpress.com

http://maxvision.us

http://hjh.hardee.k12.fl.us

http://www.tabletopgamingnews.com

 
João Silas

Here I listed out the 10 If we review the typical heuristic evaluation criteria from Nielsen Norman group,  in which we use quite often to evaluate a graphical user interface (e.g. website, mobile app):

• Visibility of system status
• Match between system and the real world
• User control and freedom
• Consistency and standards
• Error prevention
• Recognition rather than recall
• Flexibility and efficiency of use
• Aesthetic and minimalist design
• Help users recognize, diagnose, and recover from errors
• Help and documentation

The criteria above still stand for a conversational user interface. We do want the interface to be somewhat similar to how we typically understand the world, and there should be some consistency so it’s easily learnable. Also, we want the system and interface to be smart enough to prevent some common error, and when the error happens, we need the interface to help us out. Seems essential, isn’t it? However, certain criteria might be hard to meet in its full potential due to the limitation of verbal communication. For example, comparing to a dashboard page on a website where users can see multiple charts at the same time, the linear nature of conversation limits itself to provide information in a time sequence with spoken language. In short, you can’t say five sentences at the same time.

There is some fundamental advantage of adopting CUI, but that also comes with limitation of it. Therefore, I’d like to share with you a list of Design Principles which I found helpful when designing a CUI.

Say it like you mean it

Let’s start with the fun part, how do you make sure it’s a enjoyable experience with your CUI? There are some high level principles:

1. Personality: It’s important to bring a delightful experience to users ears. When we think about the expert in talking without being seen by us, radio host in general do a pretty decent job. At what point the host needs to stimulate positive emotion, and a what point she should be just quietly listening to the call-in. It’s more of an art then science!
2. Keep it brief: A chatty CUI might be good for a relationship-focused application, however if you’re trying too hard, you might easily find users’ frustration all over
3. Show me the options (money): Especially if the CUI is treated as an agentive technology with task-focused functionally, not only we want to avoid chatty interface, but also we want to be transparent about the options/capability so that it’s clear to the users what she should expect from the interface. Pro tip: don’t provide more than 3 options, it’s proven in psychology that humans short term memory is not that powerful.
4. Examples are better than instructions: When applicable, provide actual examples to replace verbose instructions, people tend to get that faster.
5. Practice makes perfect: In general there are two main dominant way to design the utterance for a CUI. For one is the Google way, in which the team will make assumptions and build prototype and iterate on that. For the other is the Amazon way, in which, to my understanding, is inspired by Turing Test, where the developer will sit in another room across the users’ room, and fake the computer response in order to converse with the users. Therefore they can quickly capture users reaction if the utterance work for the users or not. No matter which way you choose, it’s essential to keep the iteration going in order to achieve acceptable quality of conversation.

Devil’s in the detail

Now, the biggest challenge of CUI design usually falls into the error state and edge cases. To make it worse, it happens quite often. Some examples are listed below:

1. Dis-fluency: People do self correct, and they change their mind quite often. For instance,  you might hear users say: “Give me two– no three sodas”, or “Tell me– oh never mind”. This is a bit hard for the certain system to process without a careful system design. As a designer, the way we could solve this is by constructing dialog with mixed-initiative (e.g. collecting two pieces of information using a single prompt), combined with directed forms. This makes the dialogue more concise without many steps and therefore user might feel less cumbersome and close to natural human conversation. Pro tip: Avoid addressing disfluency through the structure design of grammar, for it might result in big increase of the grammar complexity therefore the recognition process slows down.
2. Error amplification: Not only people correct themselves, but also they pause in the middle of sentence, in which the system might recognize it as the end of sentence. Imagine a scenario as below:

User: “I’d like to…” user pauses

System: “I don’t under…”

User interrupt the system: “I’d like to buy…um…” user pauses again

System: “I don’t und…”

User interrupt the system again: “I’d like to buy forty…” and user pauses again

System: “What do you…”

User interrupt the system again: “I’d like to buy forty cups of…”

For scenario above, designer can come up a smart system which includes some SAFE points, e.g. high-level menu, so that user and computer can resynchronize turn-taking and get a fresh start.

3. Exit strategy: Just like a phone conversation, you probably have the experience that the person on the other end of the call hung up the call for no good reason. Similar to that, it’s hard for us to predict why and when users would leave the conversational process on the interface. Therefore, an exit strategy is important. Whether is a back button for users to go back to previous stage, or a quick access to the option menu, these are extremely important when designing CUI.

4. Context is king:  Without a great understanding of the context of what users are thinking about, sometimes it’s hard to fully comprehend what users are referring to. For example, the phrase Forty Time could be interpreted as For Tea Time (A British user?), or For Tee Time (golfers probably get it this way). It’s important to structure the conversation so that the system can understand the context as early as possible. Don’t be shy to ask question to the users, it eliminate a lot of undesired situations.

What’s your design principle for CUI design? I’m happy to learn from you.

P.S. Some of the principles are coined from the book [Spoken Dialogue Systems] By Kristina Jokinen, Michael McTear. Great read.

Photo credit:  Jason Rosewell

Where Lamborghini Goes Wrong

In the figures above, the show host Richard Hammond was describing his last thought about the new Lamborghini Huracan, after his praise of the great performance of the same car. You can see how disappointed he felt, regardless the great technology and how the technology creates a smooth and precise driving experience. The way he later described it was: “Now, as a car, this (Lamborghini) Huracan is probably better than all those other Lamborghinis, but those cars are better Lamborghinis. The other Lamborghinis make you feel special, even in traffic. This doesn’t, and that’s a loss.” So, where did Lamborghinis go wrong?

In the book of Emotional Design by Dr. Donald Norman, he gave one great example: “People pay money to get scared. The roller coaster… they enjoy the high arousal and increased adrenaline rush that accompanies danger.” Lamborghini is know for being one of the most dynamic, wildest, and strongest super sportscars in the world. However, it seems like the new Huracan doesn’t really follow the same path as its predecessors. I wonder if the project lead of Lamborghini Huracan have seen what Dr. Norman wrote, would he still make the same decision, to make a tame Lamborghini? Interestingly if you visit Lamborghini official website, one of the tag line on in the hero area says: “DARE YOUR EGO”. To me, it doesn’t seem to be the way the host Richard Hammond feels about the new Huracan.

With the great design, technology, user friendly features, Huracan might have just missed the spirit of Lamborghini, which is essential to the brand and the customers. I’ve seen this before too in some UX design projects. And how did it happen?

A bit of UX 101

I believe if you’re a UX practitioner, you’ve probably heard of The Elements of User Experience by Jesse James Garrett. In the diagram below, Mr. Garrett illustrated the fundamental element of UX: Strategy. Although we address the importance of it in our mind, I’ve seen many projects just treat it as a good-to-have in theory, rather than putting it into practices. Sometimes projects are short-period, lack of funding or resources, or the client just wants some facelift type of work, in which I understand why design services maybe treated as plumbing services (in and out, finish the work and forget about it). However, if you have a bigger project you’d like to take on, and the result is so important to you as a designer, you pretty much have no option except for thinking through the general guideline of the project, to ensure the direction you’re heading is not far from what users’ expectation. That’s where we realize the important of the project north star: Design Principle.

Some might think that UX is the same as UI, and some might say UX is about wireframe and workflow, and some might argue that UX is just the same as HCI or Human-Centered Design. In my humble opinion, they are all part of the holistic user experience, the only difference is the emphasis around the individuality/uniqueness of the users. In order to get the UI right, get the interaction right, we need to find a way to have a plan to flesh out the right design principles that are bespoke to our target users.  In the car example above, there’s no fault to build a high-performance and safe car with the serenity while driving. However, this description could fit a Bently buyer’s needs pretty well, not much as for a Lamborghini owner.

In the book of Emotional Design, Dr. Norman also mentioned: “Designers can get away with more if the product is fun and enjoyable.” Different types of users value different things, and for designer it is crucial to transform those user knowledge to our design through design principles. One of my favorite UX experts, Kim Goodwin, made a great point about why design principle is important and how to embed it in a project work.

Are you ready to make a change? Tired of constant trial and error? Let’s get your design strategy right, come up with a set of design principles, and do your design work based on it as a efficient way to get to success.

Photo credit:

https://www.topgear.com/

http://www.jjg.net/

Brainstorm with Star Wars Characters

Running out of ideas? Feeling stuck in a brainstorming session? Star Wars figurine is here to help! I was inspired by the book of “Great Idea”, and I developed a brainstorming technique which I named “Telepathy”.  The idea is to generate new ideas through empathy, by putting yourself in other’s shoes so that you can have a different mindset, and consider the problem in their views, their situations, in their daily life. So how does Star Wars play in the “Telepathy” technique?

When I’m running a brainstorming session using the Telepathy technique, I’ll bring 3 Star Wars figurine: Darth Vader, Luke Skywalker, and Yoda.

First, Darth Vader represent the role who has almost infinite power. He’s a great warrior, holding a high position in the empire, he can do anything he wants and almost no one can stop him. When you telepath with Darth Vader, you start to see things differently. Because you have unlimited power, you can free yourself from pre-existing scope or scale (since you have the power to blow up some planets you deem “undesired”). You can also delegate task to other people, or a robot, so that you can focus on important things. When putting Darth Vader in play, people will come up with ideas like automation, API, reprioritized tasks, dark pattern, or simply a powerful message or visual to “blow user’s mind”.

Next, Vader’s son, Luke Skywalker. An ambitious young Jedi (not anymore, I know) grew up in a distant farm, Luke traveled far in the universe to fight the evil empire alongside with the Rebellion. With the mission of gaining peace and the new order in the universe, Luke trained hard and fought hard with very little resources. However, he’s loved by others, with a great hope to restore the peace in the universe. his talents help him blow up the death star, and eventually defeat the Galactic Empire. When we bring Luke Skywalker to the brainstorming session, we often user our empathy to picture ourselves in a tough environment with very limited resource.  We often come up with ideas like:  dashboard, training module, social share features, etc.

Last but not least, one of my favorite character, the wise master Yoda. Once being one of the most powerful Jedi, Yoda is seeing himself in his later days when he met Luke Skywalker. Without his youth and physical strength, he’s walking with a cane, or carried around by Luke, and often relies on verbal instruction when teaching young Skywalker. What makes Yoda important in the brainstorming session is that he reminds us to design something that’s inclusive, consider different sets of needs like accessibility. Ideas that are inspired by master Yoda often includes: voice/ conversational UI, contextual help, wizard, coach mark, simplified workflow, and of course, ADA compliance.

Verify Your Idea with Rubber Duck

Once in a while, you might find that you’re in a situation that you can’t find any other designers around you as your sounding board. For example, you might be at client site working as a consultant, or let’s say, you’re the only one who take vacation during holiday seasons. What happens if you want to verify your idea but walking through the concept with someone? Rubber Duck comes to help!

Rubber Duck Debugging is a technique I often borrow from the software industry. Based on the definition from Wikipedia: “In software engineering… a programmer would debug their code by forcing themselves to explain it, line-by-line, to the duck.” This is a very helpful technique especially when I’m designing a rather complex workflow, in order to capture missing cases/ screen. For example, when designing a user login workflow, if not being careful, it’s easy to miss some cases like forgot user name, new users instead of existing users, users didn’t click on the link from the email within X amount of time, etc. Just by explaining my wireframe/ story board to a rubber duckie, I found myself often captured those missing screen that I forgot.

In my experience, Rubber Duck Debugging is also a good for mentoring junior designer. It’s a helpful totem as a reminder about the quality of deliverable. For example, when we produce  important presentation to a new client, I asked junior designers to make Rubber Duck Debugging as mandatory process, in order to self-check the quality of presentation. It also helps them develop a good habit to care about the details.

How to do it? There’s a youtube video for it!

More Ideas from Justice League

As described in my other blog post “UX is like Justice League“,  you can borrow superheroes’ superpower when you want to solve new problems. Also it helps you align yourself with the mission of doing meaningful work by helping users. What’s your favorite toy? Could you think of a way of using it to boost your productivity?

Photo Credit:
https://cdn.discoversg.com
http://assets2.ignimgs.com
http://static2.businessinsider.com
http://static.srcdn.com
http://www.revolumia.it

Without the intention to promote the upcoming movie, 4 years ago I started to have this idea of working as Justice League to solve UX problem.

Knowing himself is just a regular man without superpower, Batman analyze his opponent, work with his team to develop gadgets and tools so that he can use to  gain competitive edge in a combat and solve crime. Being a UX designer we are constantly put in different situations. Some client requires Lean UX style which involve lots of white boarding, some large clients request for very detail functional specifications, and while others ask for interactive prototypes. Just like Batman, we also need to develop different weapons in our toolbox in order to successfully deliver.

Unlike the way other superheroes fight, which is come in and storm the enemy, Batman first analyze the situation, and has the patience to be in the stealth mode, and taking out his enemy one by another. This reminds me of being a UX designer. When I am in a big project, it’s impossible to come up with meaningful solutions right away. Lots of planning is required, so that can figure out what the most urgent problems are to solve.

The best part I loved about Batman is put emotion aside and stay calm to analyze the problem at hand, and solve it quickly. No wonder people gave him the praise of “The Greatest Detective” in DC comics (in case you wonder, the word DC stands for detective comics).

You can’t mention Batman without Robin, or at least, I can’t.

Arguably the greatest sidekick in the world, Robin helped Batman solved countless crime. Sometimes the situation could be sticky because Robin thought he could solve the crime on his own. Sometimes it works, sometimes it doesn’t. To me, it’s key to understand my role in a team. With the gain of seniority, most of the time I’m in the leadership team to help guiding projects to stay on the right track. However, I remind myself to still be supportive as a sidekick when needed, and stay fresh and open minded when generating new ideas.

With a bit of impulsive personality, Robin often unintentionally becomes a pain in the neck to Batman, but sometimes that part also helps Batman solves the problem from a different angle. Being a UX designers, we all have great ideas that we can’t wait to make it happen. However, I try to remind myself that the success of a product or service is not merely from a great user experience perspective. A reasonable price, fast to deliver to the customer before our main competitor does, in certain situation it could be even more important to the greater scheme. Working as a team is all about being honest to each other, and equally important, being respectful to each other’s value.

Superman

Unbiased, big heart, strongest man of the world. Even when he discovered that he’s an alien, he still choose to stay and protect people who he never heard or met.

Needless to say about his superpower as man of steel, his other powers includes. X-ray vision to see through walls, heat vision like a laser to cut rocks in half. As a UX designer, we can borrow Superman’s power to see through the situation and find out where the real problem is, also be able to dissect the bigger problem into smaller and solvable tasks.

Another aspect is that, it’s inspiring that how Superman can endure all kinds of pain and hardship, whether it’s from the enemies, or from his own folk. While dealing with these tough situations, he still reminds himself not to abuse his power. As a designer, we have to interact not just the users, but often time our stakeholders, tech team, even fellow designers. Situation could be tough, but as a great leader as superman, we’re expected to deal with all kinds of situations, whether it’s apocalypse or when Robin had a fight Batman and ran away from the Justice League.

Wonder Woman

Just being very honest, I didn’t have much exposure to the character setting of Wonder Woman, therefore I can only describe from my limited knowledge from 30 comics books and the movie about her.

With the great heart to help, Wonder Woman stepped out his comfort zone of Amazon, and fight alongside with human. It’s not easy to relate to people unlike you. When I work with stakeholders and tech team, I learned that I have to somehow speak their language in order to truly collaborate. I started my business training on Coursera, I got my Java programing certificate, just try to make sure I can empathize from their point of view.

With her powerful wrist wrap, she can defend herself from various attack. Working in various design project, although unlike the real battle field, sometimes you could vision various attacks from experience. Different types of opinion, mostly constructive, but could be mean and pointless. Before a client presentation, I try to picture what could go wrong, where the potential problems could be, and prepare myself before it happens. Lots of debates come from different value system, I try to understand why and how people think, and respond with empathy and reasoning.

I’m a fan of her Lasso of Truth, it’s a rope that force enemies to tell the truth when she wrap it around them. As a UX designer, it’s my belief that the more we know upfront about the users, the product, the industry, and the stakeholders, the higher chance we can ensure the project success. It could be hard to get what user really thinks if we don’t step out of our office and talk to real users, and that’s what I’ve been striving for: Upfront user research, prototype and user testing, and post production evaluations.

Green Lantern

Last but no least, the most creative heroes who fights enemies with solidified illustrated objects (e.g. a rendered hammer in the air to smash his opponent)

Lantern has a lot of issues, just like some other superheroes. But what makes him great is that his young heart and wild imagination which helps him create fun and powerful weapons to fight crime. At the end of the day, who doesn’t want to have some fun?

What I appreciate about Lantern is his relentless mind of creativity, and determined to his mission. Often times we face hard choices in our lives, but Lantern never has a second thought. Being brave, being creative, he’s undoubtedly one of the most valuable team members in the Justice League (and the one I most often borrow superpower from).

More heroes

The Flash, who can act fast, and learn fast; Martian Manhunter, who has the  power of shape shifting, to put himself in other people’s shoes (developing empathy); There are more than two dozens of heroes in the league that I won’t list them all out. But I’m curious who you like best? And why?

The Myth

When I was working in ad agencies, people warned me about the two behemoth industries to work as a designer: Finance & Pharmaceutical. Yet, I worked on both, and I choose to stay doing UX for Finance for more than 7 years. You might ask, what is Roger thinking?

To give a better explanation, it’d probably make sense to first explore why designers dread these two industries. I asked around to see why they dread them so much, and I soon learned why. They seem to think that: 1) both of them are highly regulated, which implies that there are potentially many undesired rules to follow; 2) the content in general is very hard to comprehend, therefore it takes a lot of effort just to wrap your head around it; 3) the products are usually not so as excited; 4) the product or services could be very specific to certain types users, therefore it’s hard to relate to.

These opinions make sense to me. In short, it’s hard. It takes quite an amount of effort and it might not yield anything that you can easily explain to your friends and family. It takes huge amount of dedication just to learn about the product, the industry, the workflow, before you can contribute any meaningful work. You somehow need to learn the language, jargon, being able to talk to the users while they are either unreachable, or unwilling/incapable to cooperate (I’ll explain below). Often time, the complexity of the job also scares away people.

Greater Ability

So why would any designer want to work in finance? To me, it’s simple: harder challenges yield better reward. If you’ve master a 300 piece puzzle, it might make sense that you’d want to challenge yourself to harder task. For me, designing in finance is the case where I’m finding more and more joy every time I take on a new and harder challenge. The great complexity in institutional finance could be overwhelming for new joiner (see figure below), but that’s also the interesting challenge that gain you as a valuable asset as your competitive edge.

(Image of FIX protocol)

Greater Responsibility

The significance of each individual touch points that potentially gives you the power help users earn or lose millions of dollars, literally. For example, in foreign exchange trading field, major players often trade million to billion dollars in a single trade, in order to profit from a small percentage of spread (price difference). That being said, a mistake like accidentally clicking on something unwanted, a billion dollar just went gone from the user’s bank account. A UX designer therefore can help users prevent from that kind of mistakes by carefully crafting the workflow and UI design.

Who Is a Good Fit

Obviously, it’s not for anyone. I know some talented designers who hate reading documentation. I know designers who are only interested in designing products and services that they can use. I know some great visual designers that can create beautiful screens, but get confused when the workflow starts to branch out to more than five paths. And not to my surprise, they are not interested in doing design for finance. To me, it’s a meaningfully complex industry for certain types of people, but not all of us.

Some argued it’s related to the theory of different types of brain development. Some of us have our right half of the brain more developed for creative or visual tasks, and some of us have our left half of the brain more developed which makes us more analytical for solving complexity. If we were to apply to this theory to this phenomena, being a designer in finance requires almost equal weight of brain activities on both sides.

Summary

Famous scientist Nikola Tesla once said: “…Knowing that just a little theory and calculation would have saved him (Thomas Edison, his mentor and his rival) 90 percent of the labor.” This is a very good tip for doing design in finance. Spending some time to understand the product and business logic, knowing what users care about (sometimes it’s speed, sometime it’s large amount of data) in general helps. The more time I invested in upfront learning, the better the result I produced and more trust I gained from clients and stakeholders. It’s a tough job, and that’s what makes it fun.

Photo Credit to Matthew Guay