UI can make or break your product. Learn how to empower front-end developers with the right teams, processes and stacks.
Nov 06, 2017
D2iQ
D2iQ
7 min read
Florian Leibert, CEO of Mesosphere, recently chatted with Robin Whittleton, front-end developer at inUse, to discuss what it takes to build great user interfaces. Read along as Robin and Flo discuss how front-end development is evolving, the requirement for deep interaction between development and design teams, how microservices architectures enable front-end developers, and the importance of user research. Robin also offers some helpful advice for aspiring young front-end developers. You can follow Robin and Florian on Twitter for more insights on front-end development.
It's All in the Interface
This idea of ‘working for everyone' was one that really hit home in my previous position, working on the design system for
GOV.UK. For a site like that, the user has no option to pick a competitor if they can't use the things you've built. You're also building for an entire country's worth of people (60+ million of them) and many more around the world. At that point you become incredibly aware of the needs of people when building the interface to the services they need.
End-user personas make no sense there, the only way to hit your goals is to do live user testing with many different sets of users. Even on the smaller systems I'm currently working on it's important to test with real people rather than personas. Personas help the developers think about the users, but they can only use the system in the way you'd expect them to. Real people never do this, and it's their insights you need to properly make a usable system.
Front-End Developers, Infrastructure Stacks and Microservices Architectures
FL: When should front end developers have an opinion on the infrastructure stack?
RW: Obviously there are parts of the stack that have little effect for front-end developers, but they're surprisingly few and far between. For example, an important component of the interface is performance, the time taken for a user to achieve an action. Some of the pain relief can be faked without a round trip, but a particularly painful situation might require a caching layer that the backend developer or operators might not have considered necessary in terms of managing server load.
The rise of microservices has meant that front-end developers can own an entire rendering application and not have to interface with the data layer beyond REST calls. This has also reduced the chance that a choice of tech stack can intrude into front-end code: ASP Classic and WebForms, I'm looking at you.
FL: Do you have a strong preference on microservices vs. monolithic architectures? As a front-end developer, do you feel the pain points as strongly as some of the most vocal in the developer community?
RW: Microservices allow ownership of the full stack by front-end developers, with a defined contract for data and for us that's been really helpful. Obviously there's a lot more religious arguments going on behind the scenes, but I can't think of a situation as a front-end developer where I'd rather work on a monolith (unless I had my full-stack hat on and was owning the application top to bottom).
Where I do disagree with some of the original ideas around microservices is that they should be effectively black-boxed, with a few developers owning each service and never moving between. That's a useful theory, but in practice it breaks down, and rigidity never helps a development team. Typically, product development teams tend to have one or two front-end developers, and if you have rigid ownership then there's a high bus factor with the user interface. Besides, I want back-end developers to learn about what constitutes a good UI layer, and vice versa!
The Interplay Between Development and Design
FL: Do you see a strong intersection between development and design? Knowing the importance of user experience, at Mesosphere we also emphasize design and front-end development to the point where we acquired a design firm and now designers work side-by-side with developers. Who do you work closely with day-to-day, or who should you work closely with and don't?
RW: Absolutely, there is a strong intersection between development and design. Like with any design field, good interaction designers need to know the limitations of their chosen medium. Realistically, they should be able to prototype in basic code. That code doesn't need to be compatible with the multitude of browsers and assistive technologies out there, but there can't be a multi-day feedback loop if you're going to make effective designs. Design needs to iterate quickly based on user feedback.
Similarly, front-end developers need to be able to provide feedback to designers as their concerns arise. In the classic model, a designer fed a front-end developer who feeds the back-end developer. There's no feedback loop. But a front-end developer needs to be able to push back on decisions that will lead to a worsened user experience. For example, if a designer hands the front-end developer an Adobe Photoshop PSD that proves impossible to implement in (for example) an accessible way, then there needs to be a discussion and a revision that will amend the base designs.
So front-end developers need to have opinions on anything that will impact the design in a negative way (be it interaction design, content design, graphical design, etc), and also be able to provide feedback with their concerns. Without a feedback loop your product will be substantially worse for many, if not all, users.
The Effect of New Technologies Like AI and VR on Front-End
FL: How do you see front-end changing as the growth of AI and machine learning technologies take root? Do you see any interesting new use cases emerging?
RW: In the traditional sense of front-end web design, it's honestly having little impact. AI requires large datasets which can't live in the client layer, so all of the interesting stuff is on the server. That said, there are non-traditional forms of front-end emerging, for example speech interfaces. While there's little definition in terms of design and front-end development layers here (all the projects seem experimental enough at the moment to require generalists) it's a field that's worth watching. Even if the need for dedicated front-end developers there doesn't arise, the impact of changing user expectations will spill over into the web.
There's also the interesting growth in VR and mixed reality head-mounted displays. With WebVR the specifications are there to support a web front-end for these devices, and it's interesting to play with. Whether they'll take off in a meaningful way beyond ‘interesting tech demo' is another matter, but that doesn't stop it from being fun, and an important niche.
[caption id="attachment_10613" align="alignnone" width="800"]
The Changing Role of the Front-End Developer
FL: UI's have evolved a lot over the last decade. How has the role of a front-end developer changed over that time?
RW: I started my career in the early 2000s. At the time it was easily possible for one developer to basically learn all the specifications by heart. The difficult part was dealing with awful browser support. Since then, browsers, documentation and the standardisation process have gotten orders of magnitude better, but the amount of specifications has exploded and it's really not possible for anyone to know everything any more.
One thing that's still in the process of changing is the attitude towards front-end development. While it's certainly not the case any more in larger organisations, often small dev teams just have a backend developer ‘do the UI'. Modern tooling lets them get pretty far with this, but (through no fault of their own) without the depth of knowledge that a dedicated developer bring the answer is usually just to throw JavaScript (JS) at the problem until it goes away. A proper knowledge of HTML and CSS can lead to real performance and accessibility gains, and the use of progressive enhancement as a development methodology adds reliability into the mix. Hopefully the trend towards recognition of front-end as its own field will lead to better performance and maintainability in the long term.
In many respects though we've never had it so good. There's incredible tooling and better documentation than ever around, and we're now at a point that all the major browsers are evergreen in one capacity or another which means that new specifications propagate out into users' hands at a much faster pace than ever before.
Building a User-Centric Culture
FL: Time and time again, we see products that didn't invest in UX up front. How do you turn an engineering-centric culture into a user-centric culture?
RW: Design and engineering need to be permanently talking. It's not good enough to have separate design and engineering teams. There need to be product teams where every member is collaborating to build a product together. There also needs to be an understanding from the project leads that the product will be developed iteratively based on feedback from every staff member and from user research. All developers should regularly attend user research sessions. There's nothing that gets you motivated to improve your product as much as watching a user struggle with what you thought was a perfectly simple solution.
There's also no point in making changes if they can't quickly reach the users. As a product team you need to be shipping quickly and you need to be able to propagate changes out to everywhere in the system. This leads to the idea of design systems: easily composable components that are part of a consistent whole. If you find an accessibility improvement that can be made to a component then you can make it once and roll it out trivially. Better yet, if the design system is more global than just your product then it's possible to make that same fix across an organisation and benefit users of multiple independent products. This requires more effort to set up in the beginning but acts as a force multiplier helping many more users than your fix would suggest.
Getting Started in Front-End Development
FL: What advice do you have for those embarking on a career in front-end development?
RW: The most important thing to understand is that you're building the interface between the users and the logic. While new technologies are exciting and open up new possibilities, it's really important to question whether they're helping the interface. If your implementation of a new technology cuts off all people with visual impairments, or all people stuck with an older Android phone, question whether it's worth it. To be clear: the answer might be that it is. But it needs to be considered and weighed.
I'd also recommend culturing a network of people interested in front-end development, be that on Twitter, in various Slack channels or in real life at conferences and meetups. More than in back-end development or design, it's possible to be the only front-end developer on your team, and without people with whom to talk over issues you find in your job, it's very easy to get disillusioned over what you feel should be a simple problem.
Finally, have fun! While it might not be part of your day job there's a wealth of opportunity for creative coders on the web platform. Play around with Scalable Vector Graphics (SVG), Canvas, animations, and WebAudio. Try and build some visual art for fun, or just experiment and see what you can do. I'm sure you'll learn something new and interesting.
