Back to Blog

Product Hero: Talin Wadsworth, Sr. UX Design Lead at Adobe

Author

Talin Wadsworth of Adobe
Product Hero
is our bi-weekly series to highlight outstanding members of the product management community. These industry leaders share tips on processes, team building, how to be a better product manager, and who they are outside of their careers. This week our product hero is Talin Wadsworth, Lead Designer for Adobe Experience Design (XD).

C. Todd: I’m here with our latest Product Hero, Talin Wadsworth. Talin, could you start by giving us a short intro about you, your background, and how you ended up in the world of product design?

Talin: I’m originally from Salt Lake City, Utah. I had gone to school there and had been working professionally as a designer for about a year at a print shop doing a lot of service design for people coming in off the street. I wanted to see what else was out there. I was really attracted to the Bay Area. I ended up coming to California College of the Arts (CCA) to get my bachelor’s degree in design.

I started down the design path doing more traditional design – a lot of brand work, logos, and collateral. I was always really into printing, screen printing, and letterpress as well. At CCA, we were taught to solve problems using design thinking regardless of the medium.

After working at an interdisciplinary studio run by a professor of mine at CCA, I ended up at Adobe. The job was about creating tools and services to help people like myself and other creatives make great things. I was really attracted to solving those types of problems. It wasn’t about tech, and early on it wasn’t about products per se.

C. Todd: That’s really cool. Now you find yourself creating tools for people, being at a tools company. Tell me a little bit about what you’re working on right now at Adobe.

Talin: Right now I’m working on Adobe Experience Design (XD), which is a new app for experience designers. I’m designing a design tool for designers. As the lead product designer for Adobe XD, I’m working with a team to prototype those experiences and test them with users. Eventually we’ll deliver prototypes to a developer to help me communicate my ideas and experience. That’s what I’m focused on right now.

I was lucky enough to be there from the beginning of this project. I was one of the original four who built the prototype that went on to lay the foundation for what would become Adobe Experience.

C. Todd: Can you tell us more about Adobe XD? Where did the idea come from and why is it so cool?

Talin: We all just love tools here. I work for Adobe Design, our central design organization here at Adobe. We have designers that work on all of our major products and services: Creative Cloud, Acrobat’s Platform, and the Marketing Cloud, which is the marketing analytics tool.

We all sit with each other and we’re all thinking about our process and tools. Our goal is to communicate quickly and continuously with our development teams. As the demands of our work have grown, like many other product designers, our group is designing more than one experience at time. We’re designing for desktop and mobile experiences across different sizes of devices. Of course, we have to account for interactivity and designing in high fidelity. We have to communicate to developers. We have all of these challenges.

I’ve been here five years and I’ve only seen those expectations grow every year. In the past, you could have gotten away with showing static screens to your team or the executive team, but that just wasn’t cutting it anymore. It was taking too much time to manage and execute all of those pieces at once.

We were looking for tools to help us communicate. Then we saw an explosion of tools happening. Sketch was out there, really showing designers they could design for experiences using a lightweight tool. It was specifically for screens right at a time when people were really feeling the age of Photoshop and not trusting the accuracy of other tools.

We saw a need for improving the workflow of moving from one app like Illustrator, Photoshop, and Sketch to prototyping in another app. That gap can slow you down. What we needed was a modern tool, one where pixel perfect design was combined with motion and interactivity. We also need motion and interactivity built into the DNA of our tool to solve these problems.

I really did believe and still believe that tools influence outcomes. If you have a design tool that allows you to be fast, flexible, and accurate while still allowing you to play, designers could really push the boundaries of interactive design. That’s where we really started – out of a need for a new tool here at Adobe.

C. Todd: Can you describe the first prototype you mentioned, what did it look like and what functionalities were built in?

Talin: The very first prototype came to life by a team of two engineers, a product manager, and myself. The first step was just building a shared vision of what the tool was going to do. A lot of the early brainstorming was throwing ideas up on a white board and seeing what stuck or resonated with the team.

