Studio VO Research, Product and Service Design, Usability Testing . Portland-based, projects worldwide . Studio VO . en-us Mon, 17 Jun 2019 11:25:23 +0000 Mon, 17 Jun 2019 11:25:23 +0000 Reduce Waste Thu, 28 Mar 2019 02:26:00 +0000 Matthew Oliphant One of my go-to sayings (among many) is: Reduce risk, reduce waste, increase confidence. It's what I set out to do with every Studio VO project. When I see examples where there's too much risk or waste, and certainly not enough confidence in a given system, it's kind of fun to find because I know I can do something about it ... On a project. As a consultant.

As a consumer on the other hand ... it's not fun to find. Tonight, I found some silly waste being put forth by one of the biggest companies on the planet.

Hi, Amazon!

Here's the transcript from my chat. Chat's start from a product/order page, so Amazon's rep knows which product I am referring to.

Me: Hi. This product dropped $130 since I bought it yesterday. Can I get a refund or do I have to return this order and get the one that's less expensive?

Jared(Amazon): [Standard Into] Hello, This is Jared from Amazon Product Support. I'll be happy to help you. Can I have your phone number just in case our chat would be disconnected. Nice meeting you and also Thank you for being a Prime member.

Jared: Thanks for bringing this to our attention and I'm really sorry to know that you're having issues with your item. I will definitely help you. Can you please send me the link for the new price drop?

Me: one sec ... ...

Jared: Thanks! Checking here.

Jared: Upon checking here you to need to transfer to the Pricing Team for further assistance. Please stay connected.

At this point, I should note I don't think anything is wrong with transferring me. That's not the waste part.

Saurabh(Amazon): Hello, my name is Saurabh. Please give me a moment to review the previous correspondence.

Me: okay

Saurabh: I completely understand your concern regarding the price adjustment. I know how it feels when the item you purchased is available now for a lower price. We work hard to find the best prices out there and make sure our prices are as low or lower – changing our prices instantly if we find a lower offer somewhere else. *Therefore, we don’t offer purchase adjustments*.

Saurabh: The price of the item goes up and down depending on the availability and demand of the item. However, we won't be able to offer price difference refund regarding this

Me: Okay. But I can return what I got and get this new-priced one.

Me: ^^ that was meant as a question.

Saurabh: [Anticipating the question] If you wish you can process the return request for this item from our Online returns center

Saurabh: [Answering the question directly] Yes

