SPRY Portal
Streamlining Project Intake: Designing a Portal that Reduced Back-and-Forth and Increased Client Adoption

My Role
UI & UX Design
Industry
Marketing
Date
January 2023
Introduction
The SPRY Portal is a B2B web application designed to streamline how clients request and manage custom software projects. It replaces fragmented communication with a structured, guided experience, enabling faster onboarding, clearer requirements, and more efficient project execution.
Problem
WILY Global lacked a standardized way to intake project requests. This caused a few issues for our team.
PROBLEM 1
Lack of Details
Communications with clients never provided the full breadth of details for a project at one time. In order to gain more understanding, several calls and emails were usually needed to get a better picture.
PROBLEM 2
Expectation Misalignment
Misaligned expectations between clients and internal teams about scope, timelines, deliverables, and complexity, resulting in inaccurate estimates, last-minute changes, and friction during project execution.
PROBLEM 3
No Source of Truth
No centralized source of truth for project requirements, with information scattered across emails, documents, and conversations.

Defining the Problem
How might we create a standardized intake experience that captures complete project requirements upfront, aligns expectations between clients and internal teams, and establishes a single source of truth for execution?
Goals
BUSINESS GOALS
Standardize and streamline the project intake process
Create a consistent, structured way to collect complete requirements upfront, reducing manual follow-up and improving operational efficiency.
Improve scoping accuracy and scalability
Enable teams to produce reliable estimates, align expectations early, and support a growing volume of custom project requests.
USER GOALS
Provide a clear, guided way to submit project requests
Help non-technical users articulate their needs confidently without requiring prior knowledge of software development or project scoping.
Reduce uncertainty and communication friction
Minimize the need for repeated emails or calls by ensuring users understand what information is required and what happens next.
Impact
Adoption
The SPRY Platform became the primary channel for submitting custom project requests. 85% of our current clients migrated to it for submitting project requests.
Efficiency
Reduced back-and-forth needed to clarify requirements
Quality
Improved completeness and consistency of submitted project details
Business Impact
Enabled faster quoting and a scalable onboarding process, reducing time to generate project estimates by ~30% and improving onboarding efficiency for new clients
Users
Before we started designing, we took a look at how our users currently behave during the project request process by reviewing communications they’ve had with our customer-facing team. We also conducted a series of interviews with our customers.
We focused on identifying what job our customers are trying to complete.
With this, we defined 2 main user archetypes.

The Campaign Owner (Marketing Manager)
A non-technical marketer responsible for launching campaigns who needs a simple way to turn ideas into clear project requests without delays or confusion.
JOBS TO BE DONE
When I have a campaign idea, I want to easily submit a complete request so I can get an accurate quote and move forward quickly.
The Delivery Lead (Account Manager / Project Lead)
An internal team member responsible for scoping and delivering projects who needs structured, reliable information to plan work effectively.
JOBS TO BE DONE
When I receive a request, I want complete and consistent details so I can accurately scope, estimate, and execute the project without repeated clarification.
Constraints and Context
The solution needed to integrate seamlessly with existing internal workflows while supporting a wide range of project types with varying levels of complexity. Timelines were tight to accommodate upcoming client onboarding, requiring efficient decision-making throughout the design process. A key challenge was balancing simplicity for non-technical users with the level of detail required by internal teams to accurately scope and execute projects.
Current Experience
The intake process was entirely manual:
Clients submitted requests via email or meetings
Information was often incomplete or scattered across threads
Teams had to follow up multiple times to clarify scope
This created delays and inefficiencies before projects could even begin.

Research & Key Insights
Research Methods
To better understand the intake challenges, I used a combination of qualitative research and workflow analysis. I conducted stakeholder interviews with account managers and internal team members to uncover pain points in project scoping and handoff. I also analyzed past project requests to identify recurring patterns in incomplete, inconsistent, or unclear submissions. In parallel, I observed intake workflows end-to-end to understand how requests were received, clarified, and ultimately translated into actionable plans.
Key Insights
Clients lacked clarity on what information was required upfront. Many users were unsure how to structure their requests, leading to missing or inconsistent details.
Open-ended inputs resulted in vague submissions. Without guidance, requests varied widely in quality and often lacked the specificity needed for accurate scoping.
Internal teams relied on structured data, not conversations. Teams needed consistent, well-defined inputs to estimate and plan effectively, rather than piecing together information from multiple touchpoints.
Early friction discouraged complete submissions. If the process felt unclear or overwhelming, users were more likely to provide minimal details, increasing the need for follow-up.
User Flows
Based on user research and archetypes, I created a preliminary user flow in Figjam covering both sides of the experience: client onboarding and guided request submission, as well as internal review, iteration, and project scoping for accurate quoting.


Wire Frames
After mapping the user flows, I created low-fidelity wireframes to explore the structure and layout of the experience. This allowed me to quickly iterate on the flow of information, validate key interactions, and ensure the onboarding process was clear, intuitive, and aligned with both user and business needs.
Solution Overview
I designed a guided, multi-step request portal that helps clients translate high-level ideas into structured, actionable project requirements. By combining dynamic question logic with a clear step-by-step experience, the platform reduces ambiguity, aligns expectations, and enables internal teams to efficiently scope and quote custom projects.
SPRY Design System
I had the opportunity to build out a detailed design system for the SPRY portal using Figma. With this, I was able to maintain everything from iconography, fonts, colours and UI components. This helped me speed up the process of creating the UI and it allowed for an easy way to globally update components or elements that were being used all throughout the product.

Final Designs
Project Brief
Users begin by submitting a lightweight project brief that captures high-level goals and intent. This initial step is designed to be quick and accessible, providing the WILY team with enough context to understand the opportunity without overwhelming users upfront.

Project Details
Once initiated, users are guided through a structured, step-by-step flow to define key project details such as goals, features, timelines, and requirements. Breaking the process into manageable steps reduces cognitive load and ensures more complete and consistent inputs for accurate scoping.

Project Management
After submission, the platform transitions into a centralized workspace where users can track progress, review quotes, request changes, and complete required tasks. This creates a single source of truth for both clients and internal teams, improving transparency and reducing miscommunication throughout the project lifecycle.
Validation & Iteration
To validate the experience, I gathered feedback from internal stakeholders and reviewed how users interacted with early versions of the flow.
What didn’t work initially:
Users were unsure what level of detail was expected in certain steps
Some sections felt too long and overwhelming to complete in one pass
Lack of guidance led to inconsistent or incomplete responses
What I changed:
Added helper text, examples, and contextual prompts to guide users
Broke complex sections into smaller, more manageable steps
Refined question logic to better match user inputs and reduce unnecessary fields
Improved progress indicators to set clearer expectations throughout the flow
Results & Impact
The SPRY Portal became the primary method for submitting custom project requests, replacing fragmented communication with a structured and scalable intake process.
Key outcomes included:
Increased adoption of a centralized portal for project intake
Reduced back-and-forth communication needed to clarify requirements
Improved clarity, consistency, and completeness of project submissions
Enabled faster and more reliable project scoping and quoting
Aligned expectations between clients and internal teams earlier in the process
Established a scalable foundation for onboarding new clients and handling increased request volume




