Posted on

Sketch, Wireframes, Prototypes, and more: A question of fidelity

I would love to say that I seamlessly transitioned from ideation to producing wireframes. As I cannot, I will take the opportunity to explain how I eventually made this transition by better understanding the differences between sketches, wireframes, prototypes, and mockups (comps). Also, it’s a reminder of why hands-on practice is needed to fill in the gaps that theory often cannot bridge.

So why did I need to learn the distinctions between sketches, wireframes, prototypes, and mockups to make wireframes? The reason is that they’re all similar and really only differ in fidelity (or how much resemblance there is to an actual, polished product). As I read articles about wireframes to get tips, everyone had a slightly different approach to what a wireframe was exactly.

The difficulty is that with the exception of mock-ups, the other three– sketches, wireframes, and prototypes– can be executed with various levels of fidelity, which at each extreme makes them begin to resemble each other. A hi-fidelity sketch begins to resemble a typical wireframe. An “interactive” wireframe is a prototype, even if that means manually moving papers around in front of the user. Continue reading “Sketch, Wireframes, Prototypes, and more: A question of fidelity”

Posted on

Idea Dumping

Last week, I posted a few pages of sketches with ideas for a restaurant discovery mobile site.

Today, I am posting yesterday’s massive ideation sketches, and what’s interesting is the difference between the two results, despite no other work done in between.

Whereas the previous set honed in on UI elements and rather specific details, this set, in the quickness of its execution, contains a wide range of ideas. Continue reading “Idea Dumping”

Posted on

Ideation through Sketching

Normally, when beginning the ideation process– coming out with so many ideas– we don’t want to confine our solutions to a specific channel.

Initially, I wasn’t sure how much detail to put into my sketches. I decided eventually that I could go into detail once, or with each variation, but afterwards, the other screens wouldn’t include it or only a simplified version.

For example, for Pokémon Go players, some entrepreneurs helped them catch Pokémon automatically without going to their phone through a physical clip they keep with them which notifies them of nearby Pokemon and successful catches through lights. If they had stuck to only phone application solutions, they would have missed out on a good idea.

However, my learning project specifically asks me to design a website for a phone, so I will skip that step of imaging different channels. I’ll go directly to figuring out a mobile-first responsive website that helps users discover restaurants, cafés, bars, and other interesting finds.

The customer journey maps come in handy here. Although scenarios would have sufficed, the journey maps provide a push to come up with ideas to solve frustrations and pains. Continue reading “Ideation through Sketching”

Posted on

Progress: My first customer journey map

My first customer journey map can probably be improved a lot by an expert, but what’s important for me as a beginner is that it contains all the crucial elements laid out in a legible way. Despite a lack of mind-blowing insights, this journey map does its main job of portraying the frustrations and joys of a customer’s experience, highlighting features to maintain and areas where possible solutions may be proposed.

Not establishing such a map would be akin to groping in the dark to find something, which in my experience is hard even in a familiar area. Success is not guaranteed but the likelihood is much higher.

More importantly, I was wasting my time hesitating and not committing in order to output something amazing right away. Now that the first one is out of the way, I can do a few more, figuring out what works and what doesn’t, and making small tweaks towards something better each time.

As long as I keep my mind on producing, I won’t have to worry about current quality, as it will only keep improving over time.

Posted on

Shooting out Scenarios

User stories are easy to create. Just think of a type of user– mother or student, and what they might want to accomplish. A mother may want to find coupons for her essentials and students may want to find places with discounts for them. Scenarios however dig a bit deeper. They provide the situation and underlying reasons that bring users to interact with a service.

Why scenarios > user stories

With background and context, it’s easier to think of optimal solutions to accomplish tasks instead of a generic one-size-fits-all approach. The goal is to attract a loyal user base that extols the virtues of our services, and not casual users that will bounce as soon as something more fitting comes along.

How many should I make?

But of course, just like with research and stories, we could have an endless list of scenarios. How do we know when to stop? Using the research.

Through the results from interviews, surveys, and other sources of user information, we are able to pinpoint their non-negotiable demands as well as their frustrations, their pain points and their gains. Using my affinity diagram, I was able to quickly check why existing solutions leave users frustrated and options they would like to see. I quickly drafted many user stories based on the personas’ pains.

Creating scenarios

With this information, I can create scenarios and propose solutions that address their woes. Also, scenarios can be aspirational. They may or may not provide a solution, and I may or may not have capacity to provide such a feature, but they certainly show why certain features should be invested in and developed.

Scenarios also outshine stories through their ability to help find solutions with a lower risk of misdiagnoses. Vague user stories leave designers scratching their heads but overly specific ones prime certain solutions to the detriment of other more optimal ones. But through interviews and contextual inquiries, UX researchers can discover the reason behind these pains and frustrations. This information can then be used to create a scenario to think of solutions to address the underlying issue. I juxtapose what they cannot do, or not well, with the reason they drives them to want to do so.

For example, one interviewee expressed interest in downloadable maps for offline use. She didn’t always have internet and wanted to quickly navigate through town. We could have left it as is: “As a easygoing diner, I want to have maps available offline”. But some probing revealed that what was actually desired was to know where certain amenities could be found, such as grocery stores, transit stations, public restrooms, and maybe bars. In other words, she wanted to be able to explore a town for her usual needs despite intermittent internet access.

Steps to create a scenario

  1. Choose your persona (click here to see the post explaining the personas I created)
  2. Look for pains in your affinity diagram or research findings
  3. Create lots of user stories for the persona based on the pains
  4. Select unusual stories as well as a few common stories
  5. Expand on these stories and provide reasons based on the persona.
  6. Make sure they aren’t generic. These reasons should not easily fit with another persona.
  7. Optional: Provide an open-ended solution (not designing yet) without mention of specific tools or interfaces (keep options open)

Examples galore

As I love examples, here are some more. Below are four scenarios created for Sandra based on her persona’s desires and behaviors.

…

Shall I go today or tomorrow?

(There are two for comparison purposes)

Sandra loves to look at menus and get a gist of the price and also selection. She doesn’t want to miss out on something because it’s only offered on Mondays and she goes another day. So she goes to pull up the menu. The app brings her to the photo gallery where several photos have been labeled as the menu, with the most recent listed large (and the others underneath with smaller thumbnails). She can swipe between different shots of the menu.

Sandra wants to know if the gas station is still open. She sees that her favorite one is closed, but another more far away is open. She wonders if this station is a rip off though, because of its proximity to the freeway. Sandra decides to check if someone has posted an image and lo and behold, under the prices section, she found a photo of prices posted yesterday. It’s almost 20 cents more per gallon than what she paid last week at her spot, so she decides to wait a day. The next morning, after getting gas at her spot, she takes a photo of the prices and posts it on the application for others.

Where are the useful reviews?

Sandra has learned to be wary about online reviews. So many comments harp on what are inconsequential details for her. Instead, she sees what her nearby trusted friends have tried and are recommending. She notices a review posted by a nearby user whose review she has already liked and clicks again that it’s helpful. This helpful reviewer gets a notification, adds her as a friend, and messages her to say hi and talk about this new place she loved.

I have some time to kill.

Sandra has just finished lunch early and has two hours to kill before her friends arrive. She decides to see what’s nearby, especially as she had received a notification about being near one of her marked spots to try. Pulling up the map, she notices four different places, two places to try, one favorite, and a 5 star rated. Instead of going to her usual hang out, she decides to check out one of the new places. Looking at the photos, she chooses the quirkier one.

…

Next Step:

– Selecting several scenarios to draft up some customer journey maps 

Note: I personally like to provide solutions, which are italicized.. But I always focus on the background story more and am open to iterating on them to better serve the users.

Did I miss anything about scenarios? I’m still learning so please share your thoughts in the comments below.