Me: okay, thank you [because there's no need to be rude]

Saurabh: My pleasure !!!! I appreciate your patience and understanding in this matter. Is there anything else, I can help you with?

Me: That seems like more cost and waste for everyone.

Saurabh: [This popped into the chat very quickly, so I suspect it's a script] If there would be any other option, I'd have done that within a second. Since, it is Amazon's policy, we are not able to offer a Price match or refund or credit regarding that. I hope you understand our limitations. I would like to thank you for taking time out of your day to contact us at Amazon, and I hope you enjoy your day further. When you're ready, please do not forget to click on the END CHAT tab on the top right hand corner of the chat window. Bye..!!! Take care..!!!

The Waste

So. Here's what will happen. I will buy the lower-priced product (done-did) and when it arrives, I will return the product I already unboxed and set up. Except, I won't do that. As my lovely wife pointed out, “Why not just send back the same one that arrives? It's the same product.”


Amazon will rush someone (and a few robots) around a warehouse to get the product I just ordered a few minutes ago. It will be put on a truck. The truck will use fuel. The driver will use energy. The box will be loaded on a plane. The plane will use fuel. It will be unloaded and put on another truck. Then it will go to a sorting facility to be put on another truck. Eventually, sometime Friday, it will arrive on my doorstep. I will then use the computer (a small bit of energy) to start the return process. I will drive the unopened Amazon box that just arrived to the UPS store and drop it off, then I will drive home. Using fuel. Adding wear-and-tear to my car.

Or! Amazon could have just given me $130 back on my card.

Reducing Risk

Amazon likely does this for 2 reasons. First, and foremost, because they think, on average, it's unlikely the customer will return the first product and replace it with the lower-priced second product. They keep more money this way. Very business, much good. Second, it reduces their risk of people gaming the system. All those people sitting around gaming. Yeah, I typed it and feel like it's a reach, too.

Do I have a solution? Sort of: If I'm in the return window, have been an Amazon customer since 2002, pay for Prime membership, and don't have a history of “gaming the system,” just give me the bloody refund already.

I suppose I'll have to play Amazon's Waste Game. A game which Amazon likely thinks they can afford to play. Well, likely they don't think about it at all.

I live for the day companies want to assess and address they system within which their products and service function. Wouldn't it be nice for a company, even if they are making decent revenue and profit, to want to see how much better they could be?

TL;DR: yes.

Experience Design, The Talk Show? Wed, 27 Mar 2019 16:33:00 +0000 Matthew Oliphant A few weeks ago we launched a YouTube channel called We Can Do Better. It's a show about Experience Design (broadly) that is co-hosted with my friend and long-time collaborator, Matt Wallens.

The name of the show comes from this article. We can all do better when it comes to the products and service we create, and that's a lot of what we'll be talking about.

We'll also be doing interviews with people we think are interesting. Like an upcoming interview where I talk with someone who is deaf over video chat. We figured out a way to make it work. Sometimes it will be just one of us talking to the camera, and sometimes we'll be doing "field pieces." Think "documentary-lite."

Here's the most recent episode about Remote Interviews and Testing. We talk a lot about why to do it, when to do it, and what the drawbacks are.

Please subscribe as it gives us that little boost of dopamine.

Startup Therapy Office Hours Thu, 12 Jul 2018 22:37:46 +0000 Matthew Oliphant I'm partnering with Tara Horn of The Praxis Department to offer 4 days of office hours. We're calling it Startup Therapy. You don't have to be a startup to sign up, but since we're basing out of PIE, we figured it'd be a good title. We'll be available from 9am to 2pm each day.

What are we therapizing (it's a word now!)? Here's the official announcement:

Startup Therapy Office Hours

The Praxis Department and Studio VO are hosting Startup Therapy Office Hours July, 23 - July, 26 at PIE, to help you solve problems and get things done. Sign up now!

Startup life is exciting and challenging. It’s constant learning and navigating unexpected changes. It’s easy to get caught up in the race and think we have to have all the answers, even for questions we’ve never asked before.

Sometimes what we really need is a chance to step back, reflect, and ask for help.

What if you had one hour of time and confidential expert support to work on the biggest challenge you are facing right now? What help would you ask for?

  • Helping your team work together more smoothly?
  • How to connect more authentically with your customers?
  • How to identify and understand your customers’ motivations?
  • Getting a change to really stick without the usual uphill battle?
  • How to build a company without sacrificing your mental health?

No question is too big or too small, and our only mission is to help you find answers and a clear path forward.

Who’s it for?

Entrepreneurs, founders, business, and people leaders, anyone who’s interested in building a more resilient, people-centered, successful company.

What do you get?

One hour of time to discuss and work through a problem of your choosing. It’s free and entirely confidential. Sign up and pick a time! Email with your questions.

Who are we?

The Praxis Department helps great companies navigate change and create resilient cultures that scale. They created The Startup Culture Canvas and would love to help you get started with it.

Studio VO helps companies connect with customers to create more impactful product and service experiences. Think of us as your own personal customer, culture, and strategy team. People are weird. We figure out why.

30 Days Later Fri, 29 Jun 2018 08:00:00 +0000 Matthew Oliphant I’m sitting in the Virgin Airlines lounge at LHR waiting for my flight back to Portland, OR. I’m reflecting¹ about the past 30 days of travel around London, Dublin, Galway, Edinburgh, Fort William, Edinburgh, London, Norwich, Brighton, and back to London.

Had an excellent time toodling around Ireland & Scotland with my friend and colleague. Many whisky tastings. Meeting agency owners and prospective clients. Attending two conferences and speaking at one of them. As well as travelling around The South™ of the UK with friends old and new.


I was given the opportunity to give a short talk at User Research London. Again, as with the longer version of the talk I gave at UX Hong Kong in March, I had people tell me after that it resonated with them. One person even started to use one of the ideas I presented to their benefit. That feels good to hear. Looking forward to next year’s event!


I attended The Lead Developer London. As I noted on Twitter: “The perspectives shared at #LeadDevLondon should be the way Tech is. Positive, inclusive, hospitable, caring, making space for vulnerability … This is a conference for grown-ups.” If you get a chance to attend this conference, even if you aren’t a Developer, do it. They do them in Austin and NYC.


I feel grateful to have found a handful of interesting leads. All either because I knew them, or someone knew someone else I should know. The old adage is an old adage for a reason. It’s a bit odd to think about, but I currently have no leads in Portland.

I do have leads not in Portland. I’m willing to travel for work, but do have to wonder if Portland is the right place for me if I am going to make a living there. Something to keep in mind, for sure. I’d like Portland to work, especially given some of the community-related things I drive there like PDXHCD and something accelerator-y which I can talk more about in a few weeks.

Overall it’s been a good trip. I’m thankful for the friends who let me stay with them, the friends who let me hang out with them, the ones who gave me good advice, the ones who let me give them good advice, and the all Airbnb places that weren’t run by Carole & Dave; never again, you two!


No big takeaways to share. Yet. There were a lot of conversations that sparked ideas, but I need to think on them more. It’s been good to change modes (and walk 116 miles) these past 30 days. If you have the means, I highly recommend it.

If you don’t have the means, make sure to take some time for yourself each day. You deserve it.

Just What The Heck Is UX? Wed, 28 Mar 2018 19:23:00 +0000 Matthew Oliphant I’m not here to quibble about definitions or job titles. If you want to do that, go and have a nice day. Seriously. Having a nice day is more fun than quibbling.


Back in the days when I was a lowly Technical Writer¹, I was spending my days writing Help files and manuals for software. I also wrote “Announcement Memos,” which communicated changes to policy, process … actually, pretty much any change that the end-users needed to know about.

I recall being particularly miffed about writing Help for screens which were designed poorly. Surely, there must be a better way!

About a year into my job as a Tech Writer, an opportunity opened to move over to the IDS team. IDS. Awesome title. User Experience (UX) had been coined as a term a few years prior, but hadn’t really made it mainstream as a job title. Kind of like how information architecture used to be just an activity/deliverable on a project and now it’s something you can do professionally.

The Interface Design Specialist team was about 30 people or so. We were farmed out to projects. During my time there we didn’t tend to focus on a single product. We also defined Interface as “something between a thing and the person using the thing.” In my time there, I did a lot of digital work, but I also did a lot of other things like: physical product testing, redesigning the customer experience in a retail setting, and redesigning processes.

We weren’t limited in our thinking of what constituted a user’s experience.

Today’s Limitations

Today, and for a while now², UX has been a digital-only profession. “Interface” has come to mean “Screen.” I talk with a lot of UX Designers and I often ask them about the types of projects they work on. All digital. Nary a one of them has worked on a physical product³ or created an in-person service process.

That’s both okay and a missed opportunity.

UX has never been digital-only to me and in a lot of ways I find the shift to digital-only to be surprising. Along with the idea that digital will solve all the problems because it’s so cheap and we can fail fast and launch and learn and it’s all we know how to do anyway so hammer/nail metaphor, and so on…

People need jobs and the jobs are mostly centered around digital solutions to poorly-framed (or not framed at all) problems.

That’s both okay and a missed opportunity.


I was very lucky that when I moved into IDSland, as I used to call it, I was trained by the people who wrote the books on UX-before-it-was-UX. Probably books many of you are not familiar with.

Of particular note were week(s)-long classes taught by:

Ginny Redish on interviewing techniques and task analysis.
Jeff Rubin on usability testing.
Robert Bailey on all things core to human factors.

Because of how I started (the training I received, the expectations put on me), I am grateful to have not focused solely on digital projects. Now that I run a Service Design consultancy, it’s interesting to look back and realize, in many ways, I was working as a Service Designer. And let’s not get started on the “differences”⁴ between Service Design and UX…

Consulting Helper

Personally, I don’t really care what my title is or what your title is. The best title I can think of for what I do, what many of us do, is “Helper.” But that probably would cause too many responses of “say what now?”

I like to help. Doesn’t matter too much to me what I’m helping with as long as it is moving people forward and/or giving them more time. Time being super important to me right now.⁵ Doesn’t matter if it’s a process, a digital product, a physical product, a service, or a career… I like to help. And I like the variety.

Which is why I chose to focus on Service Design. For now. I feel it’s the one thing that allows for multiple touchpoints (a Service Design term, to be sure) to be addressed in my work with clients.

Major Generalist

I’m not thrilled with the term “generalist” but it works to convey the idea that I wish people who work in human-centered disciplines would take more of a generalist perspective to their work.

I see people who are Design Researchers by day who have little interest in other areas of focus. Same with Information Architects, and Service Designers, and Interaction Designers, and, and, and.

Part of me gets it. Y’all work in a space where you are required to specialize and there’s no call for you, as a UX Designer, to learn about usability testing.⁶ When you get off work, why would you spend time at a meetup that doesn’t help you move forward in your day job?

I don’t think everyone should have the same professional experience as me, but I think a lot of you are missing out on some interesting opportunities to help by focusing solely on digital or solely on a single touchpoint/activity/set of deliverables.

There’s something really rewarding about being a generalist. It allows you to experience multiple ways of seeing.

This is part of the reason I started PDXHCD.⁷ In this case, I’m firmly planting my foot on the ground that the D in HCD stands for Discipline, not Design. We want to bring in as many people as possible. From “classic” UXers, to people working on Employee Experience projects.

We’re focusing local to Portland and trying to 1) get the local groups to work better together, 2) get the local groups to improve their level of quality for events, and 3) provide a space for professional development and exposure to those multiple ways of seeing.

I’m really looking forward to seeing what this effort becomes.

Just what the heck is UX anyway?

It’s a convenient way for me to communicate what I do, but unfortunately it is too specific to communicate what I do. It’s a profession. It’s a process. It’s a set of methods, activities, tools, and deliverables.

It’s a lot of things and it isn’t what it should be. We get caught up in debates on names of things, who is responsible for what, and what level of understanding and capability you need to do this work. Probably the only one we should be debating is that last one.

I know what UX is and I also do not recognize what it is. Ultimately, it’s a question best put to rest. A better question will always be: how can we help? And, related, how do we become better helpers?

¹ Lowly in the sense that I was a cog in a giant machine of a company, not that being a Tech Writer is a lowly profession.

² I blame the introduction of the iPhone and the Appification™ of all things.

³ Why are there so many Product Designer positions open that only work on digital? What does that title mean?!

⁴ Many Service Designers will say they don’t do UX. And what UX is now, I get it. But I still feel everyone has more in common than differences.


⁶ This is one of the topics that drives me crazy the most. “Senior” UX Designers who’ve not done research or testing. “I’ve never had the opportunity to talk to customers…” [picard facepalm]

⁷ The site is just a calendar for now. We started in January and are volunteer-driven, so it will take a bit to form-out who we are and what we do. But there is a plan!

What Is Expensive? Tue, 14 Nov 2017 08:00:00 +0000 Matthew Oliphant Recently, I received a second-hand compliment: “Matthew is brilliant, but expensive.”

I was talking to a fellow who runs a company that is working on a project that I also worked on earlier this year. The compliment was from the client’s project lead. I laughed a little because I know the project lead well enough to hear it in her voice.

When I lose out on a project, I ask what the winning bid came in at. When I do get an answer (which is rare) the winning price-point tends to be lower than mine. By a lot. I’m also able to gather that the scope of work (the activities and deliverables) is less and that the project length is 2-to-4 times as long.

As an example, last year I bid $72,000 for a 4 month project for research, design, testing, and UI specifications for a project. In the statement of work there was language around “working with developers” to ensure they could start as soon as possible, noting I would be there to answer questions as they went. The idea being the dev team would be half-way through development of the app by the time the 4 months was up.

My bid was received by the person who gave me the “brilliant, but expensive” compliment. I didn’t get the project. Too expensive!

The bid was delivered in July of 2016. The project will enter a beta run sometime in April 2018. Right now, it’s a year past when I would have been done with the design work. Right now, they, the client and the company that won the work, are still figuring out what to launch with.

The fellow I was talking with who relayed the compliment owns the company that’s doing this work, a year later, and getting paid well for it. I would wager, given the length of time, the number of their employees working on the project, plus a couple other comments he made, that they have invoiced more than $72,000.

It makes me wonder: what is expensive?

Someone who looks at their budget and says, for example, “I only have $50,000 for Research and Design.” $72K is going to blow that budget. The same person hires a company that will do the work for $35K, then ends up spending $100K because they are locked in and are on the hook to launch something great.

What is expensive?

Get Your Ship in Shape Wed, 30 Aug 2017 21:20:00 +0000 Matthew Oliphant 2011.

I was a Product Manager with a small team of about 6 people. Our charge was, essentially, a feature (simplified for this story). But it was an important area within the service the company offered: we made sure reconciliation from online donations was being correctly represented in the client app.

Not very exciting. But when you rely on online donations to run your nonprofit, and you use client software to run your back-office accounting and marketing needs, it’s important.

Word, Nick. Word.

When I joined the company, we also got a new SVP of Product. She said something similar to what Nick says above. Her goal was to be customer-focused; ship what they need. I’d never been at a place with someone so high up in the chain that felt the same way I did about the importance of focusing on customer needs.

With my team, and with customers, I outlined a roadmap for what needed to happen to meet customer needs. We determined that the entire feature needed to be rewritten from the ground up due to bloat and technical debt. And, of course, the UX of it all needed to be greatly improved.

Before presenting the roadmap to others in the organization, we presented it to several customers first, for two reasons.

  1. We new what we were proposing was going to make certain higher-ups in the company balk.
  2. Customers were used to a no-matter-what 6-month shipping cycle.

We were proposing fixing only critical bugs for the next release, roughly 6 months away, and basically skipping a release to deliver a totally redesigned and rebuilt feature.

One customer said, “Fuck, yes.” Everyone else said yes, too, but not as … colloquially.

The team felt strongly, the customers felt strongly, I felt sure our SVP of Product would agree. But it turns out, you need more than one SVP believing in a better way of shipping. There wasn’t enough organizational support to do things differently than had been done at a company that’d been around for 25 years.

The idea got shot down. Certain higher-ups did indeed balk. I was told we need to “ship more than just bug fixes, no matter what.” You’d figure with support from the SVP that I reported up to, it wouldn’t have been so … succinct? a reply.

All of that is to underscore who Nick is talking to: C-levels, the people ultimately in charge of how a company runs, the buck-stops-here-assuming-there’s-responsible-leadership people. The ones who sign the checks. Because if they don’t believe in building for customer needs, it almost doesn’t matter if you, as an individual contributor, do.

If you want some help figuring out how to get your upper management types to come around to your way of thinking, or if you are a C-leveler and want help figuring it out, get in touch!

Listen Up Tue, 11 Jul 2017 17:00:00 +0000 Matthew Oliphant A few months ago, we received an email from someone who wanted to hire us. “I committed the ultimate startup sin: I made an app and I’m not sure who it’s for.” They noted they had several conversations with potential users, but it was obvious they weren’t asking the right questions and weren’t really listening to the answers. 

One of the questions they asked was, “Would you use this?” This is never a good question to ask. You never can really know what motivates people to say Yes or No. Are they being nice because they are related to you? Are you paying them to be part of a study/test/focus group? Are they, in that moment, imagining themselves using it but in reality they’d never buy it? Are they having a bad day and feeling generally negative about everything?

Teams, and even founders/owners, often think they know what their customers truly need. And they know it without having talked much to anyone. Or when they did talk, they didn’t ask the right questions and did very little active listening.

Taking an active listening approach means going into conversations with a small, core set of questions, then shutting up and letting the conversation go where it wants to go. Conversations like this can take time, especially if you want to get to the core issues.

Active listening requires being open, being flexible, and being vulnerable. The last one is especially true if you’re getting feedback on something you’ve already made. “There’s no reason I’d ever want to use this,” is a perfectly acceptable response and likely something you won’t feel good hearing if you’ve put effort into making The Thing™.

Most people are getting in the way of their goals by looking only for answers that fit what they want or expect to hear; they are missing opportunities to learn more about their product or service from the perspective of those who use or might use it.

If you’re making art, you probably don’t need to talk with anyone about what you’re making. If you’re making something people will use, and possibly pay for, it’s worth having a conversation or dozen.

My pitch to you: take a chance. Take time to have a conversation with people and, most importantly, let them do most of the talking.  If you want help doing this, or want to learn how to do it, we’re here for you.

