Design System & Code Prototyping: Bridging UX Research and Engineering

Lughni Alfadjri at UXDX Community: Accelerating Product with AI & Design Systems. Video: https://youtu.be/EfIp-WJg_vU

Readable transcript: edited from the recording's captions for readability (fillers and false starts removed, punctuation and section headings added). Wording is the speaker's own. Timestamps are positions in the video. Names marked [?] could not be verified against the audio.

Design systems are more than production

[00:00:07] Lughni: My name is Lughni. At this moment I'm working as a design technology manager at Puma. I'm managing the technical part of the Puma design system and also leading UX engineering. Nice to meet you. In this agenda there are four main parts that I would like to give an overview of. First is the design system's relationship with code prototyping. The second one is the tech stack for code prototyping. The third one is the engineering connection to UX research. And the fourth one is the takeaways of this overview.

[00:00:50] We have been aware of the benefits of a design system for production, which are to create a consistent user experience, to be a source of truth for building digital products, and reuse will speed up development, and pre-tested components work better, and so on. But actually a design system is much more than just for production. The nature of reusable UI in a design system is a very powerful infrastructure to build prototypes, either in design or code, to support your UX research team.

[00:01:39] If we see this flow, or scope I would say, there are three kinds of generic prototype. First we have the lo-fi prototype, second we have the mid-fi prototype, and with higher interactivity we have the hi-fi prototype. We also have the full-stack prototype, which also includes the API as well. However, if we think in a structural way, we see that we can actually use UI from the design system to create mid-fi and hi-fi prototypes. For example, we can have a very static prototype with the design system, with no interactivity at all, or we can also build a very interactive prototype using the design system, and it goes for both design and code. In this session we're focusing on how code prototyping with design systems can build a very powerful prototype, and I will give you a comprehensive technical view of why it is powerful.

The tech stack for code prototypes

[00:03:02] To build a hi-fi prototype, it is important to treat the design system code components as a part of the equation instead of relying on them alone. But first I would like to give you an overview of software architecture in general. Of course this is a general diagram; there are more complex and more simple architectures. First we have the front-end layer; this is the front end of the website. Then we have the API layer, then the back-end layer, and then the database layer. This is an example of a full working website or platform that we see every day.

[00:03:52] However, to build a very interactive and realistic prototype, we only need the front-end layer, because the goal of a prototype is literally not to deploy to production. The goal is to learn from the users. If we go a little bit deeper, we will see that in the front-end layer we have frameworks, UI components, state management and data storage. For frameworks right now, React has been very popular, Vue, Angular. For state management, from React, Redux; from Vue, Vuex; and from Angular, NgRx [?]. And we can use local JSON for data storage. For UI components, back then we could use Bootstrap. Right now design systems have become more popular and one of the most effective tools to build products.

[00:05:02] The design system is becoming part of the equation to build code prototypes, and as you see here, the design system alone is not enough. We need to also think about the rest of the stack, which is the frameworks, the state management and the data storage, and I will give you a little demo of that and how it makes a difference.

[00:05:25] The difference between production and a code prototype is that code prototypes have no back-end manipulation. We don't need to build integrations with back ends. Of course we can do it if you want to build a prototype using an API to test some external data, but overall, for a generic purpose, we don't need to use back-end data or back-end logic. The second one: the code in a code prototype is not for production, because the goal here is really to learn from the users. As we build this prototype to learn from the users, we can build it as fast as possible. We don't need to worry about the API. We don't need to worry about how the logic works with GraphQL, because everything is handled in the front end.

A demo: everything in the front end

[00:06:26] Now I will give you an example of how we build prototypes in our team, collaborating with our UX researchers. As you can see here, with the code prototype, when we want to test some features, we can literally put an input there, and dynamically it will show the result, because it sends the data from the input to the other elements. This can be done using the data management that I mentioned before. It looks like we have already built the full production version, but it's actually not. This is literally front-end technology that creates this prototype.

[00:07:11] This interactivity, which gives the ability to send data, is the thing that makes code prototypes very dynamic, and we can also create a very complex prototype, where if we implemented this feature in production, it might cost a lot of time and money. This prototype, for example, is only using front-end logic. It's composed with our Puma design system, and I'm using JSON as local storage. If you see the text, all of this information, there is no back end. Everything is data from JSON that I already wrote, so literally everything is in the front end.

[00:08:01] Coming back to this code prototype tech stack: we have the frameworks, the UI components, state management and data storage. That is the formula to build a code prototype in a very realistic, real-world context. What I want to emphasize is that by combining the tech stack with design systems, we will have the ability to not only speed up the code prototype but also create a real-world context prototype, especially when we want to build something complex where we don't have the logic yet. We can build a very dynamic journey on it, based on different requirements, based on different logic, and everything is literally in the front end. Again, no back-end manipulation. That's why it can be built fast.

UX engineering and UX research: same goal, different skills

[00:09:05] Now I would like to give you an overview of how code prototypes work together with UX research, from my experience. UX engineers and UX researchers have the same goal. Their goal is to create a better consumer experience. They have two different skill sets, but they have the same goal. The goal of the user researcher is: I need to do user testing with a prototype as realistic as possible, because then they can get results that are very close to what they want. And UX engineers also have a goal, which is: I want to build a prototype as realistic as possible to support UX research.

[00:09:58] Of course they are coming from different worlds. UX researchers have a different skill set, UX engineers have a different skill set, but even though they come from two distant fields, they need to really work together. They need to have very strong collaboration, because that's the only way to build a very realistic code prototype that can answer your UX researchers' questions. So collaboration is a really important part. It's not enough just to have very skillful UX engineers or very skillful UX researchers to build this realistic, helpful code prototype. Collaboration is very, very fundamental.

[00:10:48] In this product-building process, in the learning phase, UX designers, UX engineers and UX researchers iterate together. When the product manager has an idea, they collaborate together and iterate to find the best prototype to answer the questions, and everyone here has their own power and can contribute to the success of the prototype. The UX designer [?] also has a very important role here, because the UX engineer will use the UX designer's good design prototype to build the code prototype. So again, it's really about collaboration here.

[00:11:49] Through strong collaboration, a well-defined [?] code prototype can be an effective medium to bridge engineering and UX research. The code prototype is really engineered to help user researchers. It's not engineered to deploy to production; it's engineered to validate the research questions. That's very important here.

When to use a code prototype

[00:12:19] When is the best time to use a code prototype? I think there is no one-for-all answer. Sometimes it's better to use a Figma prototype, sometimes it's better to use a code prototype, and sometimes it's better to use A/B testing. It just depends on the situation that we have. But in my experience, when we have one of these three situations, we will start to use a code prototype.

[00:12:56] First, when we don't have the existing logic. For example, we want to implement a feature called chat, and in chat we want the user to be able to input text, put a message there, and get an automatic reply. Before we deploy to production and spend so much money on this feature, we can literally just build a prototype of it, mock the API, and make it very realistic, so the users really can chat with the chatbot and have the ability to interact with it. Sometimes, when we want to put it in our platform directly, it will cost months in terms of time and so much money to build. So when we don't have the logic and it takes a lot of time to build, I think before we invest in that idea, it's better to test it with a code prototype.

[00:14:07] The next one is when we need a very dynamic journey. For example, we want a feature that is very complex, where we have to send the data back and forth, like the one I showed you just now, where the users need to input some names and numbers. We need to test with the users how they put in their own name, not a name that we already predefined. They can just type their name and their number there, and this means it's very dynamic. If we want to implement this very complex feature, then we need a code prototype, because the programmatic approach that the front end has would be super helpful to mediate between the user researcher and the user tester on this prototype.

[00:15:08] The last one is realistic context. Sometimes, with a dynamic journey, we need to be very realistic; the prototype cannot be static. For example, in the journey [?] we wanted users to literally be able to put their name and number in, and this is not possible with a static file, because they cannot put their information there. If we go a little bit deeper, we'll probably also go into how the user interacts with the input text, how the input text is perceived by the users, and all of this matters and can be answered by using a code prototype.

Four takeaways

[00:15:53] In conclusion, there are four important takeaways that I would like to share with you all. First, it is really possible to build a real-world context prototype in very, very quick time. It's very possible because we don't need to touch any back end. All we need is front-end skill, and then we can manipulate all of this back end using our local storage data. We can use state management, and this will already be the formula to build a realistic, real-world context prototype.

[00:16:33] Second, it's important that the tech stack for code prototypes and production is not the same. Production, as I shared with you, is a really big architecture, from front end to back end to database. It's a different level of complexity. With a code prototype we only need the front-end layer. So basically the framework; right now it's very popular to use React, for example. For the UI components, we just need to use our design system, and we've already built a prototype which is very similar to our production platform or app. Then state management, to manage the data interactions. And then local storage like JSON, which we can use to mimic the database, so that rather than connecting to a database, we can just connect it to our front-end layer.

[00:17:34] The third one, also from our experience: in terms of code prototypes, we need to start from zero, and we need to treat it as a product, not a project. Sometimes we use it as a project, and it will not evolve. If you treat a code prototype as a product, you will know what you need to improve. In our team we have our own internal code prototype, and we treat it as a product. It evolves over time, it grows, and we give it some features, in terms of search, in terms of finding the prototype. We do not treat it as a project; we treat it as a product that keeps evolving.

[00:18:26] The last one is very, very important, and this is really about human relationships. It's not only about the ability to code, and it's not only about the ability to test. Literally, two powers are combined to build a powerful prototype and also to be able to find the users' needs effectively. So close collaboration is so fundamental. I think that's all from my overview. Feel free to ask questions if something is not clear or you need more information. Thank you.

Q&A

[00:19:09] Rory: Thank you very much, Lughni. That was a really nice view of it from an engineer's perspective. A lot of people listening out there might be more used to it from the UX research or design perspective, so thank you for sharing that. I'll jump in with the first question, because I'm intrigued: how long would you typically spend creating one of these early prototypes, and has that improved over time?

