nTop was designed to make 3D modeling feel seamless with the use of generative design. The visual programming functionality of nTopology is what drives the user experience, and the interface built to enable that is called the ‘notebook’. This is enabled by a system of modular blocks that can seamlessly integrate with one another to allow anyone to capture important workflows, embed them with designs for downstream use, and carefully control necessary variables and parameters. Operations are done in the notebook by using “blocks.” Each block performs a function on its inputs.

Some ‘blocks’ allow function overloading capabilities which is a familiar behavior for programmers. This feature allows users to define two or more functions with the same name in the same scope. (eg. Function (x, y, z))

Block overloads are difficult to use for users that are not familiar with programming principles. The UI design for overloads should guide users through the process of picking a function.

Hard to use

Difficult to know when there are other block options

Even when I know where the options are, it is an extra two clicks away when I already know what I want to use and how I want to use it

“Can they just be automatically picked based on what I drop in?”

Sometimes they may have a different number of inputs, so the blocks move up and down a bit when picking items

With slicing blocks, it is unclear whether something is automatically converting in the input, or if we are running a block specific to the type. If we make it an overload, this compounds the problem.

I needed to understand the users’ needs and frustrations in order to narrow down the problem and inform future design decisions. I decided to map out the current user journey when using overloads and I was able to identify the pain points that matched all the feedback we had received with this feature in the past.

After reviewing rough mockups with some product managers and designers, we started to understand the steps needed to improve this feature. We needed to draw a solution for auto detecting the overload type, and make it clear what is happening in the block UI and also make overload names clearer. In my ideation process, I came up with a few ways to approach the problem.

Blocks can open with a default overload, and autodetect changes.

Block can open in an ‘empty state’ and only emerges with correct inputs, once overload is selected.

Due to the time constraints of our release cycle, we could not test with customers. So I was able to conduct a moderated user test with a group of users from our internal team.

I set up 1:1 meetings with each testing candidate and was able to observe as they tested 2 prototypes that I prepared. Each prototype was paired with a test scenario with guiding questions.

After consolidating feedback and reviewing with the product team and engineering team, we decided the solution needed to be a combination of prototype A and B. Due to architectural limitations - there needed to be a default overload picked, but the UI needed to make it clear that overloads can be changed and auto detected. We also needed to address edge cases and errors.

Our goal was to make overloads easier to use and according to our customers who have expressed sentiments, we succeeded in improving usability.

Internal testing can be extremely valuable, but always scope and plan for testing with customers to further validate.

No need to rush design decisions that affect day to day flows.