How XD changed Adobe with Talin Wadsworth, the Lead Designer at Adobe XD

Matous Roskovec

Hey Talin, let’s start with who you are and what you do.

Yeah. I'm Talin Wadsworth, the Lead Designer for Adobe XD. I’ve been working on XD for about four years now, and I was one of the original team members who built the prototype of XD. Overall though, I've been at Adobe as part of the Adobe design organization for eight years. In that time, I’ve been lucky to work on a variety of projects from our transformation to Creative Cloud, our mobile applications, and our first cloud-connected workflows. All of those projects set the stage for my work on XD.

As one of the founding team members, how did you join the team, and what was your role back then?

A funny thing happened to Adobe design. About five years ago, they decided to sunset Fireworks. I had never used it before joining Adobe, but every designer at Adobe was using Fireworks. It took me a while to fully wrap my head around it, coming from mainly using Illustrator and InDesign for years, but once it clicked I knew why everybody loved it.

It did everything someone who was designing for screens wanted - it was (relatively) fast, accurate, and made for the world of pixels. We also started to see a need for integrating motion and interaction into our workflow. So I ended up adopting Keynote. It became my tool of choice, even though it was a presentation tool.

It allowed me to bring life to my designs because when we’re designing interactive experiences, and we’re having more control over the storytelling and the fidelity of those interactions, we need a tool that allows us to communicate those ideas. I was using Keynote and After Effects on many projects, but both were very limited. They were both very linear storytelling devices and were not interactive at all - you couldn’t fake it.

As Fireworks went away again, a sort of an existential crisis consumed Adobe design: What tools do we use? What helps us be more efficient when it helps us do our jobs better? There were many debates, but it was evident that we were missing something like Fireworks that was tailor-made to the job that we needed to do.

We were inspired by Fireworks and other tools that Macromedia brought to the table, even Flash. Maybe Flash had eventually over-rotated, but it used to be a platform that designers used to bring life to the Web. By enabling motion and interactivity, it led to an explosion of new experiences and creativity on the Web. I think it pushed the Web to where it is today.

We were inspired by Fireworks and other tools that Macromedia brought to the table, even Flash.

My underlying principal statement is that when designers have access to the tools that allow them to dream, innovate, and push frameworks forward, you start seeing a real explosion of new applications, services, and experiences on these platforms. Without the tools that allow us to work with motion interactions - which is a part of everything that we do now - how are we supposed to come up with great user experience? What were we leaving on the table in doing the design in Photoshop or Sketch or whatever, and then having to switch to another tool just to start adding elements of motion and interactivity?

It just felt excruciating. We kept asking: Where’s the modern tool meant for screen designers, which has the best of visual design and motion interactivity built into it. And that was the start of XD.

Before me, Tom Krcha, NJ, and Andrew Shorten got together to build this thing, I had actually already started working on something like XD - at least something in the same wheelhouse. Of course, to do any project right, you have to have the right partners. I had this project, and suddenly, my engineering partner left the company. A couple of months later, I found out that Tom, Andrew, and NJ were working on this new thing, and they needed a designer. So I just raised my hand and said: well, I'm going to do this!

When we came together it was crazy how quickly we had a “mind melt”. We had some early designs and concepts from my previous project, a white paper with insights from our customers, and some prototypes. We all just came together in one meeting, threw everything on the table, and started working together seamlessly.

We all just came together in one meeting, threw everything on the table, and started working together seamlessly.

I remember that Adobe Experience Design came only after it was called Project Comet. How did you come up with that name?

Well, actually our original name was Project Sparkler, which we came up in regard to Fireworks. It’s a fun fact that we were to announce it at Adobe Max conference where we should have also introduced another product called Spark. So we couldn’t have a Project Sparkler aside Spark. Thus, Project Comet was born.

Curious about Avocode? Learn everything in our Weekly Webinar.

It takes just 11 minutes to be a Pro.

I noticed that performance is one of the key differentiators of Adobe XD. How do you keep performance as a priority in product development?