Studio VO presents at the ACT-W Portland Conference Fri, 07 Jul 2017 16:06:00 +0000 Kristin Valentine We had the extreme pleasure of giving a workshop on usability testing at the ACT-W Portland conference (Advancing the Careers of Technical Women). A topic near and dear to Kristin’s heart as a long-time lady developer, Kristin was excited to show attendees just how game-changing eliciting feedback from real users can be.

Attendees had the opportunity to practice interviewing and performing a validation test, as well as working together to create an affinity diagram. While we only had 2 hours to cover the topic, we had an energetic and curious audience, and look forward to presenting again.


The Role of Leadership in Service Design Wed, 17 May 2017 16:00:00 +0000 Kristin Valentine In a prior post, we wrote generally about Service Design and how important the relationship between the customer and the company is to a service. Essentially, services are created at the moment of engagement: unlike a product, which is made and then sold, services are just-in-time: when a customer calls the support number, when a customer walks into the store, or when a nurse makes a house call. The relationship between the customer and the company in many ways is the service, and in the end, “company” means the employees with whom the customer interacts.

“Design for relationships and experiences that evolve and change over time, rather than just short moments of consumption or usage.”1

Designers can co-create service blueprints until they’re blue in the face, but without the buy-in of the frontline staff, those on-brand customer service scripts won’t mean a thing.

It’s not just about buy-in; it’s about getting employees to value their relationship to the customer on a base level, which requires authenticity and a desire to help people, as well as a deep understanding of the overall mission of the company. It requires people have autonomy and ownership over their work, and that they feel what they do is meaningful. 

No easy task. It’s one thing to carefully design each touchpoint, but it’s quite another to have to redesign how a company functions, and how employees relate to this vision.

I’ve attended many company retreats where we try to identify who the company is and where we want to go. I usually felt like we would come up with some good ideas, but without solid leadership the proposed change initiatives went nowhere.

How can any organization affect change in a meaningful way? Even in so-called “flat” organizations, it starts at the top. Employees look to their leaders to model behavior. Does the leadership put an emphasis on the importance of the customer relationship in a meaningful way? Does the organization empower and trust front line employees to make meaningful relationships with customers? 

“When a CEO sits down to talk to customers to find out what they think, it sends an important signal to the rest of the organization and the industry.”1

Giving employees the power to fulfill promises is vital; we’ve all been trapped in a customer support loop where it’s clear that no one has the power to actually do anything (CenturyLink I’m looking at you). Educating employees, giving them power, trusting them with it, and listening to feedback, is absolutely vital. “Paradoxically, empowering the front line starts with senior leaders, who have the authority to ensure frontline voices are heard.”2

Designers can bring a range of tools to the table to help organizations identify the gaps in their communication and inconsistencies within their own processes. But the hard work of connecting the dots lies with everyone and is an investment well worth it.

  1. Service Design: From Insight to Implementation
    by Andrew Polaine and Ben Reason
  2. “Here’s How to Actually Empower Customer Service Employees”
    Chris DeRose and Noel Tichy
    Harvard Business Review
The Business Case for Hovering Awkwardly: Field Studies for Fun and Profit Tue, 02 May 2017 18:13:00 +0000 Kristin Valentine You are in San Francisco on a business trip. You are standing in a train station, and you thought you left yourself plenty of time to get to an important meeting, since you’ve never used the BART train before. However, you had trouble finding the station and you have just a few minutes before the train arrives. You jog up to the kiosk and start jamming your credit card into the machine in the hopes it will work like the one at home, but it beeps at you. “Please make a selection first” the screen to the left suddenly flashes, and shows a long list of possible tickets and cards to purchase, and you have no idea what any of them mean. Buckle up, it’s going to be a long ride.


Windows reboot is not exactly what you would be hoping to see. From @frankieroberto on Flickr

If someone buys a ticket for the train at a terminal in the train station, it makes sense to study the design of the system in an actual train station, with a user who needs a ticket. The environmental factors (a line of annoyed people behind you, people rushing behind you to catch trains, low lighting, and the stress of being late) will affect the design in ways that cannot be replicated in a design studio.

People have remarkably terrible memories. They often don’t remember exactly what they did and certainly not in the detail of what you would need to understand a complex system. Unlike watching someone perform a task in usability lab, you watch them where the task actually occurs in the way it occurs, missed trains and all. As an observer, you get a sense of the entire workflow of a task—from locating the ticket dispenser, to attempting to cram a crumpled dollar bill into a machine, to finding the correct platform.

Conducting a field study involves watching someone do something in the environment they would normally do it. Field studies are best done at the beginning of a project where the team is looking for direction. They may be trying to figure out why users seem to be getting stuck (why are so many ticket-holders missing trains?) and are looking for ways to improve or redesign a project, or they may be looking to discover completely new opportunities. Watching someone through the entire workflow can uncover gaps in the system, misunderstandings, and creative user workarounds that the team would not have dreamed of from the comfort of their office.

The point of field study is to challenge assumptions and ensure what you are building will be adopted by users and help them achieve their goals. And yet, people in an organization often feel that field study isn’t necessary, is a waste of time, or is too expensive. These are some of the common pushbacks:

“We’re disrupting an industry/creating a new one, there is nothing to go see.”

Highly unlikely. There is probably some analog in place now; how do people accomplish their goal now? And if it really is that earth shatteringly new, use a prototype to elicit feedback; users may build their own analogies to things they already do, which will help the design team figure out a system that makes sense.

“I know what people do. I used to do it when I started the company 20 years ago!”

While it can be tempting to assume all users behave and think like we do, especially if we are users of the product, not everyone has the same experiences, technical expertise or goals that we do. This is especially true if the company has been around a long time; new (re:younger) users will likely have a completely different background and context that they bring to the table.

“We know what they do because they tell us in the support tickets.”

Support is often a great way to get insight into the issues users are having with a product. The support team can tell you what issues are arising with customers and to some extent how frequent they arise. The team may jump in with a fix—but the fix may be wrong, because people generally aren’t good at explaining what led to a problem and how that problem relates to their goals. The support tickets tell you who to talk to. Next step: ask to visit them.

“Why not use the research we already have from marketing?”

Marketers and business analysts tend to be focused only on the person making purchasing decisions, not the actual users. Even when the purchaser and user is one and the same, buyers do not equal users—they may purchase your widget, but if they aren’t a happy user, that does not bode well for the company’s future.

“That’s too expensive/time consuming.”

Do you want to find out that users actually don’t act quite how you anticipated when in their own environment? Last minute, pre-launch redesigns are not uncommon; companies put their products into the hands of real people in the real world only as a final check. That’s not the best time to discover that they didn’t take into account the fact that people don’t normally check the train platform number until after they buy a ticket, so putting that information before the turnstiles causes a lot of missed trains.

Field studies mitigate risk; they build confidence that your assumptions (aka, educated guesses) are accurate in the real world of a user.

For thorough information on conducting site visits and task and workflow analysis, checkout User and Task Analysis for Interface Design, by JoAnn Hackos and Janice Redish.

