Digital Innovation Platform (DIP)

DIP served people proposing new ideas as well as people documenting requirements for existing work. That distinction mattered: an idea needed support and sponsorship, while a requirement described a need that another team could help solve.

The original intake experience treated different kinds of work too similarly. Fields repeated, guidance arrived too late, and people had little context for what a proposal was meant to accomplish. That made it harder to write useful submissions and easier for related work to become duplicated or disconnected.

I worked as Design Lead and Product Designer across information architecture, form structure, interaction design, and iterative stakeholder review. I focused the experience on three questions:

• What are you trying to submit?
• What information will help someone evaluate it?
• Is there already related work to join or build on?

• Make the first decision legible: idea or requirement.
• Teach people what a strong submission needs before asking for detail.
• Break a large intake into smaller, understandable steps.
• Surface related work early enough to reduce duplicate effort.
• Give submitters and reviewers clearer progress, ownership, and next actions.

Start with intent

The entry screen separates idea submissions from requirements and explains the difference before the user commits to a path.

Make the form teach

The proposal form uses a six-step progress model and a contextual tip so people can understand the shape of the work before they fill it out.

Break complexity into meaningful steps

Objectives, challenges, and attachments become separate parts of the overview instead of one long undifferentiated form. This keeps the main task visible while allowing people to add supporting detail progressively.

Protect the final decision

A review step lets people inspect the proposal before submitting. Completed sections are visible, and the user retains a clear opportunity to correct information before it moves forward.

Separate ideas from requirements

The platform should not force a proposed solution and an unmet need into the same intake pattern. The first choice establishes the language and expectations for the rest of the workflow.

Use progressive disclosure

Instead of showing every field at once, the flow introduces detail when it becomes relevant: introduction, uniqueness, objectives, technical specifications, additional details, and review.

Make collaboration visible

The broader Idea Space creates room for shared discovery across ideas, requirements, proposals, and bookmarks. The system is designed to support collaboration and reduce redundancy without relying on an unverified claim of measured duplicate reduction.

The strongest evidence is the shift in interaction model:

• a clearer first decision,
• a form that teaches before it asks,
• structured proposal sections,
• a review checkpoint before submission,
• and a shared space for discovering work across the organization.

These are design outcomes and intended behaviors; the project record does not include verified task-time, adoption, or duplication metrics.

• A complex form becomes more approachable when it explains its purpose before asking for detail.
• The distinction between an idea and a requirement is a product-model decision, not just a copy change.
• Review, status, and relationship cues help turn a form into a workflow.
• Responsible information capture needs to be explicit when proposals may include sensitive organizational context.

DIP became a clearer proposal-to-collaboration model: start with the right intent, guide the submission, review it before handoff, and make related work easier to discover. The result is a more credible path for Army personnel to move an idea or requirement toward shared evaluation and delivery.