Performance is there from the very beginning because we all knew that if people are going to be working in a tool 8-12 hours a day, you don’t want any lags. We all still remember Illustrator crashing, the spinners, the long rendering just when you were moving around the canvas - all these things are like death by a thousand cuts. We had this core idea: "design at the speed of thought" - both in performance and in the user experience of the application. Anytime you have to wait for the spinner or have to manage some UI panels and stop what you’re doing - it builds up time.

If people are going to be working in a tool 8-12 hours a day, you don’t want any lags.

We have incredible engineers working on our rendering canvas, and we’re trying to bring that canvas across all platforms. We ensure that performance is still number one when we’re implementing new features.

When I compare the XD interface to Photoshop and Illustrator, it looks completely different and feels very lightweight. How do you keep it so clean?

I think we have a clear vision of the workflows that we want to enable. It starts at the top. We have a clear priority and though it pains me that there were features in the original prototype that we haven’t shipped in XD, they didn’t fit into that vision. It’s always a tough choice that we have to make.

Can you give me some example of the early feature ideas?

Let’s just say it had something to do with drawing - like wild exploration drawing. It was a little bit of a companion to Repeat grid. We are still making hard decisions to make sure that XD feels streamlined and user-friendly, sometimes almost too much. One of the weirdest critiques that I've ever heard about XD was that it’s too simple, that it doesn’t look like a pro tool, because it’s depth isn’t on display right in all the panels - like in Photoshop where you kind of feel like you can do everything.

One of the weirdest critiques that I've ever heard about XD was that it’s too simple.

In a way, XD feels too simple to a lot of people, and I think it belies a lot of the power that’s in there. On the design side, we’ve tried to emphasize both direct action and on-canvas interaction so you wouldn’t have to move your eyes around the screen too much. In terms of onboarding, we’re also working with progressive disclosure: from the contextual nature of the panel on the right-hand side and switching from the design to prototype, into much more advanced interactions and animation. This idea is that you progressively move forward in satisfying the criteria of your design work while some features remain unlocked - but are there when you need them.

We think about what designers do all the time, what they do some of the time, and what they do less frequently. All those things build-up to how we organize the UI and the workflows within XD.

This idea is that you progressively move forward in satisfying the criteria of your design work while some features remain unlocked - but are there when you need them.

Is that something unique for XD or can we expect a similar approach to appear in other Adobe tools?

I think that XD is setting the template and the patterns for the next generation Adobe tools. We have a kind of an internal design system called Spectrum and XD was the first application built based on it. We have established a lot of patterns for new apps that are coming out like Dimension or Rush and a bunch of other upcoming iPad apps like Project Rocket and Gemini.

I expect to see a lot more. And of course, Photoshop and Illustrator will also update to utilize those controls and some of those patterns. Recently, Illustrator introduced a new unified panel, and the catalyst for that was XD.

Photoshop now works on the iPad Pro. Would it make sense to bring XD also to the iPad?

Maybe. It’s definitely on our radar. If a lot of users tell us that they have adopted a tablet like the iPad as their tool, then we can firm up those plans. It always comes down to priorities. We build in an iterative, responsive way.

How big is the Adobe XD team nowadays?

I think that we have a large team. Eight years ago, when I joined Adobe, I was in a product team. Back then, a product team was lucky if they had one designer. If you had two designers on your product, oh man! You were like wow - how did you do that? Now, there are 14 designers working on Adobe XD, across Mac, Windows, and Mobile.

Eight years ago, a product team was lucky if they had one designer. Now, there are 14 designers working on Adobe XD.

In many ways, our team is setting the bar for investment in design. We’re laying the foundations for other teams. We now have more designers working on After Effects than we have ever had before. Design has become a priority, and, I think, XD has led the charge on that front as well.

When I joined Adobe, there were maybe like 90 designers. Now there is a little over 300. I don't know the exact number. But again and again, sort of speaks to this sort of like transformation from a very engineering driven company to a very design focused company.

When I joined Adobe, there were maybe like 90 designers. Now there is a little over 300.

You mentioned that even at Adobe, more designers are working together on one product. How do you think design collaboration should look like in the future?

In terms of teams, I think the more we can share information, the more efficiently we can work, and the more we can all trust that we’re doing the right thing. We’ve all seen the adoption of cloud-based workflows over the past five or eight years. Dropbox was kind of my first foray into building up that efficiency while working with other people. It’s always like: where’s the file? There’s the file! We’ve all got it. I think we essentially saw XD as a cloud-native tool and we have been working on bringing it to the cloud. Collaboration inside the document is happening this year - the team is working on it right now.

Collaboration inside the document is happening this year - the team is working on it right now.

You can share a cloud document today in XD, but can’t work on it with others in real-time yet, but that will be coming later this year. Having everybody has a single source of truth, the most up to date version, to see changes in real time, that makes me feel more confident to go on to do what I’m doing.

I’m sure you’re getting tons of feature requests. How do you prioritize what to build?

It all starts with research. We have a clear vision of the tool that we've set up to build, and that’s based on research - both our foundational research when we first got together and the ongoing quantitative and qualitative research efforts. We work with a fantastic research team that helps us do more ethnography studies. We’re looking at how work is changing and at the things that designers try to do all over the world. That’s where we base our vision for products. The other pieces that come into play are direct interactions with people. When we see a problem they’re having, we’re always evaluating it and its priority against our research and visions.

Are you still sticking with the vision you had for XD four years ago or has it somehow changed?

It naturally had to morph and change. The “who are we building a tool for” hasn’t changed, but their needs have changed — for example, animation. When we first started, only a few cutting edge designers knew the role that motion and animation were going to play in UI and UX design.

Then we saw teams like the Material Design team at Google; we saw the maturity of the iOS platform. However, when we asked like 80-90% of designers if they are doing any UI animation or micro-interactions, they’d be like no, no, no, we don’t need that. But again we saw the landscape that was trying to change. So we placed one bet on animation and ended up with the auto-animate feature. We don’t want to go too far too fast, but now we’re seeing more and more designers are adopting animation in their toolkit. This exactly where our foundational research helped us have a clear stake in the ground. As the industry changed, the priority of animation just grew, and as more and more designers were asking for it, we just moved it up the priority list and launched it last year.

What about design systems? Was that something you predicted three-four years ago or is it something users helped you prioritize? To be exact, I mean, for example, the introduction of Linked Symbols.

I think we had a firm conviction on collaborative workflows in the cloud. If you look at the models of collaboration around assets and the use of assets around within a team environment, you know there are clear patterns that we were able to pull from - in terms of design. I’m talking about those tools where you could bring in reference to the source of information that was outside of the document that you’re working on. We knew that there was this need to be connected to a source of information, and if that source changed, I needed to make sure that I was up to date. That’s the power of the cloud. When the document is in the cloud, we can track it, and we know where it is. So naturally, the Linked Symbol workflow was always there when we thought about cloud-based workflows.

With the design systems conversation coming online, we’ve seen that need to collaborate around assets and components in the design tool but then also extend them into the dev environment. We just launched Linked Assets across documents, and we updated the capabilities of components. So that's kind of like Step 1.

Now we’re corralling a bunch of different pieces to begin to address that design systems workflow need that the teams and organizations are having.

Speaking of developers, how can developers access design systems in XD?

In the short term, we have some plans to work on this as a part of the design specs hand-off. We want to make sure that a similar pattern of changes will flow over to other services and other stakeholders. Hopefully, we’re going to open up that for extensibility as well. We’ve been very aware that each team that is translating a design into a framework or some other processes has very different needs. When the design document is the single source of truth, the developer can access the information they need. Hopefully, through extensibility, people will show us how they would use that information inside their own frameworks and their processes and would be able to make the next steps from there.

From our talks with other design teams, we found out that many companies have one design system in design and another one in code, but they are not really synced. Where do you think the source of truth should be?

Wow, that’s a good question. I mean I’m sure you have some great thoughts on that too. I think that there is a camp that says that the source of truth should be the code and then there’s something that can then generate the design artifact. We have these debates with my friend all the time. If the source of truth is defined in the framework does that limit what the designer can do with it? Do they have to align their work within the shortcomings of that platform?

