What is a UI Architect?

A UI Architect is a role that we normally ascribe to people that have some sort of ‘authority’ within a front-end team. Typically, the phrase would denote someone with elevated privileges that will ‘tell/advise’ a team what to do and how to do it.

But can we describe the role in a way that might be more useful to the real output of a team?

Priorities

The first and foremost thing that almost all teams that I work with seem to get the wrong way around is their priorities.

For example; whenever I used to attend interviews myself, I would always find that the list of things teams generally wanted to focus on were the technology and frameworks such as React, Angular, Jasmine etc.

On rare occasions, I might see more abstract topics like the SOLID principles, DI (Dependency Inversion) or IOC (Inversion of Control) containers.

We can class these topics ‘software design’ as opposed to ‘software development’.

Software ‘design’ is about doing it well, software ‘development’ is about simply doing it.

I’ve been involved in the front-end for the latter part of my career. Topics like the SOLID principles and general software design concepts are not as common as they are in the back-end world.

For example; I did a talk at a conference a few years back when I asked a room of about 150 JavaScript engineers if they knew what IOC (Inversion of Control) was, I saw about 4 hands go up. I found this baffling because IOC is a really important topic if you want good architecture regardless of language.

Here’s the problem; even if you have a great architect that understands something like IOC, it’s little use unless the whole team understands it.

You end up with the architect sitting in their ‘ivory tower’ dictating the way things should be done. That’s why in the UI Architecture Academy we spend a lot of time on these abstract concepts – we know engineers should learn them.

Being a good UI architect is not just about the underlying theory, but also the process which can give you better commercial outcomes…

Delaying Decisions

A few years ago, me and my team at Logic Room developed an MVP (Minimum Viable Product) app for a recruitment consultancy in London so they could monitor candidates in a recruitment process.

Our client told me what they wanted; it included a login and registration system. The problem was that the login and registration system held no value to the app on its own.  So, I recommended that we ignore the login and registration and instead build the app to just store the progress of each client in the browser’s memory.

This meant that the entire app had to run in two modes. Authenticated and unauthenticated. We wanted to be able to run it in the latter (unauthenticated) right up to the launch and then simply turn on the authenticated without having to do too much refactoring.

So we did this by using a dynamic code technique which would allow either technique to work seamlessly. For this we used the technique DI (Dependency Inversion). It lets you separate code into discreet modules that follow an interface (which is simply a list of JavaScript functions, variables or the external boundary of a class). It says that instead of calling code directly, you should call this interface. The result was that the majority of our code could stay the same even when we turned authentication on.

So, by making DI a priority we were able to protect ourselves and our client from something that didn’t matter in the short term (authentication) to take advantage of something that did matter in the long (the actual behaviour of the app).

As ‘architects’ delaying decisions like this is important; not just because it helps us to mitigate against things that don’t add value; but because it forces us to make code that is more modular.

A Skill for Everyone

Instead of focussing on the endless sea of technology and frameworks. We should instead focus on learning rules that govern how we will eventually use the technology and/or frameworks.

Being a good UI architect is about making the code and the strategy of how to develop apps more efficient.

 The rules we need to learn to be a good architect do not need to wait until our employer gives us that job title. They should happen as part of being a competent engineer. It’s only when our entire team has rules for making decisions that we can say that the team will begin acting as one. When this happens, we won’t need ‘an’ architect, we will have ‘a team’ of architects!

Conclusion

As terms go the phrase ‘UI architect’ could mean anything. It could mean authority; it could mean experience, it could simply mean getting a higher salary.

But, being an architect is not really about any of these things. It’s about firstly defining priorities and secondly using software design theory to make better decisions – which aid better commercial outcomes. For this reason it's really something that all engineers should learn to be!

Author: Pete Heard

Pete is the founder of Logic Room. He designs the companies core material for JavaScript architecture, test automation and software team leadership.

LinkedIn