Vulcan
From mission need to technical possibility.
- Client
- Cylitix / DoD (SOCOM)
- Role
- Product designer
- Duration
- 2 months
- Platform
- Web
Drawn from the original Focus Areas design: its own question, answers and routes.
Summary
A mission need is only the beginning. The call has to translate it into questions an innovator can answer, and evidence a government team can evaluate.
Product designer on the authoring side: how a program manager asks for the right information, and who can work on the call. Technical branching, structured costs and milestones, and controlled collaboration.
The platform
Connecting government needs with commercial innovation.
Vulcan is an innovation platform built for Cylitix with sponsorship from the Department of Defense. It modernizes the Broad Agency Announcement: how agencies like SOCOM issue calls for capabilities, and how commercial innovators respond with proposals and technical demonstrations.
Calls involve stakeholders across government organizations, and the responses span very different technical domains. The platform keeps them structured, searchable and evaluable.
From need to response
A call is written once and answered many ways.
A program manager authors the call. Each innovator answers along the route their technical focus sets. The government team scouts for matches and evaluates the responses.
Custom Questions
Access Controls
RecommendedSteps, questions and routes are named as in the original designs. The diagram simplifies the path between them.
Call authoring
Let the technical domain determine the next question.
A robotics submission and a communications submission need different follow-up questions. The form builder makes that logic part of the call: authors define the branches, require an answer and decide where each section goes next.
Machine Learning continues to ‘Machine Learning’, Robotics to ‘Robotics’. The route sits beside the answer it belongs to.
After section 1, the call continues to ‘Case Studies’. The sequence of questions is part of the call’s design.
Machine Learning asks which sub-domains a participant has experience with. Each of those answers carries a route too.
The author decides which answers a call cannot do without, at the question itself.
Steps with a problem carry a warning in the call’s outline, beside the steps that are complete.

Question types
Give costs and milestones their own structure.
ROM cost estimates, milestone timelines and technical questions need different inputs. Each question type carries its own validation, optional fields and explanatory context, so a submission keeps the detail evaluators need.


Design principle
The call’s structure should reflect the capability it is asking for.
Around the call
Who works on a call, and what it finds.
- Access
Make access part of authoring.
Program managers invite editors and set visibility inside the call workflow. Organization and active or invited states sit beside the content being prepared.

- Scout
Find the capability. See the context.
Innovations are matched to the call’s problem statement. Filter by technical category, browse best matches and recent submissions, then group or invite them.

Outcome
A complex call, without flattening every technical response into the same form.
- 01
Relevant questions
Technical focus determines the next section.
- 02
Structured evidence
Costs, milestones and technical detail have distinct inputs.
- 03
Clear responsibility
Editors and visibility are part of the call itself.
Credits
- Role
- Product designer
- Work
- Product design, search UX, information architecture, design system
- Client
- Cylitix, with sponsorship from the Department of Defense
- Worked with
- The Cylitix team and DoD stakeholders
- Duration
- 2 months
- Platform
- Web, designed in Figma
Project content in the screens is illustrative, as on the original case study. The route map and the camera moves are presentation built from the original designs.