Illustration by Kinnari Parikh

Ways of working as a Digital Product Designer

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

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#.

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.

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:

  1. Go to
  2. Find a book
  3. View the details for a book
  4. Add the book to the shopping cart
  5. Checkout
  1. Pick two points of progress in the story
  2. Break down what happens “in between” of those steps
  3. Repeat steps 1 & 2 for the gaps between each of those points

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.

  1. 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.
  2. 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.
  3. 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.
  4. 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.

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.


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:

OOUX — Object Oriented UX

Sophia Voychehovski (

Product People, Mind the Gap!

Samuel Hulick (

Hypothesis Backlog

Mel Hambarsoomian (



UX Designer @Google Maps, film lover, guitarist, and former Industrial Designer by trade. Website:

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Ioannis Nousis

UX Designer @Google Maps, film lover, guitarist, and former Industrial Designer by trade. Website: