Recently, BlueMetal was selected as a finalist for a best UX – product award at MITX, an esteemed network of technology marketers. This was for a large scale data visualization wallboard produced for the energy monitoring company EnerNOC.

What’s really impressive about this experience is we went from this:

Screen Shot 2014-04-30 at 11.26.28 AM

to this:

after1

in under 8 weeks.  Most of our clients and colleagues are astounded by this result and have many questions:

  • Which process did we use: Agile or Waterfall?
  • How many iterations?
  • When did the data architect come on board?

The answer is very simple – we put the team (a UX lead, a data architect, a UI engineer, an animator and a visual designer) all in one room, on site where the wallboard was being installed.

We used parallel streams of work to ensure design was aligned with architecture and that communication between the team was constant and consistent. Due to proximity with the client, the team was able to rapidly problem-solve on the fly. This became crucial as visual design and data got closer together.

There was a classic waterfall process but compressed: Discover, Define and Design, or as we call it: BlueSky, BluePrint and BlueMetal.

During BlueSky, interviews allowed the designer to sketch out the experience quickly, and the developers were part of that brainstorming. This allowed both the UI engineer and data architect to understand the scope of requirements, course-correcting as the design became more established.

With BluePrint we whiteboarded every piece of data that needed to be displayed on the wallboard in a single brainstorming session. Both the client and project team were part of this and a firm agreement was put in place that the brainstorming could not be considered complete until we were all in agreement on every piece of functionality. Drawing this line in the sand created intense focus and a rapid approach to design.

Finally during the BlueMetal stage (Design and Build) we ran separate streams of visual design, UI framework and data architecture, working side by side to not only converge on a rapid prototype but to iteratively create a solid high quality final deliverable.

The key to success on intense projects like this involves rapidly solving problems together, and a lot has to do with location.  By ensuring everyone was sitting side by side, every team member got equal accountability on the success or failure of the project, driving the team forward to ensure a favorable result.

An example is shown below of how location affects team dynamics.

workingtogether 

Though both team members are looking at the same screen, they are looking for different things. The visual designer on the left is looking at the readability of the typeface, the colors presented and the meaningfulness of what’s being shown. At the same time, the data architect is looking to see how the live data is feeding into interface and can not only troubleshoot, but work with the designer if the type size doesn’t work with the amount of characters the data is expected to pull in. Similarly, on the live file that both developers and designers worked on in WPF (Windows Presentation Format), designers used styleguide marking to indicate to the UI engineer how to adhere to the style, but also allowed the engineer to communicate in the same design language if certain parameters were not working.

usingstyleguides

Another simple example is the need for world clocks (shown below), something we observed was needed in the 24/7 work environment of EnerNOC. By having a cohesive team, the creation, placement, styling and implementation of the clocks was something we could easily do within a very short time span.

worldclocks

This type of constant communication, rapid problem solving and parallel streams of work can only happen when your team is in the same room, and you should always decide on WHERE your team delivers before you decide on HOW.

theteam