Overview

Designing at scale for the enterprise is filled with compromises and opportunities but most of all, it is filled with details. Details about design, user journeys, APIs, toolkits, etc.

These details abound when you move from a simple webpage to an integrated application that incorporates data from multiple back-end systems while also writing back transactions to same said systems in order to drive the business forward.

Background

For instance, let’s examine the simple request to add timestamps to items on the page so our viewer will know how recent/relevant the data may be to their needs. At its core, this seems like a simple request for a timestamp; an alphanumeric sequence that usually applies to the date and time of the file being reviewed.

This simple request becomes immediately more complex when you begin to work with large scale enterprise applications due their integrated nature and how they read and write data from other systems. Some of those systems may be internal to the company while others are more than likely derived from other networks, partners, and businesses that supply services to the company.

Solution

That complexity increases when you start to breakdown what a timestamp actually looks like. At its simplest for, the timestamp might look like [HH:MM:SS] where HH, MM, and SS are hours, minutes, and seconds. However, that simplicity disappears when you begin to work across enterprises, timezones, and integrated systems that have been developed over time, possibly decades. 

If we examine the day of the week as a component of a timestamp, that seems like a simple thing to tackle. But, should it be stated DAY, fully spelling out each day – Sunday, Monday, Tuesday, Wednesday, Thursday, Friday, Saturday? Or, should it be something simpler and abbreviated like, Sun, Mon, Tue, Wed, Thu, Fri, Sat. Some of this is determined by the systems we might be integrating the data with, but at the outset of the design process we need to investigate these seemingly small details to ensure that our designs work with the data needed to support the business goals of the enterprise. 

For clarities sake, this is the full gamut of details on timestamps our team worked through as we developed our own standards for the Club Wyndham applications. 

Component – Julian, Format – year, month, day, Description – 
Component – seconds, Format – SS, Description – seconds (00 – 59)
Component – minute, Format – MI, Description – minutes per hour (00 – 59)
Component – hour, Format – MERIDIAN, Description – AM or PM  periods
Component – hour, Format – HH, Description – hour of the day (01 – 12)
Component – hour, Format – HH12, Description – operates the same way as HH above
Component – hour, Format – HH24, Description – 24 hour format (00 – 24)
Component – hours, minutes, seconds, Format – SSSSS, Description – seconds in 1-day (00000 – 86400)
Component – day, Format – DAY, Description – Day of the week (Sunday, Monday, Tuesday, Wednesday, Thursday, Friday, Saturday)
Component – day, Format – D, Description – Abbreviated day of the week (Sun, Mon, Tue, Wed, Thu, Fri, Sat)
Component – day, Format – DD, Description – Numeric day of the month (1 – 31)
Component – month, Format – MON, Description – Abbreviated name of the month (Jan, Feb, Mar, Apr, May, Jun, Jul, Aug, Sep, Oct, Nov, Dec)
Component – month, Format – MM, Description – months of the calendar (01 – 12)
Component – month, Format – MONTH, Description – Name of month (January, February, March, April, May, June, July, August, September, October, November, December)
Component – month+day, Format – DDD, Description – Numeric day of the year (1 – 365)
Component – year, Format – YY, Description – last 2-digits of the year
Component – year, Format – YYYY, Description – 4-digit year (0000-9999)
Component – week, Format – W, Description – week of the year (1 – 52)

Ultimately we settled on a few manners of display based upon the systems we used, the designs, and context for the user journey. These are the key expressions being used in the application today: 

Full display (DAY, MONTH DD, YYYY HH:MI:SS MERIDIAN) Friday, April 20, 2019 4:20:00 PM
Abbreviated display (D, MON DD, YYYY HH:MM MERIDIAN) Fri, Apr 20, 2019 4:20 PM
Condensed display (MON DD, YYYY) Apr 20, 2019
Numeric display (D MON/DD/YYYY) Fri 04/20/2019
Condensed full date (MON/DD/YYY) 04/20/2019
Condensed MM/DD (MON/DD) 04/20

Conclusion

I have said to my teams repeatedly, that in order to design at scale, you cannot merely solve the instance – you have to solve for the abstract. What I mean by that is that once you develop an acceptable solution that solves your immediate design problem, you must extrapolate that to work across multiple user journeys and behaviors.

The simple timestamp is a perfect example of the need to be able to scale a solution to work across multiple products, companies, teams, user journeys, etc. in order for it to be an effective enterprise design. It is akin to designing at micro and delivering at macro-scale. A successful enterprise designer knows this and grows their designs to meet the need of the enterprise.