In some ways it’s great. You know iOS dev kit in Xcode or the Human Interface Guidelines can accelerate your work and can accelerate you getting your product out there faster, but speaking from personal experience, we couldn’t just accept the UI framework of Illustrator when building XD - we had to define new patterns.

I think it leads to really great things when designers and developers are having that conversation and pushing each other to what’s possible. I think there’s room for design being the source of truth that is translated into code and vice versa. Maybe there’s even something in the middle like a platform that can allow for that freedom and flexibility on both ends.

I think it leads to really great things when designers and developers are having that conversation and pushing each other to what’s possible.

A lot of teams are using more than one design tool. They too need to share design information into one system. How do you see that could work? Should there be some universal design format standard?

OK, this goes back to a conversation I had with our mutual friend Tom Krcha. I think I have been down the road of the universal format concept before. Now, I believe it will become available more through openness and through open sourcing or creating an extensibility platform that will allow other teams, other tools, and other products to take what they need for their work.

Even here, inside Adobe, cross-app workflow is a big topic, and I’m trying to sort of look at it right now. If the XD document is in the cloud and there are APIs that address every part of that document that seems pretty powerful. I don’t know what’s possible at that point. I like the question, and I’m excited about the possibility. I don’t know what’s there yet, but there’s something fascinating about the way we’re opening up the document to be extended into I don’t know where. I’m just excited to see.

It’s great that your API allows tools like Avocode or Airtable integrate with XD. Do you have a dedicated team just for integrations?

We do. On XD we have the Extensibility Team which is creating those APIs to the document and the UI of XD, and then we have a Plugins Team which is building the processes for documentation, curation, and submission of third-party applications and they are also creating UI parts that third-party developers can use for their XD plugins. The cool thing about this kit is that it’s cross-platform, so when third-party developers submit and publish their plugin, it’s automatically available across Mac and Windows and also will be available to other applications like Avocode when they come online.

Currently, the API allows third-party developers only to get data out of XD. Do you plan to enable pushing and writing data into XD?

Actually, you can do that with some of the APIs already today. In the future you’ll be able to write to the canvas, I believe. I’m also working on a plugin of my own for the assets panel. You would just pick your colors and typefaces, click GO, and it would populate them all in the assets panel with all those global assets, styles, and components.

You know whenever we have a spare moment we’re interested in plugins. Not just at XD but all over Adobe. For example, the World Ready plugin has been made internally, or there are others that, for example, translate your design to other languages.

In terms of future of design, we see this significant shift towards new experiences like VR, AR, and all sorts of new interactive surfaces. How is XD preparing for this future?

I think that’s a fascinating topic. I've been feeling that need to extend beyond screens and be able to design and communicate in areas like VR. I believe that before those platforms can reach their full potential, there need to be tools that lower the barrier at least to prototype in those places. Right now you have to be that unicorn, that motivated a person to go and navigate those very painful workflows just to be able to get the "hello world" in AR and VR. I think there’s a place for a tool to allow designers to prototype, to be able to push these platforms forward and work with their development partners to ask for new capabilities and to imagine what’s possible. So as I said, it’s a fascinating topic, and we’re interested in it. I can’t share much more than that right now, though.

What about interfaces that have no UI?

Today, it feels like you need a visual to tie a voice to. But we’d love to explore around UI-less interactions - just around voice. It probably lives in some future plan for the prototype mode, but we’ll have to see. I don’t know yet.

Do you think such tools should live on their own or inside XD?

Well, I would ask you as the user. That would be the same as if we’re ever going to do anything in VR; we’ll have to find out if the users would like to do that inside XD. Anytime people ask us about something, we consider it and come back with a clearly stated opinion founded on research.

Bonus Question: What’s your favorite way to eat an avocado?

Haha, well I grew up in Salt Lake City in Utah and when I was growing up there were not many avocados. So I was introduced to avocados quite late, unlike my kids who grew up in California where avocados are almost like the first food you get. So nowadays I think it’s just with a bit of salt - that’s the best way.

Share this article

Become a better designer with The Grit free e-book

Learn how to get ahead of your competition based on our interviews with leaders from companies like Intercom, Dribbble, or Figma.

Get the all new Avocode today.

New features. New look.
Greatly improved performance.