michelle turcotte

case study

labview sharing

creating applications and code libraries can be hard.
sharing them doesn't have to be.

running short on time? check out this overview video—it's under 2 minutes ☝️

user goal: share a code library or application created in labview nxg (or install it on test machines).

the problem: sharing and publishing content in labview nxg pre-2018 was confusing and error prone.

the team:
me (interaction designer)
visual designer
ux researcher
technical writer (documentation)
product owner
marketing feature owner
technical lead
developers (5)


user research

i started by interviewing internal stakeholders and subject matter experts, then had a few conversations with external power users to get their perspective. these conversations were helpful to get the perspective of advanced users.

the most impactful insights for our broader customer base came from a series of customer visits that i conducted with my product owner. seeing the context where some users worked (like a basement office) and hearing how they shared files (e.g., on a usb stick carried by hand between offices) led to the goal of a simpler and more linear flow for the primary use cases.

technical constraints

labview nxg libraries and applications are distributed and installed using a package manager. creating packages with all the needed information is a bit more complex than just sharing the files.

animated gif from the movie emperor's new groove of a box going into another box with the caption and then i'll put that box inside of another box animated gif from the movie emperor's new groove of hands picking up a box and placing it on a doorstep with the caption and then i'll mail that box to myself

there were also several constraints of the platform we were building on (while it is software, and as one of my development partners used to say “anything is possible in software”, not everything was practical to build in a reasonable timeframe).

existing workflow

the first version of this workflow was designed without input with from the ux team. while it was technically functional, there were several usability issues:

tl;dr: the process was nonlinear and highly manual, and it didn't help the user succeed.

animated gif from the tv show star trek deep space 9 of captain sisko talking to a woman with the caption it's difficult to explain, it's not linear

competitive analysis

outside of command line tools, there are only a few applications for creating packages, one of which is was from adobe. while i didn't love their use of a wizard pattern, i did appreciate the clear way they grouped required inputs and settings. other places i took inspiration from included xcode, visual studio (and vs code), mac app packaging, and google photos.


design brief

i ensured stakeholders were aligned by capturing learnings and high-level goals in a design brief:

pdf can't be displayed; download instead.


while i wasn't able to find my sketchbook from 2018 (and i don't have the same digital trail of everything from then as i do in our current virtual work environment), you can imagine several explorations similar to these from related projects:

early ideas included everything from a wizard (one of my least favorite ui patterns) to a single-click publish button (not feasible due to aforementioned technical constraints).


i enlisted the help of a colleague to do some brainstorming and asynchronous collaboration, since his work in hardware dependencies overlapped with mine (and two designer brains are always better than one).

low-fidelity wireframes

i mixed and matched ideas from across these early explorations to land on an initial idea to test: a single-page (scrolling) document with a top-down linear flow of information and interactions.

testing & iteration

first prototype & usability testing

i created this prototype in framer (the original version, later known as framer classic):

i worked with one of our talented ux researchers to define the goals and test plan for this initial round of usability testing.

from this first round, we learned:


there were several changes, large and small, that i made to the design based on those learnings, but here are a few key iterations:

in addition, i collaborated with one of our visual designers to improve the layout and typography.

second prototype & more usability testing

with the design iterations, i updated the prototype to make it more robust:

nerdy aside on prototyping tools: i miss the original framer (a.k.a. framer classic). sure, the learning curve was pretty steep, but it was incredibly powerful for advanced prototyping. i mean look at these prototypes—they had it all! tooltips, right click menus, multiple logic paths, interactive text fields with form validation!! figma's great and all, but it's no framer.

once again working with a ux researcher to conduct usability testing (this time remotely, which way less common for us at the time), from this second round we learned:

armed with these learnings, i began refining the design and getting it ready for implementation.


design specs

after refining the design and working through the edge cases, i put together a design spec for development:

pdf can't be displayed; download instead.

collaboration with developers

of course, i don't just throw a spec over the wall to development. my involvement continued through implementation: answering questions as they inevitably arose, making minor refinements to the design as new technical constraints and edge cases were discovered, and identifying staging opportunities to meet tight deadlines.

final product

in spite of tight deadlines and shifting priorities, the development team was able to implement the majority of the workflow as designed:

for comparison, here are the original documentation instructions and the new instructions, complete with two fewer steps (notice how many things happen automatically now):

closing thoughts

there are a few things i would want to change (for example, getting the build target field into the main document space, as well as time to work towards more visual polish in the final product), but overall i'm pleased with the design direction and what the team was able to accomplish.

if you've made it all the way through this case study—congrats! it ended up longer than i was hoping, but much like a prototype, i left out a lot in favor of going through the “happy path”. the much longer story is evident in the number of pages in my final sketch document: