Designing a unified admin website for field service engineers 

DESIGN BRIEF: Our customer asked our team to consolidate half-a-dozen back-end UIs for administering the CPOF system into a unified website for system administrators and field engineers.

USER CHARACTERISTICS: Field service engineers (FSEs) are sys-admins who handle back-end administration of all Army Battle Command Systems. They set up battle systems on Army-administered networks, manage user accounts, handle data integration issues across different systems and schemas, handle patches and upgrades, and monitor and troubleshoot system health and performance. Often they are the only experts available to train front-end users how to operate their systems. They span a wide range of professional expertise, from computer scientists trained to investigate issues at depth, to technicians who can apply detailed sequences of known troubleshooting steps but might have no idea how to begin investigating less common problems.

UI & UX CHARACTERISTICS: During almost a decade of deployment, the interfaces for administering this system emerged in an ad-hoc way. Different teams of internal developers and sub-contractors designed different interfaces with minimal coordination among them. The resulting set of back-end interfaces looked something like this....

The only "unified" point-of-entry into this system was its documentation, which had been written by different contractors and was delivered and stored in separate systems (so it wasn't easily searchable).  

AdminDocs_bcj.png

DESIGN CHALLENGES:  Our biggest challenge on this project was to truly integrate and re-design these systems, instead of simply creating a web framework and re-implementing each of the existing interfaces in a separate section of that framework.

Our customer had challenged us to design the system so that it could be administered by any smart person who could read a manual and had a basic aptitude for troubleshooting.  The presence on our team of so many expert users of the existing administration system -- many of whom were developers (and therefore have a much more informed and nuanced troubleshooting approach than the "average" person) -- meant we were at risk of designing a system more for ourselves than for our intended users.

DESIGN GOALS: 

  1. Integrate and re-design to meet high-priority user needs.
  2. Design for a future-user, not ourselves.
  3. Develop a modern, striking, simple-to-use front-end. 

DESIGN PROCESS:

We brought members of our development team from all over the country together for a three-day HCD exercise to clarify the approach we wanted to take, talk about the "future user" we were going for, and brainstorm design solutions.  

We brought members of our development team from all over the country together for a three-day HCD exercise to clarify the approach we wanted to take, talk about the "future user" we were going for, and brainstorm design solutions.  

We had members of the development team collaborate to rank numered domain stories according to their impact on end-users and the frequency with which an administrator needed to perform them.  The upper-right quadrant was our sweet-spot for design. 

We had members of the development team collaborate to rank numered domain stories according to their impact on end-users and the frequency with which an administrator needed to perform them.  The upper-right quadrant was our sweet-spot for design. 

We brought in active field service engineers who were not members of our development team to repeat some of the HCD exercises we'd done with developers, and to verify and validate workflows, personas and other design artifacts.  

We brought in active field service engineers who were not members of our development team to repeat some of the HCD exercises we'd done with developers, and to verify and validate workflows, personas and other design artifacts.  

Designers worked together in a common room, iterating on our front-end dashboard design and framework. 

Designers worked together in a common room, iterating on our front-end dashboard design and framework. 

With the framework in place, we divided up the modules in the system and delved into detailed design specifications. This interaction document, done in Balsalmiq, shows three different options we considered, and initial interaction details for the one we accepted. 

With the framework in place, we divided up the modules in the system and delved into detailed design specifications. This interaction document, done in Balsalmiq, shows three different options we considered, and initial interaction details for the one we accepted. 

A final mockup of the front-end system, which we called The DASH.  

A final mockup of the front-end system, which we called The DASH.  

Developers using the DASH front-end during an internal collaboration exercise.  The design team coordinated several collabexes to let developers test out the system in an operational scenario before fielding.  

Developers using the DASH front-end during an internal collaboration exercise.  The design team coordinated several collabexes to let developers test out the system in an operational scenario before fielding.