The first prototypes were really just trying to address pieces of the design and prototyping puzzle. The very first prototypes were simple experiments around the basics of screen design. One of the first tools we made was a simple repeater that allowed you to take a shape and quickly lay out a repetitive pattern of shapes as many times as you needed horizontally, vertically, in rows or columns. It wasn’t flashy, but when we really started playing with it, we started to see how it might fit into a designer’s workflow. We started to see how it applied to design patterns found in almost every mobile app. That simple shape repeater turned into what we ended up calling the Repeat Grid.

In our first demos of that early prototype, we created the Twitter feed live on stage, in less than a minute. That included filling it with content, using drag and drop capabilities to flow images in this repeated layout. You could make changes and see those changes cascade in real time. Then we copied, pasted, and adapted the layout to fit a webpage layout, like a wire-to-screen layout. That demo was really what got people sold on Adobe XD.

C. Todd: Who was that demo to? Was it to internal Adobe folks or external folks?

Talin: It was internal to our large pool of designers. We had of course been demoing that to our bosses, making sure that they knew we were doing something worthwhile.

The first wider group demo was on stage at our yearly design week conference that we have with all of the designers at Adobe. I designed the Twitter app and its web component in minutes on stage, in real time. It blew everyone’s mind.

From there, it was really about generating excitement and continuing to refine our story. And we took the prototype on the road. We started sharing our vision with designers outside of Adobe and validating those early concepts.

We had other wild things in the prototype too that didn’t end up making it because it wasn’t of value. Features that were nice to have. Even from the beginning, we knew we had to stay focused and continue to refine and validate our story.

C. Todd: There’s a lot of buzzwords out there right now in how product teams operate, like lean, agile, and sprint-based to name a few. How would you define how product is run at Adobe?

Talin: Talking about the broader scene here at Adobe, agile is the framework that the majority of people shipping products follow. They follow a sprint schedule. They come in at the start of the week and plan what’s going on over the next two weeks. We have regular stand-ups, check-ins, and a sprint review leading into implementation.

We operated a bit differently in the early days of building XD. We had a real startup feeling in mind since it was the four of us. We could talk about something in the morning and implement it that day and be testing it by the end of the day. As the project grew, we knew we needed some process to organize the problems we were going to tackle, in some sort of priority. Really defining what a designer was going to make with XD was huge in helping us define our roadmap. Again, I think it’s just like anyone, you’re bootstrapping it, figuring it out as you go.

The biggest challenge, though, has been scaling the team from our original four and implementing other processes just to communicate with a larger group of people. Now that we have to coordinate across multiple squads and teams, we follow a more defined sprint process to make sure we have something to ship.

On the development side, they all follow agile, scrum-based dev. On the design side, it’s never really been prescribed. One of the challenges as we scaled up as a team was organizing ourselves as designers. By the time it gets into the agile development process, it should theoretically be designed to a certain extent. Ideally, we’re providing the designs early, so our devs can better estimate their own efforts. That meant that we had to figure out what our process was as a design group. The challenge was making sure we were providing the designs on time to sync up schedules between product, design, and engineering to match the roadmap. We’re still experimenting and tweaking our process, but hopefully getting better at it all the time.

C. Todd: Do you have any anecdotes that you can share about building something and then discovering you were completely wrong about a hypothesis, or a design choice you made?

Talin: Layers man, layers. Let’s just say there was a goal to not have layers for awhile. I had a bias on that. I was never a big layers user. It turns out I’m not a big layers person because I was never a big Photoshop user. The first question and the most persistent question over the past year has been about why we didn’t include layers. People need layers, man. They need it. We put them off as long as we could.

It was funny to unpack that. We don’t have layers but we have all of the other things. Through interviews and user testing, we really found out how much designers rely on layers, and how much they’ve become part of their process. Going back to my point about how tools shape outcomes, this is a good example of that.

This open forum and dialogue with designers allowed us to think about layers in a new way. Now I’m almost as excited about adding layers in as I am about anything else we’ve done in the past eight months. That feature all came from talking with designers and getting feedback from our prototype early on in the process.