Service Design Tue, 25 Apr 2017 16:30:00 +0000 Matthew Oliphant Studio VO is a Service Design company. Service Design looks at the entire lifecycle of the customer, the business (including the employees of said business) and creates the best products and services it can to make the customer happy and to make the business money.

I was explaining Service Design to a friend recently and he asked, “Isn’t that Customer Experience?” To which I replied, “Uh, sure?” The truth is, Customer Experience (CX) is and isn’t Service Design. The same with User Experience (UX); it is Service Design, and it isn’t.

I’ve been in the profession for almost 20 years and there have always been multiple names for the kinds of activities I’ve done on a project. Service Design, UX, CX, Interaction Design, Information Architecture... To me, because of my background and career, it’s all UX. But what UX means to me isn’t what UX means to most.

Primarily, because most people in UX these days came to it in the last 10 years. The term was around prior to that, but it wasn’t as widely used as it is today, or even 10 years ago. When I started, it was mostly called Usability. I was taught by people who came from the Human Factors world.

As such, it’s entirely fair for my friend to have asked about CX. As it is entirely fair to look at Information Architecture as a project activity rather than a profession. There’s a lot of confusion because we, as a profession, don’t all agree on what to call what we do. But we all do a lot of the same activities, use a lot of the same methods, use a lot of the same tools, and create a lot of the same deliverables.

Why We Chose Service Design

Service Design looks broadly and deeply at the interactions between people on the outside of a business and people on the inside of it; from what motivates people to engage with the business, to how the business should best entice and serve them, to how customers and companies deal with each other once they have an established relationship.

UX is often applied only within the digital solution space. CX tends to look solely at the part of the lifecycle from when a person becomes a customer to when they stop. Information Architecture (IA) is a unique (and needed) specialization within them. They all play a role in the support of customers and the business.

Our past experience is filled with a lot of digital solutions, but not exclusively. We’ve created IA content inventories and sitemaps. We’ve created Customer Service workflows and apps. We also know how important it is to understand the motivations and capabilities of customers and of businesses.

A business may come to us to redesign a form, but we can quickly see the form isn’t the core issue.


Picture of a draft service blueprint for a monthly event we run called Refresh Portland.

Taking a Service Design approach allows us to start those broader conversations earlier. It often better informs the people we work with about what is truly important for them to get right.

Does the form play a role? Absolutely. So does trust, how you speak to people (via copy on your site or directly to customers), and how you solve for their needs beyond the usability of a form.

You have to understand the entire lifecycle, and the roles the customer and the business play, as it is today, how it needs to change to support what you need to do, and how it will change over time because your business may want to do more and your customers will expect you to do more.

We’re all-in on Service Design. It’s somewhat new as a concept in the US, but as a practice and profession it’s been around for a while in other countries and the benefits of taking a holistic approach to design are well understood. Certainly the bulk of the activities are well-established in other areas like, UX and CX.

Many of the projects we’ve taken on over the years have been Service Design due to their scope and what work was required to make them successful. They’ve also been the projects that have had the most impact on our careers and for the people we’ve worked with (and their customers).

It may be that you are reaching out to us with help on your app, or getting your project team focused on the right work, or you need help with a form that isn’t performing well. Let’s take the opportunity to look as broadly and deeply as possible together in order to create meaningful impact for projects large and small.

How Do We Make Meaningful Work? Tue, 28 Mar 2017 20:27:00 +0000 Matthew Oliphant We’re in San Francisco this week for the second half of our two-week whirlwind tour with our good friends at Apogee. They are in the process of writing a book and creating a conference about Make Meaningful Work. There’s a lot of overlap in thinking where Dan and Jo (who run Apogee) are at and where Kristin and I are at.

We want to make meaningful work. Of course, who doesn’t? But the truth is, we all contribute to meaningless work. Up to the point we decide to not do that. And that’s where we, the four of us, and others, find ourselves now.

Dan Szuc at a Refresh Portland event.

Dan presenting at Refresh Portland in Fine Design’s space.

Dan arrived in Portland from Hong Kong and the next day we drove to Seattle for a few days. I joined him for presentations at Facebook, Amazon, and the local IxDA chapter. After each presentation, Dan and I talked about what worked, and what didn’t, and refine the flow of the content. By the time we arrived back in Portland for a presentation at Refresh Portland, the presentation was in a great place and it found a willing and highly engaged audience. Not to brag too much about an event Kristin and I co-organize, of course.

Kristin driving, me navigating (“Go south on I-5 ‘til you get to San Francisco.”), and Dan reading.

Two days later, Kristin and I drove Dan to San Francisco, and picked up Jo at SFO on Sunday. We have a presentation scheduled Wednesday evening at WeWork, and we’re looking forward to seeing how the audience reacts and engages, what questions they have, and what ideas they have to make meaningful work. We’re also taking the opportunity to meet other people while we’re here and do some touristy things as well.

Dan, Jo, and Kristin on our first visit to Japantown.

The aspect of the Make Meaningful Work presentation that is somewhat a hard sell at this point is the fact that there aren’t any direct answers being given to event attendees on how to make meaningful work. Right now, the purpose is to establish a questioning framework, to help attendees understand their current state; which, or course, is the only way to get to a future state.

Design doesn’t hold the patent to making something meaningful. Neither does tech, or business, or any one industry. Ultimately, we all have to determine how we can make meaningful work for ourselves. We, as individuals, are the only ones we can control. We can influence others, through small nudges, to help them understand how best to make meaningful work, but ultimately it is up to us to figure out how to best contribute.

Me, Dan, and Jo. Likely the cover of our next album.

That said, we can be very intentional with how we work with others. It’s rare that we work alone. When we collaborate, we can start by agreeing how we want to work together. This is how we approach projects at Studio VO. It goes beyond, “you’re the designer, you’re the product manager, you’re the stakeholder.” We all have to play those roles, but ultimately we’ve come together, hopefully, to make something that has meaning and we don’t necessarily have to fall into Industrial Age hierarchies in order to accomplish our shared goals.

Making Meaningful Work isn’t a tool, or a process, or a method, or a book, conference, or anything else. Yet it will likely be all of those things. The important thing to remember is that it is an intention. It is a choice. And while it may be a choice that only those with the privilege of time will be able to act upon, it should be acted upon by all of us whenever we have the chance, and do it, as Jo says, one sparkle at a time.

Kristin and me on a trolley in San Francisco, running late for dim sum.

Studio VO will be collaborating with Apogee and other companies and individuals over the coming months and years to help define the questioning framework as well as generate some possible answers. We'll be helping with interviews for the Make Meaningful Work book, running workshops, and nudging along everyone we can to help people, teams, and companies identify better ways to work together and better work to focus on. 

If you'd like to follow along, sign up for our newsletter below. If you'd like to join in, get in touch!

Book Review: Design For Real Life Tue, 21 Mar 2017 08:00:00 +0000 Kristin Valentine By Sara Wachter-Boettcher and Eric Meyer

