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.

 

Analyze

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).

 

Design

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
Matters)

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.

Why I Chose to Lean In

I want to help empower the underdogs of the world, the children of underprivileged immigrants, all young women. I want them to be able to look up to strong women like what I aspire to be, and realize that yes, they can code, they can be scientists, they can be CEOs. I want them have the opportunity to be leaders, not just followers. I want to be part of the transformation of our society into an America where women creating tech startups and running big corporations is part of the norm, rather than the exception.

Read more:

Why a CS Major would want an MBA

Lean in for Femgineers 

Project Management: A Roundup

I apologize for being MIA the last few months. I started my masters this January, and I have yet to find the right balance between work, school, and a life.  (I have no excuse for the weeks prior. Ha.)

Anyway, one of the classes I am taking at JHU is Management of Systems Projects. The class gives us really great resources for future work as project managers. I thought I’d list them here.

(I plan to keep this document updated, and if you have suggestions, I’d love to add them here.)

Creating a Work Breakdown Structure
MIL-STD-881C, by the DoD, everything you need to know about the WBS, compliant to Federal standards.

Creating Statement of Work / Statement of Objectives
NPG 5600.2B, NASA’s guide to writing SOW
MIL-HDBK-245D, the DoD’s guide to the SOW. I like this one better since it also covers the SOO.

Earned Value Management
Systems Engineering Guide from MITRE
NASA’s guide to the EVM, complete with tutorials and a reference card!

PMP Handbook

Websites, Etc.

PMPodcast
ProjectManagement.com (previously gantthead.com)
PMHut.com
PMTips.net
projectsmart.co.uk’s articles

Specific to Software

How To Keep Your Startup On Track With Project Management

Experiences and lessons on
outsourcing: Optimizing Outsourcing
keeping talent: Retaining Startup Engineers

All about software schedules: Evidence Based Schedudling
The ultimate basics and books to read:
How to be a Program Manager

What happens inside Facebook Engineering: How Facebook Ships Code

Fog Creek Software’s MBA reading list (which I am…slowly but surely, making progress on…) and the Making Better Software video training series. You have to buy or rent it, but it’s REALLY GREAT CONTENT!

Book Summary: Designing the Obvious + Designing with Consitency

This is a great book, a light read that has powerful lessons in design. I love it that is not overwhelming for someone new to the topic. Thankfully, it does a good job of listing down what makes great applications, well, GREAT, in the first chapter.

So without further adieu, I will list them, verbatim, for you (with some of my comments), below:

Great Web-based software, in my experience, has some or all of the following qualities:

  1. It conforms to the way users interact with the Web, but focuses on the activity instead of a specific audience. (activity based planning)
  2. It has only those features that are absolutely necessary for users to complete the activity the application is meant to support. (But be careful.)
  3. It supports the user’s mental model of what it does.
  4. It helps users get started quickly so they can become intermediate users as soon as possible.
  5. It makes it easy to recover from mistakes and difficult to make them in the first place.
  6. It has uniformly designed interface elements, but leverages irregularity to create meaning and importance.
  7. Reduces clutter to a minimum.

Let’s focus on #6.

Here are my takeaways from the chapter: “Design for Uniformity, Consistency, and Meaning”

1. First impressions, just like in life, are very important. 
The impression users have within the first 50 milliseconds are very similar to their long-term impression of the site.  Make the first one great!

2. Be consistent in hierarchy, colors, typography, and spatial memory.
Leverage the visual hierarchy HTML already naturally supports (especially now with HTML5). Make sure your styling builds on this hierarchy (headers vs body vs paragraphs vs footers).
Remember that content is the most important part of any app. Minimize chrome (look and feel), maximize interaction elements, and increase your users’ productivity.
Some rules on typography: Never use different fonts from page to page. Choose different typefaces for headers, etc. vs regular body content, but make sure the difference is obviously intentional. Use no more than 2-3 fonts. In summary, less is more!
Spatial memory is the “ability to recall where physical objects are in relation to other objects.” This is the exact same concept as to why we can hobble around in a dark room we are familiar with  This means make your app’s layout similar from page to page so that users will be able to navigate with ease.

