Learning to Build with Empathy: How to Think Like a User

At work, they push us quite hard about creating “breakthrough experiences.” It is borrowed from Pragmatic Marketing’s book Tuned In. Basically, it says that breakthrough experiences are found in products that offer solutions,  those that give customers those “aha!” moments wherein they realize we just helped them solve their problems. That sounds like a lot of manager-speak, but in the day to day life of a front end programmer such as myself, I think it translates to creating user experiences that empathize with the user — solutions that solve their pain points.

I think building products that deeply resonate with a user comes from having a strong sense of product or knowledge  in that specific industry. That, unfortunately, just comes with experience, especially in a complicated industry like insurance where I find myself in. So in the meantime, how do we start to actively hone our skills on thinking like the user? (A disclaimer: I am not classically trained in the art of Human Computer Interaction or user experience. I am merely a software engineer, trying to learn as much as I can about HCI and UX.)


 1. Work on product support

Working on customer reported bugs is definitely not glamorous. It can be painful, but seeing the pain you are putting your users through will really force you to think about what you are designing and building. To borrow from one of my favorite tech celebrities, Douglas Crockford:

There were times I would go out into the field and hold hands with the customers and see the consequences firsthand of some of the crap we were delivering to them. I think every programmer should work in customer support for the product they’re delivering. It’s another case of over-specialization. “I just write the code,” is the response you get and the programmers don’t see it as a chance to improve peoples’ lives.


2. Practice scenario based design (SBD)

In a nutshell, it’s a very agile, iterative way of designing a product using scenarios, or stories, in three phases that build off each other, in a cycle — Analyze, Design, and Prototype & Evaluate. The process forces you to slow down and really think before rushing off to design and code. In fact, in my HCI class where this was first introduced to me, we were forbidden from using the word “intuitive.” The professor argued that using the word gives us permission to dismiss problems easily  instead of actually breaking things down and asking ourselves why the experience doesn’t “feel right.” Below is a quick summary of the process that I learned and applied throughout a semester-long project.



The analysis phase of SBD is really just the requirements analysis phase. This is where you would do your interviews, your field studies and observations, competitor benchmarking activities, etc.  It is worth noting though, that field studies are very invaluable. They allow you to gain tacit knowledge from users. Interviews alone may not be sufficient as sometimes, users don’t really know what they want. (Something Tuned In really stresses is that our solutions should actually solve customer problems, not our hunches on what problems they are facing.)

You would want to write quick profiles of who you think your stakeholders and users are, including their wants, needs, and expectations. Of course,  you will adjust these throughout the analyze phase and the rest of the SBD process.

Then you would want to write the problem scenarios, or stories of users experiencing their problem points in the current situation. (When I had to practice this for my project in class, I was actually quite shocked at how effective it was in forcing me to think like a user. A programmer by trade, I find it hard to slow down sometimes — I just want to solve it!) After your write the narrative, analyze the claims (pros and cons of the situation) as well as tradeoffs. Keeping an ongoing spreadsheet of the problem points identified in the scenarios, as well as claims and tradeoffs, will be really helpful so you can build on those for future scenarios (activity, information, and interaction).



After we have a good grasp of the problem domain, it is time to start the fun part — the actual design process. In the entire process, you would use what you know as far as general UX principles and HCI theories as you design and build out the scenarios.

In SBD, you would want to start writing activity scenarios, or what you think the user should be able to do in your proposed application. I literally took my problems scenarios and spreadsheet, and overwrote those with what I think the user should be able to do in order to solve their problems. Remember these are stories, and their main value is the way their bring up questions and concerns we wouldn’t normally think of. I also like to keep another spreadsheet that just lists what activity I think the user should be able to do that will solve their problems, as well as the real world metaphor for each. Thinking about these metaphors are really helpful when trying to come up with fresh ways to do things. Of course, claims and tradeoffs should be part of the analysis as well.

Next, you would start writing your information scenarios. Just like the name implies, this is just all about how you want to present data and content to your user on a high level, focusing on what you want the user to see. Again a thorough analysis would include claims and tradeoffs for each visual element in your application.

