What it means to be a tech director at Ueno Written by Edward Hewitt in Engineering on June 06,2019 In the first video from our series with Birkir Gudjonsson, he and Sadek discuss what his role as Tech Director at Ueno New York actually entails and how Ueno structures and plans its work. This transcript provides incredible insight into the approach of an incredibly respected digital agency, including how they see their dev team as an extension of their design team and what their favorite tech stack is (we're pleased to say that Prismic is featured). Read all of the details, watch the full vidoe, and subscribe to our channel to see all of our interviews and tutorials - including the rest of the series with Birkir. Highlights: Birkir shares with Sadek the "secrets" of Ueno, how they collaborate on projects, and which tools they use: At Ueno, developers work very closely with designers. They take the unique view of seeing their devs as an extension of their design team and their dev team even works to compliment their designers by helping out with animations and designs when needed. The most important thing designers create is a style guide for the different components/buttons - this will become the elements page of a project As a technical director, Birkir manages the technical part of the project, incluidng advising clients on technical (framework and tools) choices Ueno's favorite tech stack: CSS Modules, Gatsby (because of React, GraphQL, speed, plugins) and Prismic (because of Slices that correspond to React components) Sadek: So I'm here at Prismic Studio today. I'm with Birkir from Ueno, and I'm really glad to have you here, Birkir. I really like Ueno. Can you, maybe, first, tell us a bit about yourself and what you do? Birkir: Thank you. Yeah, I'm very glad to be here. My name is Birkir Gudjonsson. I'm a technical director at Ueno. Yeah, my role is-- I do a lot of things, everything from receiving a client and finding out his requirements and expectations and all the way up to delivering a good product. Sadek: And can you give us a bit of a maybe an introduction of what Ueno is? Birkir: So Ueno is a full-service digital agency. We have three locations, in Reykjavik, Iceland, New York, and San Francisco. We do everything digital. Sadek: And I guess you're very well-known for very big project that you did that, you know, your very famous project that you did for different companies, and I like your huge attention to details and creativity. I guess they say "You're taking the thing to a different level". Birkir: Next level, yeah. Sadek: Yeah, the next level. Yeah, we work very closely with our designers, and we like to see ourselves as-- the developers, we like to see ourselves as an extension to the design team. Birkir: Yeah you could say that. Yeah, we work very closely with our designers, and we like to see ourselves as-- the developers, we like to see ourselves as an extension to the design team. Sadek: And that's something-- yeah, that's interesting. So basically, you work very closely with designers. It's not like designers do something, and then they hand you the work, and then you have to implement it, and then you insult them back, like "Oh, this doesn't work, why did you do it in Photoshop". You don't do that. Birkir: Yeah, yeah, yeah. Ah, pixel perfect something. Yeah, no, no, we take the design and we make it better. We do animations, and if we don't have a motion study for a specific thing, if we have the time, we do it better and make it like an experience. Sadek: And how do your designers do their work? What do they deliver? Birkir: What do they deliver? It depends on the project, but most of them use Sketch, and they deliver a SKETCH file or even an inVision prototype where you can click through, but in the end we always look at the style guide and do it from a modular and component-based. Sadek: Oh, modular. So designers already do modular way? Birkir: Yes, that's kind of the way to go. Sadek: Okay, so they think of a page as modules, different pieces. Birkir: Yeah, absolutely. Sadek: And do they do this work together with developers? How do they modularize their page? Or they have experience to do it? Birkir: They're getting pretty good at it right now-- Sadek: Oh. Birkir: --to think about it. Yeah, it's a very good transition. But we work pretty-- it depends on the project, but sometimes we have to work very close with them to figure out the schema of the documents and so on. Sadek: So they are pretty technical in that case? Birkir: They can be pretty technical, yeah. Some designers-- my friend Kwok, he even coded his complete website in TypeScript. Sadek: Oh. Birkir: I was very proud of him. The biggest key into making a website is, of course, picking the CMS. That's kind of key. That's usually the first question that we need to solve. Sadek: Okay, now what about your role? Birkir: So yeah, my role-- As a technical director, it's not about directing only. It's about talking with the client, finding out his needs, what kind of systems does he currently use? What kind of systems does he need? Can we get rid of something? Can we find something new? Yeah, it's all about finding those requirements, and then begin the work. Yeah, um-- Sadek: And what about like, um, do you-- Like, for instance you have a client, you understand their needs, and then do you-- Is part of your job to recommend what technologies they should be using? Birkir: Definitely. Definitely. The biggest key into making a website is, of course, picking the CMS. That's kind of key. That's usually the first question that we need to solve. Headless CMS, you can always change it. You're not stick to a specific service to manage your website. If you select WordPress, you're kind of stuck with WordPress. Sadek: Before even programming language or technology? Birkir: Yeah, it's usually how it goes. Sadek: Okay. Birkir: And we always stick to recommending Headless CMS, our sales pitch is usually like, "Headless CMS, you can always change it. You're not stick to a specific service to manage your website. If you select WordPress, you're kind of stuck with WordPress." Sadek: Right. Birkir: But if you go with Headless CMS, you can go Angular, React, doesn't matter. You can, yeah. So again, components are modular. Sadek: Right, right, and that's why you start with a CMS, so that you have that freedom, and then you choose the frame-up that you want to. Birkir: Exactly. Sadek: I want to touch more about that, your criteria of choosing a CMS, but maybe in a different video, and then we go into talking, maybe, about choosing the technology, the framework, the programming language. Birkir: Yeah. Sadek: What do you currently choose as a programming language? Birkir: So currently, we like to call ourselves, a React shop. So we write everything in JavaScript. Actually, we write everything in TypeScript nowadays for additional type safety. Yeah, we use mostly GraphQL for transportation layer on backend services. So yeah, picking services, we really look into if they have a GraphQL endpoint and so on. Sadek: But do you have some customer that would say, No, no, no, I don't want that framework? Or would adapt-- like, would you choose a technology, you try to convince, or sometimes you say, "Okay, you don't like React, we are going for, I don't know, Node or some other framework", or how does it go? You are not going to get the most for your money, if we have to use something that we are not 100% proficient at". We are very forward-facing technology-wise, so we use everything that's futuristic and nice Birkir: Yeah, that's a good question. We are conservative of the client's time and money, as well, as well as our time, so we are very transparent, and we just say, "You are not going to get the most for your money, if we have to use something that we are not 100% proficient at". Something that we are very good at doing, we can do the most efficient, we absolutely recommend going that route, and we are very forward-facing technology-wise, so we use everything that's futuristic and nice. So it happens, sometimes, that clients tell you we're afraid of that. Yeah, and sometimes they don't have the capabilities of actually going to something more modern, if you will. They may be mental locked in into some specific technologies. Sadek: Is that okay for you? Birkir: Sometimes it's okay, and we just have to work around that. Sometimes we can just deliver html, and the client has a third party provider, who translates that into their system. But then they will lose the beauty of the perfection of the execution, right? Sadek: Yeah, but if it happens, would you be like, I don't know, I would be disappointed, upset, if I see something that is broken into something not as efficient, without the transitions that I would like. Sadek: Yeah, it's a hard one, actually. Birkir: Because, yeah, we do a lot of things that maybe we wouldn't put our name under. We would just show you the design and the html that we provided, which is amazing. And then when it's translated into whatever system, it may be misinterpreted, you know. So-- Sadek: Yeah, there's so many aspects, right? It's not like-- first in the implementation, you need to be pixel-perfect, and then, also, in the execution, it should not be slow, it should show in the right order-- Birkir: Absolutely. Sadek: So many things. Transitions-- Birkir: Yeah, and responsive. I mean, that's one of the biggest-- Often, most of the time, we don't get different breakpoints. We only get the desktop design, and like I said before, our dev team is an extension of the design team. We figure out a way to make it work in mobile and make it beautiful in mobile. It's really organic. Sadek: Yeah, that's that big part of the perfection of the design. It's not the design itself. It's the execution, and how it happens, and the team that is very coherent and works together, so that you achieve a global thing that's actually is a good experience. Birkir: Absolutely. Sadek: And do you use BareCSS? Or do you use some kind of framework? Our stack is basically, we use CSS modules, no matter what kind of CSS system we use, even if it's Sass or LESS or Stylus, it doesn't matter. Birkir: Yeah, good question. We mostly stick to Sass nowadays. Our stack is basically, we use CSS modules, no matter what kind of CSS system we use, even if it's Sass or LESS or Stylus, it doesn't matter. We always have to use CSS modules on top, so that we don't interfere CSS classes with each other. If we have two developers working on a button, and they both name their class button, we don't want them to interfere. So CSS modules are very important for us. Yeah. Sadek: And now that we talked about all these topics, when you have a website, and you break it into pages, do you design some kind of design system for that website or some kind of coherent UI kit, before getting to the design itself? Or how does it work? Birkir: Yeah, we have different types of projects. Sometimes we just have marketing side, so that's a one-off thing that just lives for maybe three months. We don't go all-in into UI kits at that point, but sometimes we get a very high-profile website that has to live forever, and there's kind of a future project. We go and create that style guide in the beginning, in InDesign, and then later, we may end up creating a UI kit with some sort of tool. Or even just, our basic is usually just create a page within the website called elements, and we just list out all the different React components in that page. Sadek: Interesting. Now that-- all these choices, all these choices of framework, technology, methods of working, who does it? Is there some team that is always thinking? Or does it evolves and some team will say like, "Okay, on the last page we worked on this and it's really nice, maybe we should replicate that in other projects?" How does it go? Birkir: So in terms of selecting technologies? Sadek: Yes, technologies and methodology. Birkir: Yeah, we have a variety of developers, and everybody has input always, so like, oh, I used this great technology before, we should definitely try it. We used it on the last project, we should stick to it. That's definitely how it goes. We just try new things, and if it's good, we stick to it. Sadek: Right, cool. So now, maybe in the future, in the next video, we talk about the React framework that you are using, and then we talk about, in another video, about the Headless CMS, and how do you choose that, and which ones you use. Birkir: Absolutely. Sadek: Cool. Thanks. Birkir: Thank you.
Related posts Unpopular opinion: why required fields lead to terrible UX by Renaud Bressand, on November 05,2018 How Ueno chose their framework and why they went with Gatsby by Edward Hewitt, on June 07,2019