Understanding the “design flow”

We were having a hallway conversation yesterday about how to represent information in a UI. The discussion quickly turned to the “design flow”. To provide a little context we were discussion how designers or engineers making use of signal processing algorithms work. Other terms that come to mind are use cases, information flow, user interaction design. For the design of any product, especially software like LabVIEW being able to successfully put yourselves in the shoes of the end user is worth a lot. It’s never easy since the LabVIEW user base is so varied, many industries, many types of applications, many backgrounds and cultures.

To give a simple example, in one recent conversation we were discussing applications that run on multiple targets. Let’s say a windows machine and a system with a real time controller and an FPGA. Do people work bottom up or top down? Do people start with all the VIs and code and then decide where to target things or do they start with where things need to run  and then put the code down appropriately? The conclusion we reached was  … both. There are lots of shades of gray in between as well. So as we develop any utilities or tools to make the development and management of these systems making sure both approaches are handled intuitively is key.

There was a recent tread on Info-LabVIEW that John mentioned in his post titled “What is LabVIEW? about who it’s intended for and the balance between simpler and more complex applications. When designing parts of LabVIEW and the user experience we rely on a lot of different things to try and get it “right”. These include:

  • Having multiple iterations to serve as evaluations points
  • Holding internal usability sessions
  • Previewing features with the LabVIEW Champions
  • Visiting customers in the definition phase with mock-ups as well as during development with prototypes
  • Identifying lead users to include through the process for directed feedback
  • Sharing ideas still in need of refinement on NI-Labs

Those are the first few things that come to my mind. When you consider the Beta period for a release it’s later on in development so major changes can be harder to make, but the feedback on usability as well as bugs is valuable in short and medium term. That’s why for newer areas we like to get in front of customers to understand how they work day to day when developing applications. This can provide feedback earlier during development when we have more opportunity to make course corrections.

In addition to the issues I mentioned earlier about the things we have to balance like different application types and industries, one issue that is really difficult to grapple is entirely new paradigms. What things are done a certain way today because of the legacy of existing products, technologies and methodologies? What of that legacy is necessary to make it an understandable experience for people and what should be superseded by “new ways of working”? Answering these questions can lead to some passionate discussions, but that’s what makes working on LabVIEW and seeing how it has evolved and continues to evolve so much fun.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s