Prototypes and wireframes do not need to be thought of independently. Wireframes represent a low fidelity design of a page and can vary from sketches to basic layouts with simple design elements. The goal with wireframes is to gather feedback and iterate on the functionality, like content placement, calls to action, etc. 

 

Prototyping is often thought of as a process used in the high fidelity design stages of a product development process, but it can, and should, be integrated earlier on, especially with user experience-based projects. Since a user’s experience with a product is reliant on the flow, or the journey through a product, it is important to test and design with that in mind. 

 

Prototyping in the wireframe or composite stage can help you develop the flow and understand how someone may move through the journey. Prototypes can be as simple as dissolves or basic transitions. As the wireframe moves into higher fidelity versions, the prototyping can become more advanced and true to life as well. 

 

 

I do believe there are many benefits to starting prototyping early, especially when testing the flow of a product experience. Designing screens in isolation without prototyping them together can leave blind spots. 

 

However, if prototyping in a low fidelity mode, keep the prototype simple as well. Trying to integrate advanced animations or interactions at the low fidelity stage can once again distract from what you’re trying to test, or make it more expensive to iterate at the early stages. 

 

 

Improved productivity comes with practice in the tool, learning hotkeys and getting a grasp on how things function. I would certainly recommend exploring tutorials for Adobe XD at adobe.com/learnxd to continue practising. 

 

With that said, some methods for increasing productivity are focused around reducing repetitive tasks. Leveraging Creative Cloud libraries and the document assets within an Adobe XD document can make it easier to apply text styles and colours, and quickly add graphics and other imagery that you’re using within the project. 

 

Components are another fantastic way of saving reusable elements like buttons, navigation and common elements into a reusable asset. These components can also store interaction within the component, so you can set up simple prototyping interactions on buttons, menu items, etc, and quickly reuse them without needing to set them up every time you want to use them in the design. 

 

 

If you have tooling that supports building responsive prototypes, that may be a good approach as long as the interactions remain consistent across various screen sizes. For web experiences, this is often the case. As part of testing, it can be valuable to see how the prototype changes across different screen sizes. 

 

Sometimes you may want to unlock features across different screen sizes, like gestures, or other interactions specific to the devices or platforms of that size, like mobile for example. In these cases it may be helpful to have independent flows with custom interactions for each major breakpoint (tablet, mobile, desktop). 

 

From a practicality standpoint, it may be best to have two key target screen sizes (depending on your product) and test the flows for both. 

 

 

Personally, I work across many different types of projects, from simple templates, to UI kits and full design projects. I leverage the built-in organization in the assets panel (Colours, Character Styles, Components) and then use subgroups in Adobe XD to further nest those elements. 

 

Colours I typically organize by how often I use them (dragging and dropping them to change the order) with the primary colours at the top of the stack. 

 

For character styles I will typically create subgroups and divide them by header styles, paragraph styles and then specialty text styles for tags, promotional information, etc. 

 

The components section is typically where I will do the most organization, as this section can be lengthy depending on the volume of components used in the project. I will typically subdivide with groups for icons, logos, navigation and then other components of the page. Depending on the project, I may further subdivide. For instance, with an e-commerce page design, I may have a subgroup for components related to the product sections. 

 

This doesn’t really change at all between design and prototyping, because I do them both side by side within Adobe XD. They’re not really separate processes. 

 

 

Device simulations can be really helpful, especially when you’re testing across many device types, as it lowers the cost (you don’t have to purchase all the devices), and gets you most of the way there. Simulations can help you get the page laid out and allows you to test the interactions, for the most part. 

 

I think it’s important to test on physical devices to truly validate the feel of gestures. Testing on a real device  can also help to get a good feel for the  sizing and proportions within the design, which can be lost when designing on a larger laptop or desktop screens.

 

Matt Rae is Product / UX Designer, writer and speaker... among other things. He currently spend his days training teams and community groups on Adobe XD workflows to enhance their productivity, while writing about best-practices for the Adobe XD Learn portal. Coming from a decade in product design, across industries including travel, autonomous vehicles, EdTech and advertising technology, he’s now focused on equipping designers with resources to design the best experiences using Adobe XD. He has a passion for user experience and developing the design community.