[00:19:40] Lughni: Yes. For example, when we build the product, we normally literally build the MVP of the platform, and then over time we grow it, because the user researchers will request some features that need to be tested. So over time it grows to be a product as well, and when we want to build another prototype, it becomes very fast to build. The first one is a little bit slow, but not so slow, because everything is available there. The UI is already available, the logic is already available in the front end, the data is available. We literally don't need to worry about anything. We just need to worry about what we need to test, and how we can build a prototype that really helps the user researchers find the answers they want. So it's not so slow; it's actually very quick. For me, for example, one whole day is enough to build a prototype, because we already have an MVP; we just need to add the logic on it as well.

[00:21:03] Rory: Awesome. That's a nice, quick "come up with an idea, prototype it, test it, prototype it, test it." That's great. And what kind of collaboration is there? I'm always intrigued: do you sit together? Do engineers attend interviews with customers? You mentioned close collaboration, but how does that actually work in practice?

[00:21:25] Lughni: I want to shout out to my colleague Katherine, as a user researcher. The close collaboration literally happens in a very early phase. When we have an idea, for example the product manager has an idea, then UX designers will start to sketch the designs based on the product manager's idea, and then my colleagues, the user researchers, will start to iterate and get an overview of what they want to do, what answers they want to find, what they want to test. At that time I will be invited as well, because I will give an overview of what kind of code prototype can be helpful. I can give the overview from a code perspective, a very interactive, realistic perspective, and the UX designer can give a very nice conceptual design of it, and the user researchers can then iterate together. So the collaboration really starts at a very early phase, in the iterate phase. It doesn't start with, "Hey, we have a design, you need to code it." It's not like that. It's literally at a very early phase.

[00:22:59] Rory: Excellent. I know in some companies budget is always the thing that comes up: we're very early days, we haven't secured budget because we don't have enough of a business case put together. Are there any challenges with that in your company, in dedicating people to work on these very early-stage ideas?

[00:23:19] Lughni: I think the best way is to combine the design system and UX engineering roles, in my opinion, because they are very close. They're very interconnected. Design systems and UX engineering, in my opinion, are like siblings. People who work in UX engineering are normally familiar with design systems. People who are in design system engineering are very aware of UX engineering, because they are also aware of the design and implementing it in code. So they are typically siblings, in my opinion, and someone can share the same role if they don't have the budget, for example, or if they want to increase the team but want to be more connected. Sometimes, in my opinion, it's better to just have design systems and UX engineering in the same space. They're very, very close.

[00:24:25] Rory: I'm going to ask maybe a tricky one, or maybe not tricky. If you're going with that front-end-first approach, so you're mocking up the front end, is there a risk that when you get to development, the back end and the other parts of the stack, you've designed something that's incredibly expensive from a query perspective, or the data isn't available, challenges that you might encounter on the back end?

[00:24:56] Lughni: Yes. Actually, that's the role of the UX engineer here: they're already aware of the possible technical challenges that the team could have if they want to build this, because the technical people can give an overview from a technical view. I think having that person bridging engineering and UX research, and giving the overview of what's possible and what's not possible, is super powerful, because it will minimize the risk of failing projects. This engineering skill is super useful, not only for production but also to analyze whether a feature is possible or not.

[00:25:47] Rory: Excellent. It is great to get that insight before you go down a dead end by accident. You mentioned that this works best for greenfield sites, where you're starting from scratch. What about those big nasty existing systems that we're continuously updating? As you said, it's a product; it never finishes. Can you do the same thing with your existing systems, or is it not really as effective?

[00:26:18] Lughni: I think that's possible, because basically the key here is to build the MVP part of it, because the MVP will grow. If we have the MVP, we can structure it and manage it in micro parts, so that it becomes manageable. But again, if we don't treat it as a product, we'll just treat it like, okay, we'll do it now and think about the next step later. When we treat it as a product, then we will have a plan for the approach we need to take to be successful in the long term with the prototype infrastructure. So I think it's still possible, either with a complex or a very clean base.

[00:27:09] Rory: And I'll leave you with the question that everybody always asks these days: how are you using AI to get even faster still?

[00:27:19] Lughni: That's also a very good question. I think the power of AI is that it can create prototypes really quickly. But AI right now is still not connected to the design system, I assume. Cursor AI, or other coding AI, have not been connected to the design system. So when we build a prototype, it's possible, but it's likely [?] that it will be very similar to our platforms, and if it's not similar, then it will be a little bit tricky for the user research goal, because what they want to find and what they will have in the real platform will not be the same. But I think in the future it will be easier. My prediction is that AI will be more integrated with design systems, and then building code prototypes will be faster with the help of AI. So I'm very optimistic about that.

[00:28:22] Rory: Excellent. I'm blown away by the recent Claude Code release and how accurately it can review a code base and create stuff. So we'll see; in a few more months they'll release an upgrade, and we'll see where it goes. Excellent. Well, that brings us to time, so thank you very much, Lughni, for sharing your insights about how you're prototyping with UX at Puma.

[00:28:47] Lughni: Thank you so much, Rory. Appreciate it.