It’s been a great process. I think it’s made that feature better and it’s integrated into the product in the right way. Again, it’s not Photoshop layers, where Photoshop, really, it’s history is built around that layer stack. Layers in XD has a place in a workflow. Testing our design prototypes with real designers, early and often, helped us implement layers in a way that feels fresh, and feels like something we can build on in the right way for XD.

C. Todd: That speaks to one of my next questions around roadmapping, in that you obviously have some things that you’re listening for and you’re building. You can’t build everything all at once. What process does roadmapping play in your product development? How do you actually go about creating a roadmap for your product?

Talin: I think the minute there was more than four of us was the minute we needed a roadmap. The roadmap is really a tool to organize a group of people around a common goal. In that, roadmapping goes through a lot of discussion, a lot of workshopping, shopping it around, and getting feedback.

In the roadmap, we’re trying to balance a bunch of things. First we’re trying to support the user. We’re trying to give the designer, the creative out there, the tools that they need to be successful and create great work. That’s priority number one. Then we have the needs of business, tech, and design. Those are really the three legs of the stool there to support the user out there in the world. Always keeping in mind that our users are setting the roadmap.

For XD, they really are the greatest influence on that roadmap. We have a user voice forum. People can actually can go there, vote, and add suggestions for features they want to see in the app.

C. Todd: Do you make that roadmap available to all of your users?

Talin: We don’t explicitly in that way. However, through the ways in which we prioritize features and communicate with the community, we do. We don’t want to make promises that are too far out that may never happen the way that we think they’re going to happen now. That’s challenging.

What we want to do is communicate our priorities very clearly to the designers out there. We’re really honest with them and tell them what our priorities are to the best of our ability. Again, we don’t want to put a stake in the ground to then miss the mark. Like layers, if we had put an expiration date on layers and said layers is our highest priority, everyone is expecting layers. If we don’t deliver on layers for eight months, they’re left wondering. What we try to communicate is that layers are our priority. We’re just trying to put the best thinking that we have behind it. We just don’t want to bring you layers like Photoshop. We want to discover the best way to add a new feature to XD. A way that feels integrated into the design process.

C. Todd: Speaking of things that look out in the future, I read one of your blog posts around UX trends and product trends for 2016. Since we’re getting to the end of 2016, tell me a little bit about how accurate you feel that you were? Do you have some thoughts about what’s going on in 2017?

Talin: I think that we were accurate in that they’re all still in progress. We’re never really going to meet the promised world where we have these connected experiences across these different devices. We can blame a lot of things on that. Basically, it’s that this stuff is still happening in real time. I think those are all still pretty valid. The thing that I’m most interested in in the coming year, and this may or may not be right, is machine learning and its impact on user experiences.

C. Todd: I think that’s the thing when you think about machine learning and data driven design, those are the challenges that I think would be really powerful. How can we actually do that? How can we actually create that prototype that’s interactive, that a designer could do but still connect to some data source that is ours and populates the product? Because so many products today are becoming data driven.

That’s really interesting to hear or see. Are you guys doing things like that? How does that help bring stuff in?

Talin: We are. The minute we saw what we had with the Repeat Grid, the way in which we built it and the way in which it could connect to data locally. It starts with that drag and drop where you drag a set of local data and you drop it onto that Repeat Grid and it puts it where it needs to go, or you expect it to go, in the design. The promise, is that the Repeat Grid stays linked to that data source. That’s not happening quite yet. It’s basically embedding it. But the way in which we designed and implemented that feature, it was like, “Oh wow. This is powerful.”

What we got really excited about was – I remember when I’d be designing for a client and we were designing with dummy copy. You couldn’t actually fully unlock the potential of the design unless you had the real content, the real data. How can you design something if you don’t know what that data looks like? You don’t know what it could potentially look like. How do you design for something that is going to change the more people use it, the more people interact with it? How can you design for that? That’s crazy.

You end up with experiences that don’t quite unlock their full potential. They don’t quite tell the full story to the user about how this app or this service is going to adapt and change when it’s for you, and it’s for you not just today, but for you in a year or two years.

