post

B2B product management

Artificial Intelligence (AI) & Machine Learning (ML)

Building Product Teams

Business Strategy

Data Driven Product Management

Digital Transformation

Diversity and Inclusion

Minimum Viable Product

OKRs

Prioritisation

Product Design

Product Research

Product Development Process

Product Ethics

Product Discovery

Product Leadership

Product Management Career

Product Strategy

Stakeholder Management

🌎 <a href="https://www.mindtheproduct.com/world-product-day/" style="color:#FFFFFF;text-decoration:underline;">Happy World Product Day!</a> Be sure to celebrate product, yourself, and your peers today! 🎉

Successful product management in companies where it’s least understood

Measuring critical user journeys – Javier Andrés Bargas-Avila (UX Director, Google)

A new way to look at applied experiments

Product survey findings: Only 15% of users are embracing AI features 

Building high-performing product teams: The PDLC approach

Footer About

Footer Contribute

Footer Get Involved

Footer Links

Mind the Product

Guest Post

Overcoming the 20% feature usage challenge

Product Management

Three product leaders to learn from at #mtpcon inside Pendomonium

Juan J. Ramirez is a seasoned Product Manager and UX Specialist. He works as a Mobile UX Designer at Procore Technologies in Santa Barbara, California. Previously he was a Product Manager for Seconds.com, Contactive (Acquired by Fuze) and Usuallee. He holds a M.E.T from Carnegie Mellon University. He earned his Bachelor's degree in Business Administration from CESA Business School, in his home country, Colombia. 

Contact him:

<a href="https://www.linkedin.com/in/juanjoseramirez">LinkedIn</a> //

<a href="https://twitter.com/whoisjuan">Twitter</a> //

<a href="http://whoisjuan.me">www.whoisjuan.me</a>.

Juan José Ramírez

One month ago I subscribed to <a href="https://digit.co/" target="_blank">Digit</a>, a service that promises a way to “save money without thinking about it”. The way it works is simple – you submit your mobile number, link your bank account and you’re pretty much set. There are no apps, no user interfaces or additional confirmations.
The only thing Digit asks you to do is save their phone number as a contact, as once you’re subscribed, interactions occur exclusively through SMS. These text messages inform you about your daily balance and give you a snapshot of how much money they’ve been saving for you. If you text a word like “balance”, even with typos, you get your current bank account balance right away. Flawless.
This product has been making me rethink many of the things I have learned about designing digital products. One of the reasons I find this kind of interaction so intriguing is that digital products seems to be always created in the context of a user interface. I can’t remember a single one of my projects that didn’t start with a UI sketch or a rough wireframe, but now there are amazing companies like Digit creating UI-less products.
So, why are we so used to imagining all digital products under the light of some graphical user interface? Are there any other approaches to designing digital products without thinking in a user interface (even if we end up with one)? How do we design for the future?
<figure style="width: 371px" class="wp-caption aligncenter"><img loading="lazy" decoding="async" class="" src="https://c2.staticflickr.com/8/7079/7173388694_8ec6778019_h.jpg" alt="UI sketch" width="371" height="313" /><figcaption class="wp-caption-text">UI Sketch</figcaption></figure>
To answer these questions, I went through three years of my own product and UX documentation. I compared it with course material from the Human-Computer Interaction Institute at Carnegie Mellon University to try and come up with a product design approach that is less graphical and more conceptual.
The approach I’ve taken refers to the part of the product process in which we are designing the service, not the stage at which we think about the problem and the high-end solution idea. Think about the Digit example. You wouldn’t use this approach to find the problem (people struggling to save money). Instead you would use it to find out how to solve the problem (how to create a service that helps people to save money).
Coming up with a modern approach
Current product design approaches have been influenced primarily by the modern GUI concept popularised in the late 80’s and the development of the World Wide Web in the 90&#8217;s. Before this, most of the approaches to designing software products, while still user-centred, were based on the ideas of outputting a single result.
[Tweet &#8220;A GUI is a medium to deliver the service and not the service itself&#8221;&#8221;]
When designing a digital product you should always understand that a GUI is a medium to deliver the service and not the service itself. This means that when creating a solution to a problem you should focus on the final result. Digit, for instance, could have created native apps for Android and iOS to deliver their service. Instead, they created an agnostic solution that is cheaper and as good (or even better) as having two standalone apps. They understand that designing a product is not a matter of user experience optimisation but rather a matter of providing a real solution to a real problem.
The Approach
Before going through this approach I want to make it clear that this philosophy doesn&#8217;t reject the idea of having a GUI. It is very likely that your end solution requires a GUI to exist. What this approach proposes is an extra layer for the ideation process. This layer goes between the stage of coming up with a high-end solution and prototyping that solution.
While researching product ideation methods, I encountered a method I feel is a perfect match for this philosophy. The paper where I found this methodology is an IDEO essay published in CHI ’95 Mosaic of Creativity, titled “<a href="http://www.sigchi.org/chi95/proceedings/orgover/ps1bdy.htm" target="_blank">Interaction Design at IDEO Product Development</a>.”
I’m borrowing this methodology and using it as the backbone to my proposed approach, with some adaptation so you can easily add it to your product workflow.
The methodology consists of a process of five stages: 

<ol>
<li>Understand</li>
</ol>
The first thing you should do is familiarise yourself with the competitive landscape. Of course, as a good product professional you are already familiar with your competitors, but it’s always good to check your assumptions. After doing a small competitive analysis, you should create a document outlining your strategic ground: goals, advantages and disadvantages, context of the problem, high-end solution, etc.
<ol start="2">
<li>Observe</li>
</ol>
Observe your users dealing with the problem. If you’re trying to improve certain interactions, find potential users and record them using the current available solution. If the problem is too abstract, try to collect information that shows how does your potential users deal with the problem. This may be something as simple as a Tweet or a forum entry, and as detailed as a video product review. The objective is to find patterns in user behavior. Later, when you have a functional product, you will be able to collect data and iterate the product based on this data.
<ol start="3">
<li>Visualise and Predict</li>
</ol>
Gather all the data you have and use it to create sample scenarios with fictional characters. You can use personas if you want, but the most important part is to sketch the interactions. You might like to use storyboards or user enactments, but resist the urge of drafting a wireframe. What you want to do is predict how the end product would be used, the context in which would be used, and the functionality it would provide.
Sounds confusing? Think about the Digit example. We know that people don&#8217;t save money because they find it complicated and cognitively expensive. We also know a good high-end solution is to automate the process of saving money. So, what are the key tasks that we need to address? Is the process of moving money from your checking account to your savings account? Is it figuring out how much money you should move? If you understand where these questions are coming from you get the idea.
Now, at this point it&#8217;s fair to ask why we are avoiding the process of sketching a wireframe. Let me ask you a question, do you really need a graphical user interface to provide this solution? As far as we are concerned the potential solution is a technology that does two things. It moves money from one account to another and it figures out the amount. This doesn&#8217;t mean that the final product can&#8217;t be an app with a GUI. It only means that we don&#8217;t want to rule out any potential solution by jumping straight into the conclusion that this must be a native app.
<ol start="4">
<li>Evaluate and Refine</li>
</ol>
On this, the IDEO paper states “the boundary between this phase and the previous one is often blurred, and designs typically pass through several iterations of visualisation and evaluation before a design is finalised.”
You may be wondering, what design? At this point you already have a clear scenario on how the product would be used and the functionality it provides. You need to run through the storyboards with your potential users, get feedback and update your scenarios on the basis of the feedback. Remember that for this particular approach those scenarios are your proposed solution. At this point you can start doing some UI sketches based on the data you’re collecting. However always have this question in mind: Do I really need whatever I’m considering to provide this solution? Often the answer will be yes, but since you have been resisting the urge to prototype a GUI you now have a clear picture on what is essential and what&#8217;s not.
<ol start="5">
<ol start="5">
<li>Define</li>
</ol>
</ol>
Finally, take all the material and documentation you have created and extract the most important and relevant information. You want to end up with a document that describes how your users reacted to the scenarios and how relatable those scenarios were to them. It would also be helpful to document any relevant data or insight based on the feedback or even your own intuition.
The Future
After completing the five-stage process you will have a document that is an invaluable prototyping asset. You may be wondering how this process differs to a classical approach. Most product professionals start with a high-end solution and jump directly into wireframing. Then they run those wireframes past their potential users and they iterate based on the feedback they get from them. The problem with this approach is that they’re not showing the users the intrinsic solution. They’re just assuming that their implementation is the correct solution and they’re missing a world of user feedback by doing this.
In the near future we will have smart phones, smart accessories, smart cars and smart houses. The approach I’ve outlined here will give you a way to consider solutions that may be suitable for any of those platforms instead of you instinctively making that decision.
[Tweet &#8220;Ask yourself “Am I designing for the future?”&#8221;]
The challenge of designing for the future is that as the amount of available technologies increase, so will the odds of creating mediocre products. As a product professional and enthusiast, I invite you to reconsider your methodologies and ask yourself “Am I designing for the future?”
Some final comments
I don´t have any kind of relationship with Digit. I’m just a fan of their product.
The purpose of this article is to invite you to think more about your product design approaches. You may not find it useful or maybe you&#8217;re already doing something similar so it feels redundant. If that&#8217;s the case please let me know in the comments.
<div class="g g-21"><div class="g-single a-170"><a class="gofollow" data-track="MTcwLDIxLDEsNjA=" href="https://www.pendo.io/pendomonium/"><img decoding="async" src="https://www.mindtheproduct.com/wp-content/uploads/2024/06/MTP-Footer_ad.png" /></a></div></div>

core/freeform

10x Product X Design: Product and research team collaboration by Jane Austin

Learnings from London: What is it like to hold Google in your hand?

Learnings from London: How to build a billion dollar app

Product Systems: How to manufacture lightning in a bottle by Oji Udezue

Product management meets UX design by Tanmay Goel, Emi Kwon, Simran Kaur

Designing a sustainable future by Leyla Acaroglu

Making Hard Product Decisions for All the Right Reasons

Product Vision 2020

The Importance of Empathy, By Jack Sheppard

Design for the Developer Experience by Kevin Page

Stop Thinking About User Interface: A Product Approach for Designing Products of the Future

Stop Thinking About User Interface: A Product Approach for Designing Products of the Future

Juan José Ramírez

Comments

Read next