Book Cover Not too long ago, Beth Dean spoke at Refresh Portland. Her talk centered around emotional intelligence in design; specifically, the kind of empathetic, edge or stress case scenario that Design For Real Life is all about. She even mentioned the well-known story of Eric Meyer, one of the authors of the book, who was confronted with a picture of his recently deceased daughter by Facebook Year In Review (not something anyone would want to celebrate).

One of the audience members asked: but can you really design for every edge case? Can you be sensitive to every user? An impossible task for sure, and I was curious how this book might tackle that question.

They didn’t tackle this question head-on, although they did create a questioning framework. Take that year in review feature—the authors begin by putting people into two groups: people who want to share it, people who don’t. From there, they break both groups into people who want to relive it, people who don’t, and people who had a great year or a horrible year. There aren’t any specifics about what conclusion you may draw from this kind of thinking—the point is to go through the thought process. To realize that not everyone is always having a great time, is calm, or is in a great state of mind when interacting with your product or service.

Beyond simply realizing one should keep their users’ humanity in mind, I found the book lacking in actionable steps. They point to doing user interviews as a main source of valuable information, but rather explain how to do them, they list some other books as reference. A Book Apart (the publisher) focuses on creating very short books, so the scope of the book is meant to be limited. However, I found it to be so limited that it ended up feeling vague. Same with customer journey mapping; the description is very high-level and aimed at designers who have little experience with the practice.

They do stress the importance of seeing people where they are (go to their homes or places of work), and options for how to understand stressful situations. Given that you can’t actually interview someone under great duress or in an emergency situation, it’s difficult to get a true sense of how people are thinking and acting in those moments. They recommend using collaging as a bridge to difficult conversations; it allows people to open up about tough subjects through imagery rather than language. Participants create collages to explore their emotions of a situation; afterwards the facilitator asks questions about the image produced, resulting in a more open dialog.

This book would benefit anyone new to design or a product owner who doesn’t have much experience with customer interviews or journey mapping, who could use a broader vision of what designing for real life really means.

Reduce Suffering, Increase Dignity Tue, 14 Mar 2017 20:12:00 +0000 Matthew Oliphant I updated on Twitter last November with the following:

New KPIs.
Our app/site/content/product:
1) Reduces human suffering.
2) Increases human dignity.

I’d been thinking about Key Performance Indicators (KPIs) trying to understand why companies measure things and what is really important to track. I'm not at all against using KPIs. What I was thinking at the time, and what I continue to wonder, is what are all those measurements in service of? That tweet was part being silly, but it was also the idealist in me wondering why so many products and services aren't attempting to reduce suffering and increase dignity.

When we started Studio VO in January, I noted in my LinkedIn profile that I was looking for projects which “increase dignity, reduce suffering.” It’s why we got our first lead as a brand-new company. The person searched “ux portland,” found me on LinkedIn, read that line in the summary section, and got in touch because of it.

I’m really glad someone contacted us who appreciated what I wrote. Especially since we’re going to try to make a living out of it. We want to work on projects that increase human dignity and reduce human suffering, whether it's with big-impact projects or improving even a moment of someone's day with small nudges.

Users Never... Tue, 28 Feb 2017 08:00:00 +0000 Kristin Valentine I’ve lost track of the number of times I’ve heard someone in the web industry utter the words, “Well, a user would never do that.” Or “What do you mean? This makes perfect sense, anyone could figure it out, I don’t think it will be a problem.”

These statements are problematic for a few reasons. First of all, “users” are people. And people are weird, wonderful and come in a variety of flavors, shapes, and sizes. No two are alike. It's a pretty incredible statement to say "someone would never" do something. If you’ve ever had to walk your elderly neighbor through using a website, you know they do strange things. They use the mouse weird. They don’t use the same (or any) keyboard shortcuts. They open a new browser window for everything and they minimize everything (their dock bar, don’t even get me started).

The beautiful thing and frustrating thing about building things for people is, well, people. They don’t use your thing the way you wanted them to use it, they can’t find what they’re looking for, they can’t figure something out that seems so obvious! But at the same time, they find shortcuts and workarounds and new ways of using your thing you never even imagined. But you’ll never know any of this unless you actually talk to them and watch what they do.

Works on My Machine When I was a Flash developer (it was a web animation platform, kids), my testing process before sending it off to the QA team was to click like a bat out of hell all over the page. At complete random, clicking as fast as I could click, dragging, banging on keys; I probably looked like I’d finally gone over the edge and needed to take one of those month long sabbaticals I kept hearing about. But I did that because I’d seen people do that. They would get frustrated when something was laggy, or they accidentally clicked on something, and in a panic, start clicking all over the place to stop what was happening. Was it rational? No. Would you uncover this bug if you only ever used the app as it’s “supposed” to be used? No. Was it understandable? Yes.

To assume that people are perfectly rational, come to the same conclusions that you do, want the same things, have the same goals, and will assuredly read the entirety of the homepage top to bottom, in order, is out of touch with reality.

Yet these are all very real and easy assumptions to make; after all, it’s much harder to design something when you assume the audience is nothing like you. The best way to see this in action is by talking to people, and by watching them fumble through your perfectly rational design.  When we get feedback on products there is always a moment of surprise that uncovers something useful, and we never would have seen it if we hadn’t gone out to ask.

Before the Screen Loads Tue, 21 Feb 2017 08:00:00 +0000 Matthew Oliphant We’d been on the conference call for a little over fifteen minutes talking with the client about the early results of usability testing on an application for reviewing the results of a DNA test.

We were seeing reactions of “too many screens,” and too much medical jargon that wasn’t explained. Test participants were getting lost and felt underwhelmed. Eventually, they would all find the right information, but the usability test results didn’t feel like a success in terms of the design proving helpful.

But that wasn’t the part that was bothering me. “What happens when the person gets the email about their results being available,” I asked.

I got an immediate reply: “Well, they click on the button that says See Results and…”

I interrupted, politely of course, “No, I mean, what happens to the person when they get the email?”

I proposed a theory (a theory only because it wasn’t in the scope of testing): People have many reasons to want to do a DNA test. For many, the thought of doing DNA testing is novel and fun. People request a kit, it arrives, they spit and swab, and send it back. And then, because DNA testing isn’t as fast as it is on TV, they wait a couple of weeks.

During that time, most people aren’t thinking, “I wonder when my results will come back.” They’re getting on with their busy lives. When the results email arrives, it may be a moment of excitement and it may be a moment of intense anxiety; the DNA test description promises to identify (or rule out) a handful of genetic disorders.

It went quiet for a long few seconds on the conference call when I explained that. Their team’s focus on getting the screens right meant they weren’t thinking about the the entire flow. Granted, the scope of the test hadn’t included that aspect, but the silence showed it wasn’t even being thought about.

That isn’t to say at all that they don’t care. This was a large, complex project. But it’s also something that needs to be done correctly from the moment the app is launched. That’s why when people come to us, we look at the broader view, beyond the initial request of, for example, “help us fix our app.”

If the product or service you provide could potentially induce anxiety or stress in the people who use it, you need to be thinking about what’s happening before the screen loads.

