Software Tool Power-User Review (Verified)

Proof required

Submit the named software tool and a link or file export of the tutorial project you reproduced, alongside a 100-word written description naming each intermediate feature you used and why it was necessary — not what the feature does, but why the tutorial required it at that specific step. A screen recording of you building the project is strongly encouraged but not required for this milestone.

What gets checked

• The tool is named and the exported project file or screenshot is identifiable as work in that specific tool — a written description without an artefact does not satisfy this milestone
• At least three features beyond the most basic are named in the written description with a brief explanation of why each was necessary — listing feature names alone without situational context does not demonstrate understanding
• The project is complete and functional in the tool's own terms — a Figma file where the component links are broken, or an Excel workbook where the formulas return errors, does not satisfy this milestone

Common mistakes

• Choosing an official 'getting started' tutorial that covers only the most basic features — for this milestone, the tutorial should require at least three intermediate features; if the official beginner tutorial does not, find an intermediate-level tutorial from the tool's official documentation or YouTube channel before starting
• Watching the tutorial video rather than building the project — the submitted artefact must be a working file you created; a screenshot of someone else's completed tutorial project is not a proof of building

Resources

What a verifier looks for

• Ask the submitter to open the submitted file during the review and navigate to the specific location where one of the intermediate features is used — someone who built the project can do this in under 30 seconds
• The 100-word description should name specific features with specific situational context, not paraphrase the feature's general description from the documentation
• For tools you are unfamiliar with, the presence of the artefact file and the submitter's ability to navigate it live is more reliable evidence than the written description alone

You'll sign in first, then come straight back here.

Proof required

Submit a screen recording (5-10 minutes) of you working on your original project in the tool — not a polished finished product presentation, but a working session showing you navigating the interface and using at least two advanced features. Alongside the recording, submit the exported project file or a shareable link, and a 150-word description of what you built and which advanced features you used and why.

What gets checked

• Screen recording shows you working in the tool in real time — not a screen capture of a completed export or a slideshow of screenshots; the recording must show the tool interface, menus, and your navigation choices
• At least two advanced features are visible in the recording — for Figma: advanced components with nested instances, interactive prototypes, or advanced auto layout; for Excel: array formulas, dynamic charts, or data validation with custom rules; for Premiere: multicam editing, speed ramps, or colour grading; the features must be visible in the recording
• The project is original — not a modified tutorial template; the 150-word description explains what you were trying to achieve, and the choices visible in the recording should match that stated goal

Common mistakes

• Choosing a project that only requires the intermediate features from M1 rather than advancing to genuinely advanced capabilities — the milestone requires features beyond the intermediate tutorial; if the tool has an official 'advanced features' page or tutorial series, the project should require at least two items from it
• Recording a polished walkthrough of a finished project rather than an authentic working session — a pre-choreographed demo of a finished file is not evidence of being able to use the tool independently; the recording should include moments of navigation, menu searching, and real-time decision-making

Resources

What a verifier looks for

• Watch 2-3 minutes of the screen recording — you should see authentic tool navigation (menus opened, panels adjusted, decisions made in real time) rather than a choreographed product demo
• Ask the submitter to explain one decision they made during the project that was not covered in any tutorial they followed — someone who worked independently can describe at least one such moment
• The advanced features visible in the recording should correspond to features listed on the tool's advanced documentation pages or tutorial playlists — if no advanced features are visible, the milestone has not been met

You'll sign in first, then come straight back here.

Proof required

Submit the screen recording of your capstone task (10-20 minutes) alongside a review report documenting: the reviewer's name and professional background with a verifiable link confirming they use this specific tool professionally, specific sections of the recording they commented on, at least two questions they asked about your tool choices or workflow decisions, and your written responses.

What gets checked

• Reviewer uses the submitted tool professionally — a graphic designer who uses Figma daily qualifies for a Figma review; the same designer does not qualify as a reviewer for a DaVinci Resolve or Excel submission; the tool must match the reviewer's domain
• Review documents at least two specific questions about workflow or tool choices — not general feedback about the output quality, but questions about why you chose a specific method: 'Why did you use VLOOKUP here instead of INDEX-MATCH?', 'Why is this component detached from the source?', 'Why did you cut here instead of using a J-cut?'
• Screen recording shows a non-trivial task completed from scratch — opening a blank file and building to a functional output, not editing an existing project or demonstrating features on a pre-built template

Common mistakes

• Asking a colleague who uses the tool casually (once a week, for simple tasks) rather than a genuine power user — casual users cannot ask meaningful follow-up questions about advanced workflow choices because they have not encountered those choices themselves
• Presenting a polished demonstration rather than a genuine working session — power-user reviewers immediately identify pre-choreographed tool demos; the recording should include normal working behaviour (backtracking, menu searching, adjustment) not a perfect linear walkthrough

Resources

What a verifier looks for

• Confirm the reviewer's professional use of the specific tool from their LinkedIn or portfolio — a UI designer's profile mentioning Figma, a financial analyst's description mentioning Excel modelling, or a video editor's portfolio showing commercial work confirms domain match
• The follow-up questions documented in the review report should be specific to tool usage, not output quality — 'this looks great' is not a follow-up question; 'why did you use a nested component here instead of a variant?' is
• Ask the submitter to describe one thing they would do differently in the workflow after the review — a genuine review conversation produces at least one actionable learning; 'nothing, the reviewer said it was perfect' is a red flag

You'll sign in first, then come straight back here.