Process Evolution

Introduction

This case involves the creation and evolution of the design process at NI. The process we have today did not occur organically nor was it perfect when we started. During my time at NI, I have frequently defined, evaluated and re-defined our design process to be better than we were. Our design process today is not a concrete set of instructions but does provide a consistent framework we use to approach and solve problems. Due to the engineering-focused culture of NI, a design process was an unfamiliar practice and most engineers had never worked with a designer before. Having a defined process has given us a simple way to communicate with engineering about how we approach problems, how they are involved in that process and what they could expect from us. This simple framework (and its continued evolution) has provided engineering with consistent expectations of working with the design team and built our credibility as a new practice in a richly historied culture of engineering. While the process we have today accomplishes those goals; it was a different story when I first started in 2011.

2011 - The Beginning

When I first began at NI, I was one of the few founding designers (4 designers total) in a newly formed UX team for R&D. There was no legacy process to use as there was no legacy design team using it. In this first year, my goal was to simply understand how designs were produced in the current environment and address the most apparent issues if there were any (spoiler alert….there were). After experiencing a couple small design projects, the culture was this:

There was no process

• As mentioned earlier, a structured design process never existed before. This was all new to the engineering team. Previous to our existence, a design was commonly done by the developer implementing the feature.

Design by committee

• There was no clear ownership of design decisions.
• Decisions often went with whoever was loudest or talked the most.

We were in the midst of a shift to an iterative development environment

• The engineering teams were making a transition to work more iteratively, just as most of the development world was doing in 2011.

There were 4 designers supporting 400-500 developers

• While there is no absolute correct ratio for designers to developers, 1:100 is way off.
• We were going to be a bottleneck if we tried to design all the features that were being built.

Not all of these problems were going to be immediately solvable, but there were a few simple things we could do to start. Having previous experience designing in an iterative environment and previous experience helping to start an internal design practice, I knew the most important thing, to begin with, was setting expectations in our own design team as well as starting to set an expectation to our engineering and other product partners, like marketing. This led me to the first definition of our design process, titled simply, “UX Process - How we solve problems” This presentation had two core messages to convey:

A base level description of the design process

While I did dive into some of the specific exercises we perform such as stakeholder interviews, use case development, and prototyping; this was more a 101 level description of the design process.

Understanding how design and iterative development work together

This piece of content illustrated the speed at which you can move but the inherent risk of churn and failure it introduced. The main goal of this content was to communicate how important planning and correct problem definition was at the front of the process. If you don’t a clear endpoint in mind, you may not end up where you thought. I attempted to communicate this point through a series of photoshopped Mona Lisa’s displayed in the style of an ‘ole progressively loaded gif.

The risks of not planning ahead in an iterative development environment.

For the first year, accomplishing the goals was fairly straightforward. Anytime we started a new project with a team, I would walk through this presentation and set expectations of what a designer did and what they brought to the table. We also incorporated a Discovery phase into our projects to ensure we were pointed in the correct direction with a proper understanding of the goals of the project.

2012 - A little more formality

After my first year, our team had doubled in size (we must have been doing something right), we were taking on more projects and working with more engineers. Over the past year, I had learned which exercises were more successful in our environment and which did not provide as much value. For example, for most new projects the stakeholder interviews continued to be one of the most valuable places to start. It provided each stakeholder with an introduction to the designer and allowed the designer to learn where the team was already aligned and identify any gaps or inconsistencies that may need to be addressed. It also allowed the designer to get a sense of how success for the project would be measured.

The year prior, I had provided a basic skeleton of the process along with a laundry list of things designers do. At this point, I could focus that list on what designers at NI are likely to do for most projects. For example, we weren’t going to be doing many mood boards as deliverables. While valuable for many projects, they weren’t very necessary for the types of features and projects we worked on, despite how fun they are to make. Along with that refinement, our larger design team needed to begin having a common vocabulary for how we communicated our process as some engineers would work with more than one of us. With that information, our goal for the year was to provide a bit more structure to our process and create a simple infographic that we could use to more easily communicate how designers worked.

From the start, we had a few existing artifacts to help inform an infographic. As a team, we started to explore ways to consolidate this information into one visual.

As most UX design projects, we started the concepts in wires in order to quickly generate a few ideas.

Members of the visual design team began generating higher fidelity mock ups.

2013 - Getting technical, consistent and unified

