Explore a Workshop to Help Achieve the Highest Development Accuracy Utilising Strategic Touchpoints

Enhance Communication, Manage Expectations, & Strengthen Relationships to Drive Higher Output Quality & Efficiency

Introduction

Facilitating a collaborative workshop consisting of numerous sessions with existing or new development partners is an excellent way to manage expectations and expand relationships, communication, and touchpoints. This approach can achieve increased volume and better output quality.

Ultimately, to determine the key players, a workshop will clarify the end-to-end workflow and identify where teams overlap, such as creatives, product owners, business analysts, and developers.
Before executing the first session, make parties aware of the objective (an initial call). Each session will also measure engagement levels, ability, competency, and willingness to perform routine tasks, keeping the goal in sight. However, this is not an objective to share with your development partners.

During sessions, you may also discover something that isn’t evident in the design, such as the intended user flow or the interactive elements. Therefore, all design instances should be captured and shared with development partners to minimise room for assumption and error during the build.

What you’ll need

• Creative brief — this can be made up (smaller, the better).
• Low-fidelity wireframe — e.g., a card UI.
• Hi-fidelity design — consisting of elements and components via a design system.

Low-Fidelity Wireframe Review (Session 1)

Fig 1.1 — An example low-fidelity wireframe review with a development partner.

Objective

Identify technical requirements and critical aspects of the component structure. This session aims to outline the brief, discuss the solution’s skeleton (design at low fidelity), and review feasibility before proceeding with concepts. It allows development teams and business analysts to familiarise themselves with tickets lower in the creative backlog. If concerns are flagged, modifying designs at low fidelity is faster.

Preparation

Before the session, validate concepts with peers and get a sign-off from the product owner, who ensures the design aligns with the project’s goals and requirements.

Process

Creatives begin the session by walking through the solution in its current state. Development partners can then flag questions and queries concerning the design.

Expected Points of Discussion

• Content hierarchy
• Content structure
• Behaviours, interactions, and instances
• Technical requirements
• Elements and class identification
• Component-based structures
• Dynamic vs authored content
• Scalability (markets and languages)
• Design consistency across breakpoints
• Full page width or container width
• Fluidity (component scaling)
• Text responsiveness and wrapping scenarios
• Accessibility (e.g., navigation, heading hierarchy, logical content flow, forms)

Hi-fidelity Design Review (Session 2)

Fig 2.1— An example hi-fidelity design review with a development partner.

Objective

Analyse the hi-fidelity design and understand implementation scenarios. This session allows creatives to walk through the final surface layer of solutions, enabling BAs (Business Analysts) to begin capturing ACs (Acceptance Criteria). Development partners will also query any uncertainties.

Preparation

Before this session, ensure peer review and signed off by the product owner.

Expected Points of Discussion

• Elements and class identification
• Component-based structures
• Dynamic vs authored content
• Scalability (markets and languages)
• Design consistency across breakpoints
• Asset sharing (imagery, iconography, DAM integration)
• The broader context of the page for components
• “What-if” scenarios
• Signposting (e.g., text links, buttons)
• Accessibility (e.g., colour contrast, font sizes, responsive design)

Documentation Review (Session 3)

Objective

This session allows creatives to walk through the source of truth design documentation, enabling development partners to query any last uncertainties before the build.

Preparation

Before this session commences, design documentation must be peer-reviewed by a senior creative and a member of an accessibility team.

Expected Points of Discussion

• Input types (e.g., text fields, dropdowns)
• State definitions (e.g., none, hover, pressed, focused, visited)
• Markup and implementation guidance
• Accessibility (e.g., clickable areas, alt text, ARIA labels, tab order, screen reader flow, tables, global typography styles)

Conceptual Build (Session 4)

Fig 3.1 — An example conceptual build review with a development partner.

Objective

This exercise identifies the alignment of elements, attributes (margins, paddings), classes, frameworks, groupings of elements (containers), and properties. In this session, design and development teams collaborate to create a schematic illustration that explains the logic and high-level HTML and CSS/SCSS.

Preparation

To produce a conceptual build, trace it on top of the hi-fidelity design. Teams should align with the implementation approach before development, ensuring agreed strategies are visible during VQA (Visual Quality Assurance). Familiarise development partners with the tracing tool of choice before the exercise commences.

Potential Challenges

Developer Engagement

Understanding your team’s dynamics is crucial in gauging the level of engagement you can expect during workshops. Whether your team is internal or external, established relationships and existing assumptions or priorities can significantly influence their participation. External teams, for instance, may not feel as connected to the project, while internal teams might have preconceived notions that could limit their involvement.

To overcome this challenge:

If Remote

• Turn on cameras to create a sense of presence.
• Start with a fun, lighthearted icebreaker to make participants comfortable and more inclined to share.
• Use collaborative tools like Miro, Figma, or Mural to keep the session interactive and engaging.

If In-Person

• Foster a sense of inclusion by arranging seating in a circular or U-shape format to encourage open communication.
• Include tactile activities, such as using sticky notes or whiteboards, to make the session hands-on.

Both formats

• Clearly outline the purpose and expected outcomes of the workshop so participants see its value.
• Include developers early in the planning stages, making them feel their input is critical.
• Keep workshops concise and focused, respecting their time and workload.

After each session, seeking feedback from the working group is essential to understand what worked well and to improve engagement for future sessions. This commitment to continuous improvement enhances the workshop experience and fosters open communication.

Formal Build & Review (Session 5)

Fig 4.1 — An example of a formal build and review with a development partner.

Objective

Before this session starts, request development partners to produce a front-end build of the solution. The final session allows development teams to present to the creative team and walk through authored scenarios before VQA.

Process

Development teams should contact the creative team ad hoc during the build cycle for additional design uncertainties. Minimising the number of assumptions improves output quality and reduces time spent on VQA.

Expected Outcomes

The creative team reviews the build and flags change requests, striving for one-to-one parity with the design. Note: The VQA exercise is not an expectation as part of this session.

Summary

Increasing the number of design-developer touchpoints reduces the risk of assumptions, room for error, and poor output quality. Incorporating the sessions described into your day-to-day routine will create better relationships and set clear expectations for delivery, simplifying the technical understanding of the end-to-end creative process for business stakeholders. Lastly, each point of communication can act as a fallback and evidence if there is a failure of implementation or inaccuracy of builds.