by Frances Advincula
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:
[quote author=”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.[/quote]
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:
- Paper: Pen, paper, and post-its
- 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.)
- For mobile: Proto.io
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!
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?)
General Assembly’s videos on YouTube ( a peek includes Making Something People Love and Why UX
Intuitive Equals Familiar (What does intuitive really mean?)
Hack Design, a design course for hackers
Frances Advincula writes the series Frances Fridays. Frances recently graduated with a degree in Computer Science and is currently pursuing a masters at Johns Hopkins. She now works as a Software Developer for Accenture Software. A proud geek girl, she’s sure she is the only one who can’t play video games. Tweet her at @FranAdvincula.