UX Architecture / Design for B2B Startup

VideoTele.com, an off-shoot of Tektronix, Inc., was a startup in 1999, building an "edge video-grooming device," a widget that converted broadcast TV into 6Mbps digital video streams, real-time. Nothing like it existed on the planet, and VT.c was positioned to be in every telephone Network Operations Center (NOC) for telecoms racing to enter the digital TV market.

But bleeding edge technology was just one part of the company's overall challenges: VT.c's users were telecom technicians unfamiliar with digital video technology.

My starting point was a UNIX XWindows prototype created by engineering from their internal "green-screen" menus. 

The prototype wasn't native to its windows environment, and it couldn't scale. Specifically, telecoms must have "5 9s up-time," meaning, all equipment must work 99.999% of the time -  a maximum of 5 minutes downtime per year.

The sales team was frustrated: customers were complaining they couldn't use the equipment in their environment and maintain regulatory compliance. 

5 9s up-time meant the hardware had to be fault-tolerant, but equally important was the software: technicians had to monitor and take immediate action to resolve any alarm—within moments. 

Version 1 of the software used common SNMP protocols, integrating with standard network monitoring systems such as HP Openview. In contrast to the original prototype, this version took advantage of many Windows GUI capabilities, including visual display of components, operating states and hierarchical menus.

With over 500 channels to manage, the technician needed to quickly determine which card, in which chassis, in which rack might need to be serviced or managed. Version 1 proved to be too cumbersome for these tasks and couldn't scale.

Version 2 used hierarchical information visualization to provide the technician with immediate access to critical information along with a direct way of accessing the equipment through standard Windows interactions (click, double-click, hover, etc.).

In addition, the final design provided drag-and-drop capabilities to configure the chasses (with cards) and configure the racks (with chasses).

The bottom line: with the introduction of Version 2, the sales team gave us a standing ovation. It was clear to them that we had (finally) crafted something they could easily demonstrate and sell.

When I arrived at Videotele.com, I dove in by interviewing the marketing and engineering teams who had created the initial engineering version of the software. In addition to learning how complicated the devices were, I also came to understand that no one had done any user research up until that point.

My first step was to begin a very light-weight contextual inquiry process. I set up interviews with prospects and customers to learn about their jobs, their context and the sorts of things they cared deeply about. From that information, I crafted my first Persona, an artifact and concept I hadn't heard about before (this was 1999 after all).

Subsequently, I created context scenarios (or science-fiction stories, as I called them) to garner feedback from marketing and engineering about the future software experience I was proposing to design.

Armed with the scenarios, I began creating code-based prototypes (using Delphi, Borland's object oriented Pascal and incredibly amazing IDE) that I used for several purposes:

• To help me visualize and refine my interaction and visual designs
• To communicate with engineering the very detailed and involved state changes, significantly reducing documentation
• To test with users in those cases where none of us were really certain of the right thing to do (and when production code wasn't close to ready)
• To use as the screen captures for the specifications I wrote.

Because the actual system was being built in C, C++, VB and ultimately .NET, we all agreed my work would not ever become production code. 

I proceeded to create a UI specification that captured current, next and future release features. The specification became the basis for help documentation and QA test plans, both of which I assisted in creating.

As the first UX hire by VT.c, I was a "team of one" for a couple of years. If that wasn't isolating enough, the UX role wasn't well understood by the hardware engineers working deep inside the machine at the algorithm layer, nor by the middle-ware engineers trying to create a high-performance vehicle. 

Still, as my research began to answer questions with definitive data, the organization came to appreciate the true value of UX: as a strategic contributor to product definition, design and delivery.

I was responsible for all research, definition and design work, from visual to interactive. I wrote the specifications, provided interpretation of the specs to the engineering teams, assisted in the creation of the help system and documentation, and worked side-by-side with the QA lead, fashioning accurate test plans.

In addition, I worked closely with Product Management, helping respond to RFPs, negotiating requirements and their definition, and helping craft marketing collateral.

My role was within the Advanced Technology Group. An additional responsibility was to attend standards conferences (the MP4 standard was just being crafted at the time) to ensure VT.c's algorithms would be compliant with the final standard.