3. Being consistent with the rest of the company’s other products is important as well.
If you do, your company will be able to easily convert users of one app to buy a new one. There will aslo be less dev time due to reuse. If you don’t, you will risk your company looking un-focused, and you will make users unhappy as they have to relearn what they already know.

4. Know the power of design patterns.

Yahoo’s 59 design patterns.

Designing Interfaces’ patterns

UX’ movement’s 4 best design pattern libraries

“Design patterns are the glue that holds everything in an interface. They help useres learn new applications based on what they already know.”

Which leads me to this interesting fact I read from somewhere else. The company that originally built Visio (before Microsoft acquired them) built it to look like it was Microsoft’s precisely to increase their usability. I mean, everyone knows how to use MS office apps, right? (Bonus: which is also a big factor into why Microsoft acquired them!)

5. Know when to be inconsistent. Usually, to bring more importance to an element of a page.
But, be very careful. Knowing when to comes with experience, so err in the side of consistency when in doubt.

Remember the following:
Colors: 1-2 additional is ideal. You can use lighter/darker versions as well; just be sure not to overwhelm.
Dimension: more space usually means more importance.
Always make the differences obviously intentional.

6. Use bananas.
Bananas are guideposts that help the user along with what they want to do. It goes back to making it impossible for the user to fail, by designing the page to focus on what the user should be doing, and nothing else.

The idea behind Set Godin’s “banana” principle is that user’s will follow giant, clear signposts about what needs to be done on a page, just like monkeys will follow a trail of bananas. Surfacing the bananas in an application screen is as simple as determining what’s most important on a page and then making it stand out by displaying it differently than everything else…

Keep in mind that some apps do not benefit from bananas, such as portals, where the aim is to give as much information and choices as possible.

On finding your voice as a young woman in tech

Have you ever looked at code you wrote just one year ago and shivered? The other day, I saw parts of the software I wrote as an intern, decided to do an SVN blame, and felt torn at the feelings that ensued. Half of me was embarrassed that I wrote it, and half of me was proud at the thought of how much I’ve improved in just  a year.

That’s how I feel about my confidence as a software engineer too. I feel torn about it. I feel like I’m straddling a line dividing who I was before and who I am becoming. Sometimes I feel super confident, like I am the programmer version the kickass NCIS agent Ziva, and at other times I feel like I don’t know what I’m doing, OMG they are going to fire me.

Some days I find myself making smart suggestion in code reviews, having chats about code quality with the programmers I used to be terrified of. Other days, mmm…not so much. For instance, just the other week, one of the lead software architects took me aside to tell me that I didn’t speak up enough during a meeting with the User Experience group. He said I didn’t fight for our point of view. And yet, the very same week that happened, I asked to be relocated to the San Francisco area, AND I asked for a raise. That shocked me too, that I would think I am invaluable enough to deserve what I had asked for.

Thus, I realized that I must be doing something right in the confidence department, and yet, I still have a long way to go.

I know that I need to have a stronger voice and a tougher backbone, and yet, I feel proud to know that I am getting better, growing more confident everyday. So I asked myself, how did I get more confident in the last year? What else can  I do to get even better?

The end result is a starting list of these things that I think will help, and since we girls in tech are in this together… (Read the rest in my other blog, Life, Code, Etc.)

Prototyping with Axure: Random Notes

 

 

 

 

 

Read it on my other blog, Life, Code, Etc. 

A preview:

How a UX team Uses Axure:

For wireframing process. Used by UX team, Product Managers, Business Analysts. Developers consume the output so there is little room for misinterpretation when they are building the system.

Before using Axure, the UX team may utilize storyboards to capture the workflow. They are thought of as “one level higher” than Axure prototypes and are used to make sure all players involved have the right expectations. Afterwards, they go to Axure.

Designing the UX should be tech agnostic and instead focus on giving users the best possible experience. However, the UX team should still work closely with engineering to make sure that the design is buildable.

 


A Motivation Drip

My best friend told me she thinks I’m in a mid-mid-life crisis because I dyed my hair and bought a new wardrobe. I wouldn’t quite say I’m in a crisis, but this week has been, um, exhausting. I got moved to a new team with tougher deadlines, and I started training for my first 5K (and I hate running, so you get the picture). So I will admit it — I’m glad it’s Friday since I’m running low on motivation, and I’m this close to flopping on the couch and watching rom coms. At times like these, I like to peruse my favorite inspirational quotes, articles, and TED videos. I fondly call this process my “motivation drip,” and I hope you enjoy it too. But be warned — I’m going to go all Oprah on y’all.

 

Let’s start with my favorite:

 “And yes, you might fail. And yes, you might sometimes look stupid. Or unprepared. Or lost. Or audacious. Or wrong. Or arrogant. Or ballsy. But you also might not. You might surprise yourself. And slowly those lost and unprepared times might become the minority rather than the majority, and soon you are looking at the Past You from a vantage point you didn’t know existed before you decided to try.”

 -Sara Rosso

 

And from that awesome article, I found this gem:

 “Which leads to a question about how do we define ourselves? Is it just what we’ve done? You’ve already heard me say that, we are always 2: Who we’ve been, and who we aspire to be. Each of us is bound by our past, our accomplishments, and our failings. But I believe we are ALSO our aspirations and dreams. If each of us has a self-definition that allows us to appreciate the creative act of the moment…then we will stop denying energy to it. We will be okay with the trying and experimenting. Look around at any innovative company, and notice….they are okay failing because their self-definition includes the idea that they will ultimately figure it out.”

-Nilofer Merchant


So really, don’t be afraid to fail. Be afraid of not having the guts to try.

 “Guts is the willingness to lose. To be proven wrong, or to fail. It’s easy to be confident when you have everything aligned, when the moment is perfect. It’s also not particularly useful.”

-Seth Godin


And again, from the same author, it is only failure if you don’t learn from it.

 “…when you know the difference between failures that are better off forgotten and failures that are merely successes that haven’t grown up yet.”

-Seth Godin


(That’s so much better than, “It’s not  a bug; it’s a feauture!” Don’t you think?)

 

If life is throwing a curve ball at you, just hang in there.

 “More than education, more than experience, more than training, a person’s level of resilience will determine who succeeds and who fails. That’s true in the cancer ward, it’s true in the Olympics, and it’s true in the boardroom.”

Diane L. Coutu, HBR’s “How Resilience Works”


If you’re going through a hard time with your goals and self-improvement list right now,  consider that you might be in the dip (
You know, the feeling of being stuck and tired and ready to give up…), and actually be encouraged by that fact. It means you are exactly where you should be!

  • Big goals aren’t handed to you. You have to earn them.
  • If it is anything worth doing, you will hit a dip.
  • The dip is the toll you cross, the dues you pay.
  • You will want to give up.
  • You will question yourself.
  • You will feel uncomfortable.
  • You will want to fling yourself back into your comfort zone, but you won’t.
  • You will push through it.
  • And as much as it might suck, celebrate as you wade your way through the dip.
  • Live for the dip.
  • Laugh when you can; cry, scream or vent if you need to; and know that you’ll emerge stronger on the other side. Dragon slayed. Finish line in sight. Big dream conquered.


Keep on pushing yourself to be better. Try your best, and then do more, but remember, done is better than perfect. 

 

“There are a million valedictorians, even more A+ students.

There are a million absolutely beautiful girls. Perfection just puts you in a club.”

 -Jen Dziura

 

“Perfectionism is a deadly enemy of good performance. It’s like being judged every time you write a sentence or paragraph. It’s far better to go ahead, make mistakes and learn from them. Rather than expecting great output from a burst of frenzied inspiration, the idea behind Boice’s brief regular sessions is to work with moderate daily expectations, knowing this will lead in time to better results.”

-Brian Martin 

 

And finally, for when you’re already doing your 1000% (yes, that is one thousand), being you’re rockstar self, and yet the imposter boogey-man comes knocking:

 

“…so I ended up at Princeton, and I was like, I am not supposed to be here. I am an impostor. And the night before my first-year talk, and the first-year talk at Princeton is a 20-minute talk to 20 people. That’s it. I was so afraid of being found out the next day that I called her and said, “I’m quitting.” She was like, “You are not quitting, because I took a gamble on you, and you’re staying. You’re going to stay, and this is what you’re going to do. You are going to fake it. You’re going to do every talk that you ever get asked to do. You’re just going to do it and do it and do it, even if you’re terrified and just paralyzed and having an out-of-body experience, until you have this moment where you say, ‘Oh my gosh, I’m doing it. Like, I have become this. I am actually doing this.’” So that’s what I did. Five years in grad school, a few years, you know, I’m at Northwestern, I moved to Harvard, I’m at Harvard, I’m not really thinking about it anymore…”

-Amy Cuddy’s TED talk: Your Body Language Shapes Who You are

http://on.ted.com/Cuddy

 

 

I hope that got you riled up and ready to work even harder! Really, if what we are doing is not tough or hard to do, then what are we doing then? Are we wasting our life, just coasting along? Maybe that is what I  love about being a programmer the most. I live for the feeling of triumph when you’ve finally figured out that one last thing, or that feeling when you’ve finally tracked down the bug, or when your function finally works. The same can be said for any aspect of life that we have to work hard for, whether it is a college degree, a new job, even a marathon. We push ourselves constantly because we know our goal is worth it, our goal will make our circumstance better. We push ourselves because…well, reaching a goal is euphoria.

And yes, you might fail. …

And yes, you might fail. And yes, you might sometimes look stupid. Or unprepared. Or lost. Or audacious. Or wrong. Or arrogant. Or ballsy. But you also might not. You might surprise yourself. And slowly those lost and unprepared times might become the minority rather than the majority, and soon you are looking at the Past You from a vantage point you didn’t know existed before you decided to try.

http://whenihavetime.com/2012/02/16/stop-sabotaging-your-own-success-a-manifesto/

Book Review: Clean Code

</p><br />
<p>Read my entire summary at Femgineer!</p><br />
<p>“Test code is just as important as production code. It is not a second-class citizen. It requires thought, design, and care. It must be kept as clean as production code.”</p><br />
<p>“It is unit tests that keep our code flexible, maintainable, and reu</p><br />
<p>sable. The reason is simple. If you have tests, you do not fear making changes to the code! Without tests, every change is a possible bug. No matter how flexible your architecture is, no matter how nicely partitioned your design, without tests you will be reluctant to make changes because of the far that you will introduce undetected bugs.” </p><br />
<p>” /></div>
</blockquote>
<div class=
“Test code is just as important as production code. It is not a second-class citizen. It requires thought, design, and care. It must be kept as clean as production code….It is unit tests that keep our code flexible, maintainable, and reusable. The reason is simple. If you have tests, you do not fear making changes to the code! Without tests, every change is a possible bug. No matter how flexible your architecture is, no matter how nicely partitioned your design, without tests you will be reluctant to make changes because of the far that you will introduce undetected bugs.”

My New Blog: Life, Code, etc

Hello, Folks!

I realize I haven’t really posted in quite some time now… with all the goings on of moving back to the US, a new job, new exciting projects, and just trying to make new friends in the middle of nowhere, I haven’t…. yeah, you get the picture. I thought if I could blog in micro ways, which we all know tumblr is very good at encouraging, I would do it more often. Plus, I’m really going to blog more often if I don’t just have to write about techie things.

So I started my new blog, Life, Code, Etc over yonder at tumblr. Be sure to visit me there! To be quite honest, I will probably be posting the most over there…

I’ve also been blogging on Femgineer.com. I’ve written about what’s it’s like to be a young girl in tech, advice from the brogrammersroundups of blogs I read, and a book review of Clean Code. You’re gonna see me there every Friday (we call em Frances Fridays), so if you have any topics you’d like me to write about, feel free to shoot me an email!

Sometimes, my roundups on software development and startups get published in Women 2.0 as well.

And my articles on getting that perfect internship has appeared in The Levo League too, in tres parts: un, deux, and trois.

So many goings on, so may things to do, so many good things happening…sometimes, I’m afraid I’m going to go insane — if I haven’t already. For sure, this is a very exciting time to be a young girl in tech, and I just hope that I can share more of my experiences and lessons learned more often.