Fast forward 12 more months and our previous efforts were not going unnoticed. Our team was still growing, we were strategically working on the right projects and even some engineering teams were giving up some of their own hiring requisitions so that we could continue to build the design practice at NI.

With the design team growing at a rapid pace, we already had a solidified structure to our design approach but we were struggling with a clear delivery of the final assets. Our interaction and visual design teams worked together but delivered separately. Also, the final resting place of any deliverable was at the whim of the designer. Unfortunately, in our development environment, there are times when a design is finalized and documented but still may not get implemented for a few months. Going back and tracking down all the latest deliverables was causing frustration and confusion on the design and engineering side. We were working fast and furious and our organization, or lack thereof, was causing issues transitioning design to development. There were three things we focused on improving for this next phase of our process evolution.

Unifying our deliverables

Use the same toolchain We were using just as many design tools as we had designers. Some used the Adobe suite (including yours truly), some used Omnigraffle, Axure, Visio, Fireworks, Expression Blend/Design. With this, we were not able to easily leverage each other’s assets or designs. The time had come for us to pick a toolset and stick with it. Long story short, we now use Illustrator for most designs and InDesign as a documentation tool. I may have played a small role in advocating for the Adobe Suite (what can I say, I’m a fan). It also helped that Adobe had just launched Creative Cloud and license management was about to get a whole lot simpler. Nonetheless, we all now could easily collaborate on designs and share files. I also provided templates, symbols libraries and training to the team to ease the transition.

Unified deliverables Prior to this, the interaction design details were a separate document than the visual design information. If you were lucky, those documents resided in the same place. Quite often, they did not. With our new ease of collaboration from a shared toolchain, we focused on a unified deliverable. Even if the visual designer was getting started after most of the interactions had been defined, they could still contribute to the same design deliverable. Through Creative Cloud, they had access to all the source files, so integrating their content into an existing document was simple. It also allowed either designer to easily go back and update the shared file if needed.

Put it all in the same place We were delivering content via network servers, Sharepoint, e-mail, an internal wiki and enterprise collaboration intranet. Unless you knew the designer who worked on a project your chances of tracking down the content was pretty slim. During this phase, I drove us to use our collaboration intranet to communicate, discuss and deliver our final documentation. It was now possible to search for any specific deliverable and feel confident you knew where to find it.

2014 - The big push for integration

After a few years of evolution and refinement, things were running smoothly on the design side of the house. Our clients know what to expect of us, they had a better understanding of how we solved problems and we had successfully built a great deal of credibility in the organization. The next logical step was formally incorporating our design process in the larger product development process. This encompassed the full range of the process from product definition to final implementation. All teams (design, marketing, engineering) were asked to build their own version of an ideal process for us all to work together. Afterward, we all met in a summit to share our work. I was asked to provide the version from the design practice so I began collecting information from the members of the design team to learn from past experiences to help inform our future “ideal” process.

To accomplish this, I lead a series of workshops with the design team to determine a few things:

1. What were example of successful projects we had worked on?
2. What were attributes of those successful projects?
3. Based on that, how would we define an ideal process at National Instruments?

In the first workshop, I asked the team to draw out an example of a project that went well, and a project that didn’t go well. We created these drawings in a rough, infographic style to help quickly illustrate the projects.

Examples of very quickly created infographics of projects. Some good projects, some bad.

From the infographics, we identified attributes in the projects that contributed to their quality.

Example of a brainwriting exercise where each team member drew their version of an ideal process.

From that, we identified more tactical attributes that contributed to the success (or not) of the project. We then grouped those together to define overarching themes (good ‘ole affinity mapping).

Now that we had a list of the good, the bad and the ugly of projects past, we began to define the future. We used a brainwriting exercise (more info on brainwriting↗) to allow everyone to generate their own ideas of the ideal process. We reviewed, we refined, we reviewed, we refined….and finally resolved at an iterative process you see below.

Armed with our ideal process, I returned to the collective summit to share our thoughts. Due to our diligence and efforts, design was becoming the core piece of the product development process. Our version of the process ended up being the baseline by which all teams built their pieces on top of. This was an unprecedented view on how our products should be defined, prioritized and built with design being a common thread through every step of product development.

Looking back over the previous 3 years of process evolution. We had quickly gone from an island of misfit toys designing like rogue cowboys just trying to keep up with engineering to an integral common denominator with a consistent and established process to make the users, the product and the company as successful as possible.