I met Mark Hewitt and Julian Flaks, the CRO and CTO respectively, of EQengineered at a Society for Information Management (SIM) meeting. They were the event speakers that evening. They were eloquently explaining what UX frameworks are and how they can be used to simultaneously enhance IT software development productivity, enrich user experience, and increase overall user satisfaction. Being impressed with their knowledge and the topic of UX frameworks, I asked them if I could interview them for this post, so I could share their insights with you also. They generously agreed!
I began by asking them for their definition of UX frameworks. They explained that UX frameworks go beyond simple user-interface code libraries and provide a structured development platform to develop front-end software. They do this by:
- Providing methods and constructs designed to maximize programmer and design flexibility
- Facilitating a common user interface across multiple software products
- Enhancing programmer productivity by not re-creating the wheel on each development product
- Enhancing ongoing software maintenance through the use of a common coding library and user-interface programming standards
Given these great advantages, I asked Mark and Julian for their advice on implementing a UX framework within an IT organization. They suggested the following:
Understand what you are building
The first key to proper user design is to understand the purpose and nature of the interface you are building. They suggested asking yourself the following questions:
- What is the interface’s business purpose?
- Who are the intended users and what are their demographics and computer literacy?
- What is the level of required complexity, in regard to needed business rules and dynamic screen changes based on data and user actions?
- How much data must be entered, manipulated and/or displayed?
You must understand the interfaces and interactions between the front-end software being developed and the back-end processing being performed. From a standardization prospective, ideally, all business logic should be contained in the back-end. UX considerations may dictate they need to leak into the front end, but this is an example of deliberately compromising the clean architecture. As such it requires discipline and great care.
Reduce front-end data flow
The amount of data passed to and from the user front-end should be minimized, particularly if the application is intended for use on mobile devices. This is a time when the key to a frictionless front-end experience is diligence in the data and back end RESTful layer.
UX must be the highest priority
Certainly, your back-end systems must be secure, but your system will be judged by the look and feel of its front-end.
Selected UX framework must be a good fit
The UX framework you select for your organization must successfully co-exist with your back-end systems, internally used technologies and the types of the applications you’re trying to build. You must assure that the selected framework works with you, not against you, when building and maintaining applications.
Enforce your architectural principles
Whichever UX framework you select, make sure that it is used in a standard and consistent way. This enforcement enhances maintainability, interoperability, programmer redeployment and a consistent look and feel across your applications.
Understand your framework’s strengths and weaknesses
Every framework has its own strengths, weaknesses and idiosyncrasies. These are very important to know during the selection process, when creating your internal standards and best practices and when deciding which of your internal development projects should and should not use the framework.
Update your architectural documents
The overall architectural blueprint of your UX framework and its interfaces and programming standards must be a living document to stay relevant.
As a last question, I asked Mark and Julian if they had a closing thought that they would like to share. They said that to think of user experience in general, look at it holistically. In other words, beyond the technology. You must also consider the skill sets of your developers, current and future project types, and the full software lifecycle, including development, maintenance and eventual replacement.
This article is published as part of the IDG Contributor Network. Want to Join?