Screenshot of three Tugboat Previews showing three different active projects

At first glance, deploy previews or git pull request environments sound like technical tools that only benefit development and engineering teams. In reality, though, these tools are fantastic for UI and UX designers. They enable tighter collaboration with engineering, earlier and easier usability testing, and a great way to share work with stakeholders. Find out why deploy previews should be a tool in every design team’s toolbox.

Git pull request builder benefits for UI and UX designers

As a UI/UX designer, the core benefits of a git pull request builder primarily relate to providing visibility into how developers are implementing your designs. With a working version of a website for every pull request, design teams can:

  • Review front-end development work.
  • Share working website previews with stakeholders.
  • Collaborate more effectively across teams.
  • Conduct usability testing earlier with on-demand deploy previews.
  • Review design implementation and conduct usability testing without disruption.

Review front-end development work.

Reviewing front-end development work isn’t always a simple task for UI and UX design teams. In some cases, they may see a “demo” at a scrum where a developer or QA team is “driving” a version of the code from a local development environment. However, the design team may not get to play with code in action for the first time before it’s deployed to a staging server, at which point it may be late in the development process to make changes.

With an ephemeral staging environment automatically created for every pull request, UI and UX designers can easily review a working version of the website or web app from very early in the development process. When a front-end developer opens a work-in-progress pull request, a git pull request builder deploys a version of that work to an ephemeral environment. Designers who visit the URL can actually use the first iterations of a website or web app - without needing to have a local development environment. This makes it easy to provide fast, actionable feedback.

Compare your Figma file with a functional version of the web app or website design - weeks or months before you might otherwise see the work on a staging server. Step through a user flow in action as a working website prototype. Deploy previews enable design teams to sidestep of the complexities of maintaining a local development environment, and the delays of waiting for engineering to deploy work to a staging environment.

Share working website previews with stakeholders.

Designers and front-end developers are natural collaborators, but they’re typically working with additional stakeholders, such as product team members, managers, or clients. In many cases, it’s neither feasible nor expected for these stakeholders to have access to the git repository where the code lives, so they may not get a chance to review and weigh in until code is deployed to a staging or UAT server. This can be weeks or months into the development process.

Delays in sharing work with stakeholders contribute to lack of trust, lack of visibility into progress, and potential problems at demo time if it’s the first time stakeholders are viewing work.

With a git pull request builder, ephemeral environments can be shared with stakeholders for a given pull request, regardless of whether it’s on staging, UAT, or a public-facing server. Invite stakeholders to experience and provide feedback on work earlier in the web development process. This creates a much better experience for stakeholders and design team members, and enables moments of delight that turn stakeholder reviews into something that everyone enjoys.

Collaborate more effectively across teams.

When UI and UX designers get working prototypes of a design’s implementation for the first time quite late in the development process, this can create problems and friction across an organization. In some organizations, design teams might see working versions of the website for the first time on the eve of a planned release, resulting in late nights while front-end developers and designers collaborate to resolve issues. In other cases, ineffective collaboration processes result in poorly-implemented or incomplete design implementations being rushed into production, with a vague hope of going back to fix it someday.

With a git pull request builder, designers can have insight into how their designs are being implemented from the earliest moments in the development process. This makes iterating together with engineering teams and stakeholders simple and seamless, and reduces rework by ensuring design and development teams are aligned throughout the development process.

Conduct usability testing earlier with on-demand deploy previews.

Usability testing is an important step in the design process, but it’s typically not possible to conduct usability testing until a website or web app is feature-complete and deployed to a staging or UAT environment. With on-demand deploy previews, design teams can start usability testing with a minimum viable product or a product prototype right away.

Jenna Tollerson, Engineering Lead at Digital Services Georgia, said in our recent case study:

“When I prototype new features for stakeholders, Tugboat allows me to present the idea on a working site, and gather feedback asynchronously.”

Imagine being able to conduct usability testing from a prototype early in the development process, and being able to iterate and make changes to the design along the way - versus getting a fully feature-complete implementation after weeks or months of development, only to find substantial rework is required due to a usability issue. When design teams can see the product and conduct usability testing from the beginning, UI and UX designers can make refinements and validate the design’s usability along the way. Design teams can create a better, more usable finished product.

Review design implementation and conduct usability testing without disruption.

Tugboat dashboard showing three copies of a deploy preview for concurrent usability testing
Multiple copies of a deploy preview enable simultaneous usability testing without disruption

Resource contention for a limited number of staging or UAT environments can become a design and usability testing bottleneck. What happens if design teams want to conduct multiple usability tests on the same day, or if another team needs to use the staging environment and blows away the carefully constructed environment?

Tugboat offers features to help ensure UI and UX designers get the deploy previews they need to do their work, without fighting with other teams for limited environmental resources. Take advantage of features like:

  • Cloning a Preview to instantly create duplicate copies of a website or web app deploy preview. Need to conduct three usability tests on the same day? Clone the Preview three times, and you’ll have all the duplicate website previews you need.
  • Resetting a Preview to return it to a pristine build state. Do your usability tests involve creating data and manipulating content in the deploy preview? Select Reset after the usability test is complete, and Tugboat restores the database and website to its fresh build state.
  • Locking a Preview to ensure ongoing development work doesn’t disrupt your review and usability testing. When you Lock a Preview, it won’t get automatic updates when developers make new commits, and it won’t overwrite the database with any automatic refreshes overnight.

Coming soon: deploy preview benefits for DevOps and IT teams

Now you’ve got a better idea of how git pull request builders benefit UI and UX designers by making it easier to review front-end development work, to collaborate across teams, and to conduct usability testing or share work with stakeholders without disruptions. In our next article in the series, we’ll look at how deploy previews benefit DevOps and IT teams through time, cost, and maintenance savings!