Finally, (which isn’t really finally as you would want to iterate on these scenarios — each step will bring up thoughts and concerns on decisions made in the previous ones, etc.) you would write your interaction scenarios or how the users will actually act with your proposed system. In all honestly, I found this very difficult to do when I was implementing my project for class — so what I did was I mocked up something really fast using plain old pen and paper — and then when I had a more solid idea of what I want, then I went back and thought about the scenarios, claims, and tradeoffs.


Prototype and Evaluate

The final step in the iteration would be actually building out the prototype using the research and decisions made in your scenario writing process. Always  prototype early! It costs a  lot less to trash a prototype versus code. Also, when doing usability tests with users, try not to use high-fidelity prototypes too early on because users will focus on colors and the look versus actually usability and ease of use.


A few of my favorites are the following:

    1. Paper: Pen, paper, and post-its
    1. Low-fidelity: Balsamiq (desktop) / Mockflow (online) / Mockingbird (online)
    1. High-fidelity: Axure (lots of great libraries that can really make your app look real — perfect for client-facing demos. A caveat: make sure they realize this is not coded. The UI tends to make customers think you are done even when there is no-backend to power the actual functionality.)
    1. For mobile: Proto.io
    1. Coded prototypes: Ruby, JavaScript, Bootstrap. Read Design Resources for Developers for more fun!


Next, you would want to get feedback from users, whether it is as informal as asking your friends to try your app out, or actually paying people for a day to observe them interact with your application, complete with permission slips and evaluation forms, etc. The feedback you will get from your users should go back into your scenarios, which you will adjust and use to re-design your prototype, which you will get feedback on again, and so on. Iterate, iterate, iterate!


Article: How to Build Prototypes without Technical Chops

Article: How Facebook Did UX Testing For Facebook Home (With Fewer Than 60 People)

Book: If you are interested in the theory behind SBD, the textbook for the course, and where the image came from, is Usability Engineering: Scenario-Based Development of Human-Computer Interaction


3. Actively build your UX arsenal

Read and stay up to date! I cheat a lot by watching what Smashing Magazine and The Nerdery post on their social media.

What I’m currently interested in this week include the following:

UX Apprentice – a great website on the fundamentals

Storyboarding in Visual Studio (Has anyone tried this yet?)

Palantir’s The UI Design Interview

The Rise of the Mobile Only User