Even if you aren’t making something that could create anxiety or stress, you cannot count on your users being stress-free when they are engaging with you. How you plan for that and how you handle that is well worth considering as the launch or first-time-use of any product or service is always a make or break moment.

Book Review: Why Did the Policeman Cross the Road? Tue, 14 Feb 2017 08:00:00 +0000 Kristin Valentine Book Cover I literally knew nothing about Stevyn Colgan's new book, Why Did the Policeman Cross the Road?: How to solve problems before they arise; Matthew simply bought two and gave me one. I was unsure what policing had to do with user experience research, but not one to turn down a book with fun illustrations on the cover, I dove right in.

The story is both a timeline of Colgan’s career as a police officer in London, as well as an in-depth explanation of the methods of crime prevention and problem-solving that he and a special unit known as the Problem Solving Unit employed to lower crime rates. Rather than simply increase the number of patrols (which costs money) and increase arrests, they looked at ways to prevent crime with little to no resources by going through a step-by-step process and by engaging the community in their efforts.

His process is familiar to anyone in design research: Define the problem, research, analyze, act, and evaluate your action. Colgan illustrates every part of this process with colorful examples and surprising results.

He stresses the importance of getting your research data from multiple sources. He cites one example where an area was flagged by their software as a robbery hotspot, which usually results in increased patrols. However, the investigator who knew the area well thought it was strange and investigated further; it turned out a nearby school had started a healthy-eating campaign and had taken junk food off the menu. The kids would then go off campus for lunch, and the bullies would feel free to steal their classmates’ lunch money. The victims’ parents would report these as robberies. Clearly the issue was bullying, not street crime.


Colgan stresses the importance of actually speaking to the people involved; be it the people who report the crime or nuisance, the source of the complaints, and even nearby businesses and neighbors. Similar to the work we do, understanding the people involved is an obvious, but often overlooked, part of problem-solving.

In one case, local residents of a housing estate filed complaints that the kids in the complex were being a nuisance: graffiti, littering, noise, drinking, and kicking balls around ‘no ball games’ areas despite two nice soccer fields nearby. They wanted increased patrols and possible legal measures; the residents also suggested removing the ball fields as punishment. So Colgan spoke to many of the kids involved and other kids around the complex. As it turned out, the older kids were bullying the younger kids off of the closer ball field, and the younger kids weren’t allowed to cross the big street that separated them from the other field. So they would just loiter around and cause problems. Colgan solved the issue by breaking up the closer field into 2. The older kids wanted the full sized field, so they played at the far one, and the smaller fields gave the various ages of kids plenty of room to play.

“If you can get to know people’s needs, desires and motivations, their habits, foibles and interests, and what informs their choices and decisions, you can design solutions to problems that thwart the bad guys and support the good guys. It means that cops have to become good readers of people. Or they have to work with people who are good readers of people. It’s pointless putting a solution in place if you don’t have any understanding of how people are likely to react to it.”

Overall, the book is a great story and creative way to illustrate design-thinking in action. I wouldn’t say this is necessarily a step-by-step manual, but more of an ethos for problem-solving in any complex, people-centric scenario.

Working Within Constraints Tue, 07 Feb 2017 17:56:00 +0000 Matthew Oliphant It isn’t fun to be constrained when trying to solve a problem or explore an opportunity. Having too little time and too little budget is something everyone runs into. But working within a constraint can lead to some surprising and creative outcomes.

Instead of asking, “What if…,” as we might if we were taking a Blue Sky approach, we might ask, “In order to…?” Asking the question in this manner causes everyone to consider the underlying motivation for wanting a change, or the underlying reason that something is not working optimally.

We will almost always end up taking a constraints approach to a project, even if the project starts with Blue Sky Thinking. Using constraints to look for problems and opportunities, can be a good way to generate meaningful ideas in a short period of time.

Speaking of Time…

It may feel like there is no time because internal process is being applied blindly, or the skill-sets of the team tasked to solve the issue are not a good match. Because of this, teams do not often stop to consider the simplest, most constrained way to approach the issue.

One of the ways we use constraints, while maintaining flexibility, is to conduct interviews and testing in rounds with three individual participants in each round. This ensures everyone has time to consider the core issues of the project as we assess the results of each round.

This approach allows us decide if we need to change our questions, change who we are asking the questions of, or change what we are giving participants to react to. Even if things go well during the first round of three participants, we may learn something that prompts the start of a parallel track of research.

We continue in rounds until we feel we’re getting good, consistent feedback while asking the right questions of the right people. We build to a level of confidence with which everyone is comfortable.

Working Within Constraints

We like to be able to explore and we like to be realistic. Starting from a place of constraints is a good way to balance the desire to do everything with the knowledge that you cannot. Eventually, we can explore all options, but we do it in increments.

Few people enjoy being constrained when attempting to solve a problem or explore an opportunity. But proceeding intentionally with small-scope steps can be a great way to work through any size project. Get in touch and let’s talk about how we can help get you where you need to be.

Ethics and Technology Tue, 31 Jan 2017 08:00:00 +0000 Kristin Valentine View of a bridge being built

What does it mean for technology to be ethical? To illustrate, let’s start with how it can be unethical.

Robert Moses, the master builder of public works in New York between 1920 and 1970, did something very unusual: he had all of the overpasses around Long Island designed and built as low as 9 feet tall, much shorter than most overpasses you might be used to. As it turns out, he did this because the city buses were about 12 feet tall--and he was trying to “protect” Long Island, and specifically Jones Beach, from poor people and racial minorities, who were more likely to use the bus than the middle and upper class whites in the area. He also vetoed a proposal to extend the rail line to the area.1

In this case, the design in question was intentionally unethical, but often design solutions can have detrimental effects without the intention. For instance, when Facebook’s “year in review” feature was unveiled, it had the unintended consequence of showing people photos of their recently deceased loved ones, causing pain and suffering for their users.2

As industries are turned upside down--disrupted--and technology has been pushed into every part of our lives, we have to evaluate the effects of our products like never before. Not only the direct effects, but also the side effects. People are often willing to take the leap into a new technology to avoid FOMO (fear of missing out) or seeming like a luddite, but the long term or side effects are typically not given much thought.

For technologists, the more widely publicized ethical questions tend to center around privacy on sites like Facebook and Google, or what liabilities and responsibilities do companies like Uber and Airbnb have to safeguard their customers. Neither Uber nor Lyft are handicap accessible; if it’s “just” a platform for other people to “share,” do they have to conform to the ADA (American Disabilities Act)?

“In our times people are often willing to make drastic changes in the way they live to accord with technological innovation at the same time they would resist similar kinds of changes justified on political grounds.”1

Given that there are no formal licensing, education, or requirements to be a web developer, there are also no formal ethical guidelines by which they must abide. Computer science courses may include some mention of ethics, but six week code schools generally do not. Many tech companies are lead by engineers, whose focus can easily become the technology and not the people using it.

