Ways of working as a Digital Product Designer

A summary of some techniques I use when working with digital products

8 min readSep 2, 2017

Back in the uni where I was studying industrial design, our professors in the design studio courses tough us very early on that by working as a product/industrial designer, what we would actually be doing is creative problem-solving.

Developing digital products is no different! You apply the same techniques and principles in order to solve user problems. Because you are working with digital products though and the process is iterative, you have to be able to assess what the real challenges are, prioritize them, produce solutions and measure their effectivity. Creative problem solving is a cornerstone skill that separates good from great design.

In this post, I will walk you through my approach for working with digital products. At MOO, I use these techniques to tackle problems regarding our internal tools and also the customer facing of template browse pages. It doesn’t matter if you are working with SaaS, Enterprise or E -commerce products because these problem-solving techniques can be implemented in any kind of product/system. So here we go!

OOUX (Object Oriented UX)

Although digital products are crafted in code and not physical materials, software experiences derive their reasoning from the same source as all products: a relationship between the user and the object, where simple inputs are transformed to useful outputs for solving meaningful tasks. If you think about it, this is also how backend engineers work. In the ’80s, the software engineering community began to transition from procedural languages like C, to object-oriented languages. Today, most software developers bring our designs to life using object-oriented languages like Java, Ruby, Python, C++ or C#.

In his 1995 book, Designing Object Oriented User Interfaces, designer and engineer Dave Collins argues that basing both front-end and backend design on object-oriented principles “brings coherence to the software development process. Object-orientation reveals deep structural correspondences between the artifacts of analysis, design, and implementation.”

So how do we apply OOUX into practice? In her amazing article, Object-Oriented UX, Sofia Voychehovski explains really thoroughly the process which can be boiled down to 4 steps:

1. Extract objects from goals

The result from user research is usually a list of goals that users hope to accomplish in the system. We can highlight nouns inside the goals and extract objects from nouns tactfully.

2. Define core content inside objects

After having a list of objects, it is time for us to add detailed content to each object, which contains core content as well as metadata which can be used to filter/sort the object.

3. Nest objects for cross-linking

Now each object has its content and comes to life. This step is to find the inner relationship between each object in order to understand how this object is connected with its sibling object.

4. Forced ranking

This step is to reorder the list under each object, from most to least important.

I use OOUX early on in the design process, in order to map out and construct the base layer of the system that is going to be designed. I involve the key stake holders, apart from the devs and my PM that is, and together we collaborate on building the system object by object. When this is done, I use the GAP approach to identify the interactions and steps of each user path.

The Gap Technique

This technique was first introduced by Samuel Hulick in his article “Product People, Mind the Gap!”. To articulate his point, Samuel chose the story of making a peanut butter jelly but I will go with a different one. Let’s suppose that: You want to buy a book from Amazon. What are the steps that you would follow in order to achieve your goal? Quickly, someone would say:

Go to amazon.com
Find a book
View the details for a book
Add the book to the shopping cart
Checkout

It looks pretty straight forward and accurate right? Well, there are many things happening in between those steps that we failed to capture. In most cases, these steps are actually always nested. We can demonstrate that by expanding our example above:

As you can see, by adding additional detail provides more and more clarity regarding the steps that our users would make in order to achieve their goal. Because with the Gap technique you can identify and construct a story about what the persona does with the software, it is a very good way for stakeholders to connect with and talk about.

Here’s how you can apply it:

Pick two points of progress in the story
Break down what happens “in between” of those steps
Repeat steps 1 & 2 for the gaps between each of those points

If you leave too many “gaps” in between the steps, you risk creating a story that has logical holes and is not coherent with your users mental model. For that reason, it is crucial to know which details to focus on and which ones to skip. Anytime we decide to skip a particular step (or mini-step, or even mini-mini-step), we are effectively saying “users will figure it out on their own”.

Most of the time I use this technique when I am done implementing OOUX and I have my system in place and I know the relationships between objects and how they are connected with their sibling objects. That way I can start crafting flows and slowly figuring out the basic steps and then deep dive on each step in order to discover the nested ones. Also, I usually have a feedback session with the team, my PM and devs, so that we can optimize and finalize the flows.

How Might We’s

That one is quite common and I use this all the time from my uni years till now. Basically, you reframe Problems as standardized challenges. After you have your system with objects and your flows, you rewrite each one as a standardized challenge or user story. This will help create an array of solutions and be a little bit broader at the start.

Let’s look at an example: “ How might we ensure that users of X product are able to see multiple projects in the projects page”. Here’s how you can apply this technique:

Each team member is given in 5–10 minutes to write as many possible ways to tackle the How Might We challenge without any discussion. Removing discussion insures a variety of diverse solutions. Of course, some might be the same but that’s a good thing! Solutions don’t have to be written in any particular way they could be only written solutions or quick sketches — but they must be understandable for people who are reading them.
Then you dot vote the solutions. This could take up to 10–15 minutes. Each team member gets 3 to 5 dots to vote on the solutions they think would best solve the problem. Of course, the number of the dots each member has depends on how many are attending the session.
Prioritize the solutions. Just like we did with the problems, the team now has 30 seconds to make a prioritized list of solutions. A rule of thumb is to ignore anything with the less than two votes.
Decide which solutions to implement. By now, you should have solutions which are more popular than others, but it’s important to also know how much effort is required to implement them. That’s why an effort/impact mapping of the solutions is necessary in order to get your solutions into your product backlog. Take each solution and add them to the effort/impact quadrant. Effort, in this case is how much effort the team thinks it will take to implement and impact is the degree to which the team thinks it would solve the problem you’re trying to solve.

I highly recommend doing this with your core team. For example at MOO I use this with the devs and the PM of my team in order for everybody to have a clear overview which high-impact and low effort (aka low hanging fruits) solutions will be executed on phase one of the MVP along with the must other must haves and also which ones are for later iteration.

Bonus: Hypothesis Backlog

When you get influenced by your fellow Designer colleagues regarding your design process, then you know you are working at a good company! I was first introduced to this technique by Mel Hambarsoomian at MOO.

So basically, this came from the need of having a way of packaging problems and opportunities so that you could relay them back to PMs and other stakeholders, and then work together to get a priority. And because these problems need their own space, the actual backlog is not a place to add them, a new separate backlog was created called: “Hypothesis backlog”.

It’s a collection of opportunities to improve the product — some guesses, some validated by research. But likely, the prioritized ones need further discovery and problem validation. It’s is not a backlog in the sense of a stream of work for developers or a roadmap for the Product (but could end up becoming part of these things if prioritized and validated).

At MOO, our teams use the “Hypothesis backlog” to align stories or even quarterly OKR’s so that we can work more closely to each other and create coherent experiences. The key point here is to get buy in from the PM’s and have meetings for deciding how to move forward with these opportunities and integrate them in the product roadmap.

References

I did not invent the techniques above, nor I will take credit for them. I just want to share with you my go to techniques and I do know you might have your caveats regarding these but hopefully this post can help you creatively solve problems and maybe establish a process. For those who want to read the actual posts, I provide the references below: