DocForge

As our team's primary designer and developer, I focused on constructing the DocForge product and preparing a demo for the company pitch. The product would need to fulfill certain key goals:

1. Make documentation easier.
2. Make documentation faster.
3. Incentivize developers to document.
4. Prevent docs from becoming outdated.

Many of the challenges I faced stemed from the short timeframe our team was given to develop our business idea:

• Tight development and design time constraints
• Concurrent ideation, design, and development
• Coordinating different ideas and opinions

Our startup summer team looked at over 200 data points to determine what programmers despise about documentation. Several major recurring concerns we decided to address were:

• The time-consuming and difficult nature of documentation
• The tendency for documentation to become outdated as code changes
• Lack of willingness to document

I created simple wireframes based on the basic features our team decided DocForge should support:

• Semi-automatic documentation generation through VSCode (to make documentation easier and quicker)
• Manual documentation adding and editing through web app
• Nested documents and easy-to-access navigation hierarchy
• Feature creation
• Contribution tracking via Github and web app (to incentivize documentation by holding developers accountable in data)
• Connect everything to database and rest API
• Notifications in messaging apps to remind users to update outdated docs

Due to our pressing deadline, we later limited the product's development to items that would be displayed during the demo. We began actual development with a heavy front-end focus following a rough demo script:

1. Showcase tree hierarchy and features page
2. Create documentation via the VSCode extension
3. Show documentation update notification in Slack
4. Show editing documentation in web app
5. Show contributions page

See the DocForge preview:

Throughout the project, there was pressure to assemble a seemingly functional software product as quickly and efficiently as possible. By following the concept of creating a "minimum demoable product", our team could assemble a polished demo in time for pitch night.

Despite the incredible overall efficiency, our team could have spent more time before design/development to establish exactly what the product was or wasn't, what it did or did not do. Due to differring opinions, I had to correct certain misunderstandings represented either in the design or demo video. Still, by focusing only on what we would absolutely need to unveil, our team saved precious time to direct to other important business areas.