Designers, and anyone involved who can take a step back to get a big picture view, have to ask these questions. How will this product affect its users, both short term and long term? Can all people access this product? Will this product have any affect on the community, and can or should any negative effects be eliminated, mitigated or addressed in some way? Pokemon Go got people outside, exploring, and getting exercise, but it also caused people to walk blindly out into traffic or even off cliffsides. Perhaps the benefits outweigh the problems, but perhaps there was also a way to design with this problem in mind.3

How can you know all effects that a new product might have once out in the wild? It’s impossible to predict everything, but with some exploratory research, it is possible to uncover previously unforeseen impacts. One-on-one interviews with potential, current, and past customers and usability studies can offer a wealth of information. But you have to look beyond the obvious and ask the questions that may not come up in a typical development cycle.

When a large new construction project is being proposed, typically the site will undergo an impact assessment; most commonly economical but also environmental. What long range effects on an area will this project have? Will it increase jobs? Drive up neighboring home prices? Is it being built on a watershed or nesting ground?

Beyond construction, there are also social impact assessments:

"Social impact assessment includes the processes of analyzing, monitoring and managing the intended and unintended social consequences, both positive and negative, of planned interventions (policies, programs, plans, projects) and any social change processes invoked by those interventions. Its primary purpose is to bring about a more sustainable and equitable biophysical and human environment."4

We could draw on these ideas and apply them to technology. Should a company be required to do social impact studies for every new app or feature they want to build? That seems like overkill, but it is true that companies are responsible for the effects their products have; certainly all of the companies mentioned in this article has seen their share of lawsuits.

One could hope that technologists can push the industry to consider ethics and impacts with a more holistic view. Europe seems to be leading in this area with the European Parliamentary Technology Assessment5 network, although they tend to be centered around bioethics, public health, and energy. In the United States, advocates have pushed to ensure the accessibility of all federal websites and apps through Section 508.6  As technology takes over more and more of our everyday lives, technology companies will be forced to step up as the public and policy makers demand it.

  1. Langdon Winner, Do Artifacts Have Politics, 1980
We Can Do Better Tue, 24 Jan 2017 19:54:00 +0000 Matthew Oliphant The five of us entered a restaurant across from the Sai Yee Street Garden on Soy Street in Hong Kong. We’d been walking around Mong Kok for a while, looking for a place to eat. Nothing was looking good, but we figured, enough walking, let’s just go in and eat.

We’d been at Savannah College of Art & Design - Hong Kong earlier in the evening and while there were snacks (and a tour of the cool, previously-a-jail building) it was past time to eat real food. Some of us were getting hangry.

We were shown to a table near the open kitchen. Handed menus. Almost immediately Amber, our guide for the evening, said something to the extent of, “Matthew, you’re not a vegetarian, are you?”

In fact, I am. Been that way since 1994 or so. Usually that’s neither here nor there. But when you are at a conference, in a city you don’t live in, in a country where you really don’t speak the language other than to ask for the bill and say “thank you,” being a vegetarian becomes here and there.

“There’s nothing on this menu you can have.”

Usually when I hear those words, it’s an exaggeration. In this case, there was literally (classic definition) nothing on the menu that didn’t have meat on it or in it. Even the items identified as vegetarian (shaved pork sprinkled as a garnish on steamed lettuce!).

But that’s fine. For me, in that moment, or any like it, I really don’t want to be the one person that others have to work around. Everyone else was fine with staying, including me.

Amber wasn’t. She was in full-on host-mode. She closed the menu, stood up, and declared, “Come on. We can do better.” I was the only one who protested. We got up, went down the street, and we actually did do better. Better food, more choice, better ambience, and everyone was included.

Amber’s “we can do better” has always stuck with me.


Looking for Better

For most software, iteration is the name of the game. You build the first version, let’s call it the Minimum Viable Product (MVP) and if that version finds enough success to warrant version 1.5, then version 2, etc.

What interests us is what happens prior to all that. This is the stage for all decisions you are able to make in the future. Exploring opportunities, validating hypothesis, and forming an idea. Then on to Alpha, Beta, Beta 2, Beta 3 …

Here, getting things right, doing better, can make all the difference.

We start with an hypothesis. We have to in most cases as there’s a budget to consider and even when we’re doing exploratory research, we’ve got to scope our exploration to something. But at the same time, if said hypothesis doesn’t pan out, we toss it out and start with a new hypothesis based on the data collected to that point.

The data we collect is based on interviews, surveys, usability testing (of current and potential interactions and processes), and a number of other methods. For the most part, the plan is to build confidence that we’re on the right track to “better,” whatever that means in the context of the project.

Which Leads to an Idea

“I want to build a new social network.” What you really want to do is make something that connects people online. You want to make it easy for one person to make another person laugh by posting a picture with the caption, “Remember this?” You want to enable people to get things done together. You’d like to make money while doing it.

Whatever the idea you have, it shouldn’t be stated in terms of a solution. It should be stated in terms of goals and outcomes. It should be centered on people.

This isn’t a difficult concept to grasp intellectually. You probably agree with me. And yet, we see terrible apps all over the place. Apps with such ridiculously minimal functionality you wonder if those building it fell asleep part-way through.

There’s that word. Minimal.

You down with MVP?

Build just enough of a product to put it out in the world, let anyone and everyone give you feedback. See if your idea is viable. It sounds very reasonable.

There is evidence to suggest it’s a really good idea. But I don’t think the way “minimum” and “viable” are typically defined lead to good outcomes. Sometimes good outcomes are lucked into, but that’s not a good foundation on which to build a product or a company.

“Minimum” as a modifier gets placed, within conversations, wherever it needs to be to make the person’s point. More often than not, “minimum” is applied as a modifier to “product.” These are the bad conversations; the ones that focus on the minimum amount of functionality that needs to be built for people to use said product. It skips over viability.

When people ignore the viable part of an effort, they are essentially saying, “Let’s build a Minimum Usable Product.” If you are doing this on purpose, fine. But call a MUP a MUP.

When the conversations use “minimum” to modify “viable” I think this is closer to the point. I suspect most people would say, “We totally do this! Not that MUP thing.” Maybe you do. But I don’t think it’s enough.

If you’re saying, what’s the minimum amount of effort I can put in to get the maximum amount of reward, well … you’re speaking my language. But if you’re saying, let’s put in the minimum amount of effort and we’ll see what happens, well, you’re just making stuff up.

Viability defines what it takes, as a baseline, to live. In the product world, that would define the core functionality or feature set that is needed to be successful on its own.

Everything done after viability is met enhances what is there (or becomes bloat because you’re supposed to always keep adding on to a product, right?).

A viable product doesn’t deliver 30% of the features with the hope that things just really take off and you can then have the support you need (eyeballs, clicks, users) to finish out that pesky 70%.

What does this mean?

A company’s reputation feeds as much into its ability to turn a profit as does the things it creates in its operations. Your design should take that into account. The people who approve your deliverables should understand that. The people that sign the cheques should demand it.

It’s on all of us to stand up, be good hosts, and say “We can do better.”