General Assembly’s videos on YouTube ( a peek includes Making Something People Love and Why UX

11 Rules For Great UX Design, Adapted From An Original Mad Man

Intuitive Equals Familiar (What does intuitive really mean?)

Hack Design, a design course for hackers

Finally, I can’t wait to take this class through Coursera (It’s free!), starting June 10th: Creative Programming for Digital Media & Mobile Apps


This post was previously featured in Femgineer.com.


7 Lessons After 7 Months in Silicon Valley

This post was originally published on Femgineer.

2014 has been a crazy whirlwind. I left my job in Corporate America on the East Coast, moved across the country, joined an early stage startup, shipped product, moved from SF to Palo Alto (the movers know me by name), and now I’m starting grad school back up again part-time, whew!

As I started packing for my trip home to visit my parents for the holidays, I couldn’t help but stop and reflect at what my first 7 months in Silicon Valley has been like — all the defeats, triumphs, and lessons learned. While I had mentors who prepared me for the transition, there were still things I wish someone had warned me about, which is why I’m sharing them with you!

If you’re thinking about relocating to Silicon Valley, I hope you’ll find this post useful.

If you’re already there, then I hope it reminds you of what it was like to be a Startup/Silicon Valley Newbie.

Read more here.


How I Decided to Leave Corporate America to Join an Early Stage Startup

This post was originally published at Femgineer.

I subscribed to Inc. Magazine when I was 10. I bought the domain name BuyConvectionOvens.com because I saw an infomercial on internet businesses that said you should start a business that resonate with what you love. At the time, my dad and I spent a lot of time baking on the weekends, so to my 10-year old self, an online business selling ovens made complete total sense. (Please don’t laugh.)

That’s when I first started playing with HTML, which unfortunately didn’t get restarted until I was in undergrad.

So I always knew I wanted to be part of the startup world from a very early age, even before I was aware of the word “startup.” And even though I found myself with an amazing job as a software engineer in Corporate America, I still tried to be involved with startups (contributing to and voraciously reading Femgineer, Women2.com, etc.).

Poornima has always tried to convince me to move to the Bay, but the timing was never right. I was enjoying my job building enterprise software with smart and amazing people. In fact, we were so close that as a young female living alone in the city, I referred to my coworkers as my family.

Read more here.


Rock the Internship, Part One: Get the Interview

Do you want to be a leading lady, just like the women we celebrate here at Levo? If you’re just starting out in the world, having at least one good internship in your resume is most definitely a step in the right direction. However, if you’re just like every college girl out there, internship application season almost always equates to stress and nervous breakdowns.

I just finished a six-month internship myself, and let me tell you something: getting an internship and acing can feel both impossible and cakelike all at once. Allow me to share with you a few tricks and some lessons I learned along the way. I hope you find them useful.

Read more at Levo League.

Software Design for the Newbie

First time designing an app? Freak not! I bring you the four steps to easy design.

1. Think  about what activities your customer will be doing. Instead of thinking on a feature-based paradigm, think of how your users will accomplish activities. Make the flow as easy and intuitive as possible.

2. Make up imaginary characters that you want to use your app. Can x person with x background find her way easily in your app? How about a less technical guy y with y experience?

3. Time to mockup? Use paper and post-it’s for the time being (they’ll be able to focus more on the actual flow vs. the design). Brainstorm with your team and come up with as many designs as you want. Show these to future users.

4. Create the actual mockup, taking into account the user feedback, using software such as Balsamiq or Mockingbird. Show and revise as needed.

Plus, here are a few more resources:

1. Prototyping for non-techies, Women 2.0

2. The ultimate guide to wireframing, Six Revisions

Hope that helps!

[Images: mark and angel hack lifecreative blogspot, sap design guildcrunchbase]

FILE - In this Jan. 15, 2004 file photo, Google co-founders Larry Page, left, and Sergey Brin pose for photos at their company's headquarters in Mountain View, Calif. Google’s IPO 10 years ago launched the company on a trajectory that continues to reshape its business and much of the world in its orbit. (AP Photo/Ben Margot, File)

Search Engines: A Lookback

A Book Summary on The Search, How Google and Its Rivals Rewrote the Rules of Business and Transformed Our Culture

By Frances Advincula


Note: Author John Battelle starts off by detailing how he stumbled upon the year 2001’s summary on Google’s Zeitgeist, a PR tool that summarizes what the world searched for. He coins the term “The Database of Intentions,” explains the value of search to our modern world, and provides us a history of search. He also tells the story of how Google was born and their journey to success, all while exposing the inner workings of search and how it makes money. Finally, he tells about the impact and implications of search in our lives, as well as its future. However, a few details maybe outdated, as the book was published in 2005. All points of view are the original author’s; I merely summarized what he had to say.



Google’s approach to search may be the closest thing we have to “The Database of Intentions,” the aggregate result of all our searches, the history of every query we typed in the search box. Basically, it shows what we searched for and where that search led, showing insight on what we want, what we think about, what drives us. {PYP’s take: We can think of it as the world’s Facebook timeline!}


At the same time, search is not only one of the pioneers of useful web services, it is also the reason for the second wave of Internet giants (think eBay, Amazon, Yahoo, Google).  Researchers also say search is the forefront of further progress in artificial intelligence. {PYP’s take: It is interesting to note that, fast forward to today, we now have Siri, who definitely acts/talks like a human!}



Who: The younger you are and the higher your level of education, the more you use search.


What: The beauty of search is that we can query for anything under the sun; the possibilities are infinite. How we choose the words we type in the search box, however, is a mystery in itself.

Where: The most used search engines are Microsoft, Yahoo, AOL, and Google.
{PYP’s take: Now, Google is used as a verb, and Bing recently overtook Yahoo.}


When: We search the most in the morning and the evening.


Why: First, we search to find what we know already exists. We want to locate something, to find information on a topic. Second, we use search to discover what we think exists, but we have yet to find.

How Search Works: Every search engine has three main parts, the crawler, the index, and the runtime system. The crawler traverses the entire Web and sends every page it finds to a massive database called the index.  The information is then analyzed using factors such as the number and popularity of links, language, content, etc.  Afterwards, the data is sent to the runtime system, a database that is ready to serve the person who queries. The runtime system performs the ranking logic, connects the user’s query to the index, and displays the results to the user.


With this in mind, returning relevant results is no easy feat. For example, if we want to know more about Abraham Lincoln, we search for “Abraham Lincoln Biography.” However, we are not merely looking for pages with those exact keywords; a good search engine will pay attention to coherence as well. As it analyses pages, it will take into consideration if the page shows the attributes of a biography. Similarly, search must deliver results even when we misspell a word, or be flexible enough to show relevant results for subjects that are represented by different words (“soda” versus “pop”, “tennis shoes” versus “sneakers”). Search engines also worry about striking the toss-keep balance with words such as “to,” “be,” etc. Usually, tossing them out will make the engine work faster, but what if one queries “to be or not to be”? All of a sudden, those words are crucial to the query. {PYP’s take: An infographic on how Google works.}


How Search Makes Money:  Most of the revenue comes from paid search. Advertisers pay the search company a certain amount per click in exchange for their ads showing up when a user queries for something relevant to their offerings. There are also more innovative ways companies are cashing in on search; examples include targeting ads using a person’s online habits and demographic.



Archie by Alan Emtage, McGill University, 1990. The first internet-based, pre-Web search engine.


Veronica by University of Nevada students, 1993. Connected users to the document itself, versus just the machine where it is located.

WWW Wanderer by Mathey Gray of MIT, 1993. Pioneered a breadth algorithm still used today.


Web Crawler by Brian Pinkertron, University of Washington, 1994. First to index the entire contents of a webpage.


Alta Vista by Louis Monier , DEC, mid 1990s. Pioneered the use of thousands of crawlers at once.

Lycos by Dr. Michael Mauldin, Carnegie Mellon, 1994. First to use links as a way of ranking and to include a summary of the results.

Excite by six Stanford alumni, 1994. Started personalization and free email.

Yahoo by Jerry Yang and David Filo, PhD students at Stanford, 1994. Started out using a directory-type structure that organized the Web into categories. Shares stark similarities with Google (both founded by Stanford PhD students, both have the quirky culture, both have fun office complexes).


GoTo.com by Bill Gross, founder of IdeaLab, 1997. Came up with the pay-per-click model; results were fully commercial.


Google started as a thesis topic called BackRub by Stanford PhD student Larry Page. He set out to create a system that would take the links of entire Web, analyze, and publish them in a way where one can find out who was linking to whom (unprecedented at the time), attracting the attention of Sergey Brin, another computer science PhD student at Stanford. The two came up with PageRank, an algorithm that rewarded links from important pages and penalized those that came from obscure sites (similar to the academe’s way of judging the quality of your paper through your citations and their quality).

After its debut on the Stanford site in 1996, the founders tried to license to the major players in the industry, but were turned down by companies like Yahoo for the next eighteen months. Finally deciding to start their own company, they received their first $100,000 in funding from Andy Bechtolsheim, a founder of Sun. Thus, Google was formally incorporated as Google Inc. on September 7, 1998.


The next step was to find a business model that generated money. Google turned to advertising, pioneering their text-based ads with AdWords. Led by their founders and new CEO Eric Schmidt (formerly of Sun and Novell), Google summed up its core values in their mantra – “Don’t Be Evil.”
Google continued to grow significantly from 2001 to 2004, buying DejaNews, Blogger, Picasa, and Keyhole.  Then the company released AdSense, a service that displays ads based on the contents of a page. They also started to index images and public phone-book information, partnering with companies such AT&T, Cingular, HandSpring, and AOL. After 9/11 happened, websites like cnn.com weren’t able to handle the traffic, and people turned to Google to inform them. Google was finally more than a search engine, something they took advantage of by launching Google News. Later, Google launched a new version of AdWords that copied GoTo.com’s auction and pay-per-click approach (previously, AdWords used the cost per thousand model).  However, Google still included popularity on how they rank an ad, not merely how much the company paid. Although this decision actually makes Google more money, the public saw it as a “Don’t Be Evil” move, one that put the user’s interests before Google’s.

But as Google gained more admiration from the public and the press, not everyone was happy with it either.  Whether it was their founder’s approach, their aloofness, their unconventional hiring process, or even their cute vibe, some were not impressed by Google.

By 2004, Google realized that to be able to compete with Yahoo and Microsoft, they had to go public. That April, Google filed their formal public offering (S1) that stated how not only would they be  maintaining a high level of control, the founders would also have ten times more voting power than the rest of the shareholders, despite the fact that they would own just 30% of the shares. After an age discrimination lawsuit, an investigation due to an untimely magazine interview, a reprimand that led Google to conduct a recision offer to their employees, glitches on their auction technology, and a myriad of other PR disasters, Google finally went public on August 19, 2004. Starting at the price of $85 per share, the price quickly rose to around $100 on the first day, topping at $300 by the next summer.

Post-IPO, Google underwent a soul searching of sorts, resulting in the founders’ Tablet, a statement of what makes Google what it is. This became a guide for a reorganization that took months long. Their previous approach of giving the most resources to the top 100 projects was done away with; instead, the company segregated functionality into core groups — search, advertising, “20 percent,” and “10 percent,” with the latter two for products that are were acquisitions or unconventional.


First, search overhauled the way businesses operated, from investors looking into new prospects to real estate firms staking out new territory. Until now, Google’s routine algorithmic updates impacts the crop of small, online stores who rely on showing up in organic search results. Google continues to do these in order to control spammers, click fraud, and other unethical operations that plague the Web to this day.

Next, search made information available and permanent. We now search for everything, including potential dates, potential hires, people we just met.  Unfortunately, we might not always like what we see. For example, pre-search, unfortunate things that we may have been involved in, although public information, are somehow inconvenient to research. Now, one can merely query for your name, and voila! – the history of you, as it is published online, is available for the world to see. Of course, we cannot forget the PATRIOT  Act, which allows for our private information to be intercepted and demanded by government authorities from our ISPs, Google, etc. The million dollar question then is how do be balance between our right to know and the right of a person to his privacy?

Google also had to be very careful on the precedent they set when they were entering China. They didn’t have the luxury of being a manufacturing company; brands do not suffer by being made in China. Things are different when your business is in information. Once they budge to China, what stops another country or even a corporation from making similar demands?
{PYP’s take: A  closer look on Google and China}


Perhaps in the future, we can search for anyone in real-time, or perhaps we won’t be limited to typing in a search box.  Maybe the public will even have access to a search that understands very complex, human-like demands like IBM’s WebFountain.  For sure, the evolution of search will be influenced by its two major players and their difference. Yahoo will continue to focus on being a media business, whereas Google will keep its stance on being a technology business.  Many say Google will eventually permeate into everything we do online, including music, documents, mail, photographs, and video.  To quote directly from the book, “When it comes to search, as with the Internet itself, the most interesting stuff is yet to come.”
{PYP’s Take: To date, Google has launched Google Music, Google Docs, and Gmail, as well as acquired YouTube, and Picasa. As for the interesting stuff, it is my opinion that Google has indeed lived up to that sentiment with Google+, Search plus Your World, and Android.}


“Because of their early success, they were closed-minded and a bit arrogant. Nothing deceives like success.”- Vinod Koshla, partner at Kleiner Perkins Caufield & Byers, on advising Excite founders to buy out Lycos, and not being heeded.

“I’d rather do something interesting than something boring and get rich.” – Louis Moiner, creator of AltaVista, on leaving Compaq in 1999, having felt that AltaVista was becoming a Yahoo clone.