UX Architecture / Design for B2B Startup

Business Challenge

Image of a Unix-style screen for configuring a video device

Early UNIX-style interface to configure video devices.

Typical video "head-end" NOC: racks of equipment with no manual interface.

Typical video "head-end" NOC: racks of equipment with no manual interface.

Typical rural telecom NOC: miles from nowhere and unstaffed.

VideoTele.com, an off-shoot of Tektronix, Inc., was a startup in 1999. Staffed by some of the smartest engineers on the planet, VT.c had built 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. In particular, VT.c didn't know who would manage these devices, or how they expected to manage them. VT.c's users were telecom technicians thoroughly unfamiliar with digital video technology.

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

Unfortunately, this prototype failed to take advantage of the windows environment and couldn't scale to the needs of the telecom technicians. Telecoms have to comply with "5 9s up time," meaning, all equipment in their NOC had to be working 99.999% of the time - an equivalent 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. 


Image from specification for V1.0 of GUI software showing all racks filled with chasses, some in alarm

Version 1 of management/configuration software - HP Openview SNMP-based.

Version 1 of management/configuration software - HP Openview SNMP-based.

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

Version 1of 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.

Image from V2.0 specification showing chassis / card views

Version 2 of the software, using full Windows-based GUI capabilities

Image from V2.0 specification showing multi-state fully loaded chassis

Version 2 of the software, using full Windows-based GUI capabilities

Photograph of smiling sales people at annual meeting, applauding the design/dev team's software

A standing ovation at the annual meeting.

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.


Image from Context Scenarios with comments

Excerpt from Context Scenario.

Image of table of colors used for a variety of elements within the software

Detail of alarm state color table.

Image from V2.0 software spec flow chart diagramming system behavior

Typical flow-chart explaining how interface states change.

Image from V1.0 specification showing redline/markeup of symbol types and alarms

V1 index into all symbol types and colors.

Image from V1.0 software specification showing symbol states for various alarm conditions

Diagrammatic explanation of various alarm states.

Image from V1.0 spec showing redline/markup for configuration dialog

Detailed redlined figure from specification.

Image from V2.0 specification showing multi-state fully loaded chassis

Card View. Figure from specification.

Image of specification detail, redlines indicating size and position of graphical elements

Detailed redline of specific card view element.

Image from V2.0 software spec showing chassis/card view with markup

Review of actual screens with indications for how elements differ from specification.

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.

Collaboration | Contributions

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.