The following pyramid diagram shows the elements of a UI software product, arranged in proportion to the business-value they provide.
- Business Logic
- Architecture / Best Practices
- Testing
- Portability
- Accessibility
- Analytics
- User Feedback
The business-logic represents the core of the product and can be seen as the encapsulation of business requirements into code. These business requirements represent the what and are different than the UX requirements which represent the how. UX and the Business converge to determine the who and the why. Traditionally, the who and why have been treated as optional nice-to-haves, remaining as affirmations to the Business and UX of the decisions they have made.
In this modern age of software development, forward-thinkers in the space such as Apple and Amazon have pioneered methods of integrating the concerns of the Business and of the User Experience more deeply into the practice of engineering the software product. No longer are UI engineers to simply code to spec but also have a responsibility to the end-user themself. Customer Obsession; Working Backwards; User Journeys; These are a few of the concepts characterizing the reformed workflow of the UI software product.
A software product can exist and be useful to people, even with no perceivable architecture (known as the "Big Ball of Mud" architecture). A good architecture can generally be derived from the knowledge of and adherence to "best-practices". Sometimes these best-practices can be specific to a particular technology, either programming language or perhaps even framework. Good practices, even "best" practices, must be actively sought and encouraged by the group.
There is a quality of momentum to best-practices which must be guarded. The fundamental qualities of good architecture are well-known and even more well-documented, yet knowledge of best-practices or useful design-patterns is not enough. It is important to adopt an air of impersonality when subjecting your work to the criticisms of your peers. Remember that their main concern is the customer, and refining your attention to detail is precisely the sort of process whereby the momentum of best-practices is preserved.
"In ordinary computational practice by hand or by desk machines, it is the custom to check every step of the computation and, when an error is found, to localize it by a backward process starting from the first point where the error is noted." - Norbert Wiener, Cybernetics
Beyond having a running program with an architecture which lends itself to easy maintenance, the most important thing you can add to software is testing. Most of the value provided by testing comes from automated tests. Tests can be broken up into several different types. The first classification of tests, popularized by Martin Fowler, can be depicted by his Test Pyramid.
A slightly different more modern view, espoused by the foremost representative of the JavaScript testing community Kent C. Dodds, can be depicted by his Test Trophy.
One thing to note here is that the "UI" in the Test Pyramid refers to "End to End" testing, and the "Service" level refers to "Integration" testing.
The Test Trophy is a bit revolutionary in that it brings the importance of Static checking into the same important realm of writing tests. Note that it is probably due to the importance of JavaScript in modern software that this layer was conceived of.
I would also like to propose a further elucidation of Unit tests with regards to the UI. UI functionality is unique in that it contains the multi-layered complexity of the API, but in a more localized space. This means that testing for each layer of a UI component can be the responsibility of the developer who created it and is possible to group within a centralized codebase.
A UI component, although utilizing 3 languages to build, also, perhaps necessarily, requires 3 layers of testing. It is useful to treat these three layers separately when speaking of Unit tests. Component testing, snapshot testing, and visual regression testing follow logically from JS, HTML, and CSS being the necessary compositional units of a UI element. These three languages can be generalized further to the domains which they deal with, respectively Behavior, Anatomy, and Appearance.
Note: Because a UI "component" can be a composite of smaller components, there is some overlap between unit and integration tests with regards to component testing. This is accounted for in the Testing Trophy depicted above.
Portability adds business-value to an app in that it widens the breadth of the relevance of your app, by eliminating cross-platform barriers to usage. Accessibility can be seen as a subset of Portability.
With regards to UI development, the two major considerations for portability are the device screen-size and the browser.
"I wish for a world that views disability, mental or physical, not as a hindrance but as unique attributes that can be seen as powerful assets if given the right opportunities." – Oliver Sacks, neurologist, naturalist, and author
"We need to make every single thing accessible to every single person with a disability." – Stevie Wonder
Accessibility is so important to think about, especially because it is so often forgotten about. As fully physically and mentally capable as engineers normally are, it can be difficult to remember to include software capabilities which render the software usable to those who are not as capable. Constantly thinking about accessibility while engaging in the practice of engineering is central to the act of customer-obsession and customer-driven business outcomes.
Accessibility refers to the usability of a software product by people of different abilities, both physical and cognitive.
Analytics can be seen as passive user feedback. It is essentially a subset of user feedback. It involves the gathering of application usage data, even unbeknownst to the user. This data is gathered in order to provide insight for further improvements to the app and other Business decisions.
User Feedback, while the uppermost portion of the UI Best-Practices / Business-Value Pyramid can certainly be argued to be the most critical piece since it improves further iterations of each layer of the application. It is the mirror of a software product.
Gathering user-feedback before developing features is the best-practice known to the industry in modern software development. In a sense, the top layer of the pyramid is the first which should be considered, giving way to the complete scope of the application.