So, we did a sneak at Max where we actually connected to live data on the web. It was a natural next step: instead dragging in a set of images on my desktop, why don’t we connect it to a gallery of images on the web? Of course, that demo was an iterative next step. It was still embedding the images we scraped from the web. It wasn’t keeping that connection. Then at South by Southwest just earlier this year, we took the next step and hooked up XD to my Instagram accounts. Live, during our presentation, I had a design that I had shown linking to my Instagram account. I had a picture that I had taken of the audience, posted it to my Instagram and my design updated. My design changed, my prototype changed. There’s new data. It saw it and it flowed it right into the layout. That’s just scratching the surface of connecting to live sets of data.

Again, thinking about connecting to sources of data now that can help us to practically collaborate with teams or to prototype users own data. How does it change how we publish from XD? How does it change what XD could mean to not just prototyping but to app or service design? What power that gives designers when they’re connected to that?

On our end, the thing we’ve been thinking about is how user data can impact our UI and impact the experience of our apps. There’s a couple of things that are just ideas when we’re discussing things over lunch, or coffee, or drinks, ideas about what that would mean to our tool long term. We’re generating all of this data now. People are using these tools. We have data for people using all of our tools. How can that start impacting how we organize and arrange our experiences? Help people be better designers. That’s really been a goal of mine.

Thinking about how tools really impact outcomes. I don’t think we say that or think about that enough. I really and truly believe that. If you give a designer a tool that can connect to real sources of data, the results are going to be more dynamic, more engaging and I think a modern design tool really should be accounting for these advances that we have in technology.

C. Todd: What advice would you turn around and give to someone who is just entering the product and design field? How would you give them advice as they aspire to be a product designer?

Talin: I think the biggest thing is to be curious. That’s where it starts. You’ve got to be engaged with it. You’ve got to be completely immersed in that. Part of that is about defining what you’re into and what your interests are. That’s just where it starts. The other thing I had written down earlier is that once you have that and once you define what it is that drives you, then you’ve got to put in the hard work. Now starts the real hard work.

Part of being a designer is about finding your process and refining it over time. That’s the thing that you’re always going to be able to rely on as any creative – your process. That’s why you go to school. That’s why you go and get a job somewhere as an intern to just get your feet wet. You’re looking to build process through experience. School is one type of experience builder. Work is another type of experience builder. All of that leads to, again, refining your process. That process should really be organized around things that drive you. Stay curious.

C. Todd: What’s missing in the product design or product management conversation today?

Talin: I was actually just talking about this the other day with some colleagues – intuition. I feel like intuition is completely not part of the conversation right now. That’s because we’re so in love with data. I really think that now we have to find ways to integrate data in smart ways and meaningful and useful ways. We can’t forget intuition. We can’t forget the role that intuition plays in a creative process, in pushing the conversation forward. Those advances come, yes, through data, and testing, and prototyping, but the designer is there to give context to that data, and intuition will always have a role to play.

C. Todd: I think that’s where you get some of the breakthroughs, right? Data can tell you so much. Typically data is almost always backward looking, even if you think about machine learning and predictive analytics. They’re still relying on data from yesterday. That intuition piece is where you can say, “Well what if we did this instead?” That can be very divergent from what the data is telling you. It could also be really amazing.

Talin: You’ll know if you’re wrong. You’ll know if you’re wrong very quickly, sooner rather than later. I think that’s always the tension. That’s always the tension between even just design and art. I’ve always felt it’s the middle ground that leads to the best solution. It really leads to something lasting and impactful, coming somewhere in between. Taking the best from intuition, and taking the best of critical and analytical thinking, and connecting those dots and driving those dots is going to change the way people work, or create, or live.

C. Todd: Cool. Talin this has been awesome, really insightful. I have a lot of great stuff here to share with our readers. Thank you very much for spending some time with us.

Author C. Todd Lombardo

C. Todd brings his vast experience in design, innovation, and strategic thinking to craft smart, impactful solutions that radically transform our clients’ business strategies.

More posts from this author

How we work Process

Product Hero Talin Wadsworth