angular and ux style guidelines
all enterprise software products

TABLE OF CONTENTS

case study

OVERVIEW

brief

process

DELIVERABLES

links

 

OVERVIEW

Client

-  KinderCare Education
-  Children's Creative Learning Centers
-  Champions
-  The Partners Group 

Location

-  Portland, OR

Industry

-  Child-care education and services
-  Financial / accounting
-  Tuition subsidy

company profile

-  $1.6B company
-  World's largest early childhood education company

TECHNOLOGIES

-  Enterprise software
-  ERP software (enterprise resource planning) 
-  Financial and accounting software

Product(s)

-  Tuition subsidy financial software  

Project / feature / deliverable

-  Tuition Subsidy v1.0 (MVP)

duration / date

-  15 month release / 2015-2016

NOTE: If you are diving deep into my background, I highly recommend reading my KinderCare Education product and UX design case study first to better understand the larger context for the case study below.

BACKGROUND

This case study highlights the collaborative work I undertook with a front-end engineer to create living UX style guidelines, then develop a front-end architecture capable of supporting implementation of new software using the framework. Unlike my other KinderCare Education case studies, this work was not intended for just the tuition subsidy software product I led, but rather was meant to be a modern, future-facing standard for all new software across the enterprise. 

problem

First problem: we needed a modern, front-end framework and UX style guidelines that could be used to replace or upgrade six legacy enterprise applications, most of which were created in the 1980s and 1990s. I began thinking about this problem even when I interviewed for the role. In my initial discussions, I heard a lot of buzzwords: UX, modern application development, fresh design. But it seemed as if stakeholders believed "UX" was something that magically resolved itself in the process of "designing" or was akin to slapping a new coat of paint on a worn-out interface. I knew the company needed something more fundamental, both in terms of guidelines and architecture. I also understood I would not have time to spend months on enterprise buy-in or development of a custom standard. Furthermore, no one internally at the company was capable of maintaining or updating a new UX standard.

Second problem: the company was using an ASP .NET and SOAP-based legacy framework with .NET client. We needed a new architecture to support our modern UX design guidelines, responsive design, backwards-compatibility with recent versions of all major browsers, and improved general application performance. We already knew we wanted to use Angular, which created an enormous problem, since Angular will not work with SOAP directly. But SOAP was already on the chopping block. Its higher bandwidth degrades application performance due to XML-based messaging over JSON, and it also has interoperability issues with mobile clients. Using Angular was the right decision, but required huge overhead to refactor and support a new REST service tier. 

solution

The answer to the style guidelines was fairly simple (at least as an afterthought): Material Design. I let Google do the hard work for us. I was familiar with the design standard from my time working at Symantec in Silicon Valley. There I had participated in a project to create new, modern UX guidelines, and we had studied and benchmarked the most popular industry design standards: Apple Human Design, Windows Metro, and Google Material Design. So I had a foundation with Material Design, but began this project with a deeper dive into its interactive design language.

At the same time, I began deconstructing the existing legacy systems, to determine where Material Design was or was not a good fit. I like this standard quite a bit and give it high praise, because I was almost always able to find solutions to design problems. Only on rare occasions did I deviate with minor customization, which was great, because it largely translated into Google, and not the KinderCare Education enterprise, maintaining the guidelines. 

But a design standard can only be as good as your ability to translate it into working software products. So I began bridging the UX standards with the front-end architecture. I worked with a full-stack, architectural lead, one with a particular passion for UX and the front-end, to implement the best possible client platform:

New full-stack architecture

• Angular 1.x
• Bootstrap 3.x
• Material Design for Bootstrap
• HTML5
• CSS3
• REST with token-based authentication
• Microsoft WebAPI
• .NET
• Oracle
   

Challenges

Bootstrap is an excellent front-end framework, but does not faithfully match the Material Design standard. So we had to add Material Design for Bootstrap to the stack, which is a layer of CSS that overwrites core Bootstrap and provides the visual aesthetic of Material Design.  

Because SOAP would not work with Angular, we decided to adopt Angular infrastructure for the client implementation with REST. Replacing SOAP with a RESTful tier was an enormous amount of work. 

The company did not have a true architectural engineer on staff. We had to deconstruct the existing systems piece by piece to achieve any reasonable frame of reference for our new work. 

We were creating the UX guidelines and the front-end architecture at the same time I was designing the new software product and the engineers were beginning core development. It was difficult for everyone to pull double duty, and the lack of linearity, having a framework first and following it with development work, often set our work at odds.  

The enterprise's lack of experience with modern software development lifecycle, Agile, or UX was a thematic issue that touched most work, not just this facet of the project. There were often pervasive misunderstandings about the extensive scope of work and time required for developing a new design standard and framework. Similarly, we needed to remember the enterprise's limited ability to maintain or develop the framework or UX standard in the future. We were always working within the constraint of low future overhead for the enterprise. 

Outcome

Because the Material Design standard is maintained by Google, and we did little customization with it, the company will not have to worry about the resources and work associated with supporting custom UX guidelines in the future. Better yet, given the popularity of Material Design, the company will always be able to find UX practitioners in the local market who are conversant with the standard. Furthermore, given its popularity, both with Google's core products and as an open-source design standard, Material Design should have a very long life and remain relevant for many years to come. 

On the development side, the new front-end architecture is a stable, modern implementation that should also serve the company for years. The move to a RESTful tier combined with other changes, such as Angular handling more processing on the front-end, bolstered application performance. Additionally, given the popularity of Angular and its use of an MVC architecture that turns JavaScript into a standardized framework, the company should find it easier to maintain the architecture internally, or find talent in the local market to support it. 

From a user perspective, these collective changes were readily apparent and well received even in early demos. Users were shocked by the gains in application speed and efficiency brought about by this work. 

UX Living Style Guidelines

The UX living style guide helped set the direction with engineering work, as it provided guideposts for system performance and requirements. Choosing to use a customized version of Google Material Design eliminated many months of upfront work and later maintenance with a custom design standard. 

bridging design and framework

Some considerations in selecting the best front-end architecture were independent of Material Design and purely technical in nature. But overall the relationship between the UX guidelines and architecture was inextricable, requiring great forethought and planning. How would we support Google Material Design when core Bootsrap was not very Material-Design-esque? Would our technical choices support responsiveness and backwards-compatibility with major browsers? I worked closely with the architectural engineer to bridge these gaps. 

FULL-STACK ARCHITECTURAL ENGINEERING

On a purely engineering level, decisions and obstacles were abundant. While this case study focuses on the front-end and UX standards, the total engineering effort might more accurately be described as a complete refactoring of full-stack, enterprise architecture. Things like the SOAP service tier presented technical problems independent of Angular or Material Design. But there were major issues that extended throughout the back-end and data tier. For example, all the company's legacy applications were using different databases technologies, and replicating information between databases at regular intervals. There was a data migration component that was so gargantuan in itself that it practically dwarfed other projects within the larger program. Considerations on design and the front-end extended to all layers of architecture. 

design-DEVELOPMENT fusion

In the end we were able to marry the new design standards with a modern front-end architecture that met all our requirements. Because it was built on common technologies and standards, and unified what had been a piecemeal array of technologies and infrastructure, it eliminated many risks and issues for the company. This simplification of infrastructure should reduce the costs and resources associated with maintaining it after consultants have departed. But the use of popular standards like Material Design and technologies like Angular ensure that KinderCare Education will always be able to find local engineering and design talent to continue supporting the new software.