An Interview with Tom Krcha, Adobe XD Product Manager
A few weeks ago Adobe released the first public preview of what the company is now calling Adobe XD, its major new UX/UI design and prototyping tool—you can download it here. This early version is missing several key features, and a long road to the full 1.0 launch lays ahead. Nevertheless, the preview is workable enough that professional designers can begin to see firsthand whether the app can deliver on the innovation that has been such an integral part of its promise. This milestone seemed like the right moment for me to interview Tom Krcha, a key member of the product team who has been with the project since the very beginning, before it was even called Project Comet. I asked him to reflect on how XD first came to life, what it took to get it to this release, and the long-term vision that is guiding him and the team.
Full disclosure: Since August of last year I have been an Adobe employee. As with all of my posts, this interview was not submitted to management for approval.
Khoi Vinh: Let’s start at the beginning. How did XD first come to be?
Tom Krcha: It started around mid-2014. I was working with the Behance team on some new apps, and we were prototyping new ideas all the time for them, using many different tools to do that. None of them seemed to be ideal. They lacked continuity; the ability to let you jump from an idea into a design and then mock up a quick prototype that could be easily shared—that seemed so obvious, but very distant from the reality back then. I wanted to speed up the way we iterate and communicate our ideas.
So I collected a bunch of the thoughts into a slide deck—a very quick mood board, nothing polished—and shared it with some people I knew around the company, just to see what others thought of it. Some of the ideas were around constraint-based adaptive layout, reusability, in-context editing, fast but precise vector UI and icon drawing and so on.
I quickly discovered that other folks at the company were thinking about similar things as well and in fact there was a lot of passion for this topic. We all met together and soon after assembled a small team of people, like a startup, with a mission to explore and re-think current UI/UX design workflow—if we could imagine anything and start with a blank canvas, with no limits. The whole process was really exciting.
I want to hear more about that process but first: by mid-2014 Sketch had already gained tons of traction, and the market for design tools had become quite robust. I have to imagine you and your colleagues were watching the market, right?
It’s true that there were a lot of design tools out there. But when we stepped back and took a broader view of the market, it seemed like there were a lot of opportunities to rethink traditional tooling. Demand for mobile apps had exploded. App design had matured and became more functional, and had moved towards flat design, which I think was an important break point. Designers started to think more about products and less about graphics. And motion and interaction started to play a much bigger role in app design. It was clear that we had entered a new era of designing products.
However we knew that building a new tool would take some time. It just doesn’t happen overnight. So I think everyone was less worried about what was happening at that moment and thinking further ahead. The thinking was to leapfrog the current generation of tools and jump to the future. To build an electric car of design tooling.
So do you believe most of the UX and UI design tools that debuted over the past two or three years are too focused on the “today” of the craft, and not enough on the tomorrow?
Yes. There is so much more that designers would love to have to simplify and speed up their process. Designing at the speed of thought is where we are all heading.
Getting to “speed of thought” tools requires negotiating the tradeoffs between ease of use and high fidelity—a WYSIWYG interface versus a code-intensive interface, is that right? How did you strike the right balance for XD?
That’s right; high fidelity and ease of use often go against each other. When we first started working on XD, we knew that we wanted to build a tool for any designer to pick up and start using right away, and to be able to use day to day. We decided to squarely focus on the design side and not on the development side of things, and also to stay platform agnostic. We talked to many designers—many advanced designers, but also emerging designers who haven’t necessarily adopted any given tools and who are just starting to look around, which is great, because they are less anchored to specific solutions. We learned that no matter what skill level they are, they want to start quickly and move fast. One of our core principles has been “comfort first,” meaning that the tool shouldn’t get in your way; it should be very straightforward. It should almost feel invisible, performance included.
What are some examples of those “comfort first” decisions you made?
There are many. The contextual property inspector shows you just what you need when you need it. We have recent files and UI kits available on the welcome screen for immediate use, so you don’t have to hunt for them. One of my favorites is ghosting. Whenever you have an object, let’s say a photo, that gets clipped by an artboard, we display the clipped part ghosted with opacity to help designers work easily with the full object context. This applies to the Boolean operations and soon to the masking as well. Another example is the distance decorations/guides where we combined snaplines and distance measurements together to minimize distractions. Some of these things are subtle, but when you experience them they feel so obvious.
If I’m a new user, what should I expect from the first time (or first few times) I use Adobe XD? Will that comfort be obvious to me right away, or is there a learning curve?
We tried to minimize the need for learning. The basics, such as drawing and layout, should feel familiar from first launch. There are definitely features that users need to learn about, but they will feel natural after using them one or two times. For instance you can drag an image from your computer directly into a shape in order to mask it—no need to actually tell the app to mask the image to the shape. It’s such a logical thing to do but I haven’t seen other tools do this.
We’re coming up with a set of heuristics like this that will make sense to everyone. One example is if you duplicate an object multiple times. We know that and we can show a contextual hint that says “[⌘R] Turn into Repeat Grid”, which might actually take the already duplicated objects and create a repeat grid for you quickly. Another place where it comes handy is the path editing, since there are many operations you can do on points with different key modifiers or gestures.
We’re still building the proper onboarding experience, and that’s a big part of the learning. We know that many users won’t read or watch long tutorials, but maybe there are more contextual methods of helping them learn about things that’s right within the tool. So you’ll see contextual hints that provide just enough guidance by showing you shortcuts for commands related to the currently selected object. Of course this will only be useful if it’s valuable enough and very subtle that it doesn’t interrupt the design process.
How much are you finding that the XD beta testers are struggling with the biases and preconceptions that they might bring with them from other tools?
Ha, yes. There is definitely one that I am constantly fighting with: the zoom tool. Our zoom has this Mac or iOS native feel. Pinch-to-zoom to a specific area on the trackpad or option and scroll on the mouse. It’s a buttery smooth zoom and I’m sure users will love it.
However, from the feedback we’ve learned that users are struggling to find the actual legacy zoom tool—the rectangle/marquee zoom. I definitely see a use case for that but pinch, in my opinion, has a much more natural feel. We’ll eventually support all the use cases, but it’s one of those things that I wish we could just skip.
In general though, how open to change are you finding the beta users?
I think lot of that goes back to onboarding actually. If the intention comes across clearly then it’s easy. However, we sometimes get a lot of feedback on certain things. That’s actually great. It’s exactly why we decided to start a dialog with users early on. First to really see if certain ideas are just crazy or just cool but are really edge cases, or if they will resonate well and speed up the workflows significantly. Sure, you still have to trust your expertise and gut, when making decisions, but having usage data and qualitative research helps a lot to settle on a decision. Either way, innovation is hard, especially when you are fighting expectations that are often not clearly articulated—because “it used to always be like that.” I think we can do so much better in areas such as symbols, styles and layers and not just take what’s out there.
Read the rest here.