The evolution of UX Design in a new Javascript framework world
In the last years UX evolved rapidly through the vast adoption of Agile and even more after the beginning of the Startup era. Turning an idea into a product or a business is encoded in our DNA and startups have always existed, but since the concept moved from the US towards Europe and the rest of the world, the UX field attracted a lot of attention.
Lean startup thinking took over the world but I sense that too many designers disregard how to run projects in international environments. A lot of in-house UX Designers have difficulties working with external design agencies or development companies, with external vendors for different services that your company needs to integrate in the application.
Your team members will be in different time zones, speak different languages, and be part of different cultures therefore proper communication will be a huge challenge. The designer, engineer, and product manager might not be able to sit down together and quickly iterate through designs.
I currently work for one of those companies that have offices across four countries and almost 1000 employees from every corner of the world. This is great as you never stop learning about other cultures but when it comes to getting stuff done quickly sometimes you feel like you’re hearding cats.
We have departments dedicated to different services that we offer. We also have external vendors that offer solutions that might be too costly to develop in-house. We have business teams in one country, development in another and QA and customer support in another far away place. Usually UX has to be close to business so that they can take their requirements and build solutions based on data and research therefore I am part of the business team, trying to solve their problems.
But how can a product designer communicate with all parties involved in the process and propose innovative design solutions that are sustainable and flexible, in an Agile context spread out across multiple countries?
For starters, the designer also needs to understand what developers expect from him to make development smoother and quicker. Many times they are not satisfied with complex user journeys and nice task flows. Therefore the designer needs to understand the technology being used and what can and cannot be done (as always there will be technical restrictions that will affect the user experience).
Based on the tech information that the designer gets, he creates a project-specific visual language, a language that can be easily implemented by the developers either in a proof of concept or in the project itself. Needless to say that the guidelines should be based on the principles of good design.
Sounds pretty simple but why should we focus on how developers actually build the product itself?
Well, first of all UX has been totally decoupled from development and pushed more in the direction of business analysis. The designer’s focus is split between the customer and on what the business expects. He needs to meet both expectations but if he doesn’t release the product, or he releases it after the market expectations have changed, the product will be a failure.
If we look at what the UX process looks like today we will see that it consists of several phases that cascade one into another and the latter are dependant on the former.
The “classic” UX Process
First we have strategy. Strategy will shape the goals of the project, what the organisation is hoping to achieve with the project, how its success should be measured, and what priority it should have in the grand scheme of things;
Then comes research, including user and competitor research activities, interviews, surveys etc.
The analysis phase will draw insights from the data collected during the Research phase.
The design phase will start after the analysis, and because it is collaborative and iterative, the design will be built on the user feedback loop established in previous iterations. The scope of the Design phase is to put ideas in front of users, get their feedback, refine them, and repeat until you reach the desired result. I’ve been talking a lot about the importance of testing and refining, as I consider evolutionary prototyping crucial to the whole UX process.
The production phase starts when the high-fidelity design is created, then the high-fidelity version of the product is validated with the stakeholders and the end-users through user testing sessions.
And only in and after the production phase the UX Designer will shift from creating and validating ideas with stakeholders and users to collaborating with developers. He will need to guide the product vision until the release.
A lot of strategy, research, analysis, wireframing and prototyping goes into designing the perfect user experience before actually starting development as we can see.
So the “classic” UX Design process cannot be Agile as it relies on several phases that cascade one into another and the latter are dependant on the former.
The classic UX process that most large companies follow is Waterfall. Why am I saying Waterfall?
Because in Waterfall this is done upfront, during a design phase that occurs before coding begins, and captures the design in clear specifications and user interface prototypes that have gone through usability testing.
In comparison to this,
In an Agile process, low fidelity design tasks replace the traditional design phase, design begins before all the requirements are known, development begins before the design work is finished, and the deliverables capture only small components and pieces of functionality.
Therefore being Agile requires a different UX approach, a component-oriented approach.
Brad Frost’s Atomic Design laid a good foundation back in 2013. Atomic Design specifies that interfaces are made up of smaller components. “We can break entire interfaces down into fundamental building blocks and work up from there.”
He was saying that “we are still designing full pages” and that is still true nowadays for many companies. They are designing pages, then create a style guide based on the elements on those pages and they use that for future improvements and new components.
Through my experience working on large enterprise applications I consider we should be doing the opposite, start from a set of design guidelines that will help us build components.
But it’s not just about creating and seeing how these components look. And it’s not just about the interactions between them. By building components that are independent from one another but still talk to each other and provide services to one another, we can reuse them, modify them and disable them if a service is down for a while.
And this is what user experience should focus on today.
We need to build components that are independent from one another and still provide services to one another. We need to be able to reuse them, modify them and disable them if a service is down for a while.
This is the reality now, UX Designers must be focused on creating visual languages that will allow them to easily create components for each service that the application needs to provide.
A designer can create the design components as the deliverables which will provide the service implementation and oversee how these components are built and implemented by the developers in order to be reusable and flexible to technology changes.
In order to better understand this we need to look what Google and Facebook are doing with Angular and React. They facilitate the creation of interactive, dynamic and reusable UI components.
This component-based approach can be guided by a component-oriented UX design that will define components designed to perform one or more activities.
As a result, each component is built as a discrete piece of code making it possible to reuse in different ways throughout the application. By changing only the way that an individual component interoperates with other components, designers and developers will save a lot of refactoring work when adding the component to another section.
Therefore variants of the design would be adapted on the fly and pushed out much easier. This will save us a lot of time as we won’t need to refactor components to fit different views.
All this talk about component-oriented UX, but what are the practical advantages that it can bring to the table?
First of all, the components can operate with no dependence on one another, therefore they will be autonomous and designers will be able to iterate rapidly, responding promptly to user feedback.
If rapid iterations are not enough, the second advantage is that the components respect the reusability principle. Each component has the potential to be reused across the application. These reusable components are designed in a manner so that they are independent of any particular technology. Therefore designers will spend less time refactoring a component in order to fit in different views.
The third and most important one is that the components are built in a structured manner so that they can be constantly improved. The need for perfection will come secondary, therefore development will run smoother and products will be released sooner.
The Conclusion:
Component-oriented UX is an evolution that comes natural with the dominance of the javascript framework use trend.
These frameworks facilitate the creation of UI components and if we take Angular for example, it is integrated with a lot of other tools and frameworks, making it the de-facto choice for most developers. Therefore the design process needs to adapt and find a similar path forward so that development can run smoother.
Component-oriented UX is new and the learning curve may be slow as it requires a deep understanding of both UX design principles as well as software development processes and patterns.
Still I am a firm believer that the future of UX lies in this approach and more and more companies will start thinking forward to a connected user experience across tools and integrated services.
Radu Fotolescu is an UX Designer based in London, currently working in FinTech. Founder of UX Design Today — UX Courses & Axure Libraries.
