Training – Elijah R. Young

Module 6: When Design Gets Skipped | Design-First Delivery

Alan Williams — Fri, 20 Feb 2026 14:20:46 +0000

Module 6: When Design Gets Skipped | Design-First Delivery | elijah.ai

Module 6: When Design Gets Skipped

Real Talk

What this module covers: What happens when you skip the steps in Modules 1–5. Not to scare you—to give you language when someone says "we don't have time for all that." The checklist doesn't slow you down. It keeps you from building something you'll have to tear down.

What You Get When You Skip Design

Real talk. When you skip these steps, you get:

Apps that solve the wrong problem (or no one's problem). You built something. It works. But the person who asked for it says "oh, that's not quite what I meant." Or worse: no one uses it because no one owned the outcome.
Flows that break because data boundaries or connectors weren't thought through. You built a flow that mixes SharePoint and Gmail. Your admin's DLP policy says no. Now you're refactoring—or the flow sits in limbo while you negotiate.
Rework when governance or compliance show up late. You shipped. It's in production. Then someone asks: "Who can see this data? Is it audit-ready?" You don't know. You're scrambling to add security and logging after the fact.
Pilots that never scale because no one owned the outcome. The pilot worked. Everyone loved the demo. But there's no owner. No rollout plan. No support model. Six months later it's orphaned and someone's asking "whatever happened to that thing?"

The "We Don't Have Time" Pushback

You'll hear it: "We need to move fast. Can't we just build it and figure out the rest later?"

Here's the thing. The modules don't add weeks. They add clarity. A 30-minute requirement capture session can save you 30 hours of rework. A 15-minute conversation about who owns the outcome can prevent a pilot from dying on the vine.

The checklist is a filter. It keeps you from saying yes to every request—and from building things that will haunt your backlog. When someone drops "we need an app for X" on your desk, you can say: "I'd love to help. Let's get an owner, a problem statement, and a baseline. Ten minutes. Then we'll know if we should build."

The Bottom Line

Low-code isn't failing because Power Platform is weak. It's failing because we skip the part where we figure out what we're actually building. You wouldn't pour a foundation without a blueprint. Same idea.

Use the modules. Use the checklist. Protect your time. Protect your credibility.

You're Done

You've worked through the Design-First Delivery series. Go build something that sticks.

← Back to index

← Index | ← Module 5 | Module 6

Module 5: Ready to Build (and Process Maps) | Design-First Delivery

Alan Williams — Fri, 20 Feb 2026 14:10:56 +0000

Module 5: Ready to Build (and Process Maps) | Design-First Delivery | elijah.ai

← Index | ← Module 4 | Module 5 | Module 6 Next →

Module 5: Ready to Build (and Process Maps)

Final Checklist Before You Open the Tool

What this module covers: If you've passed the phases in Modules 1–4, you're in good shape. This is the final pass—and a quick look at Process Maps in Power Apps Plans if you have access.

Final Checklist

Work through this before you open Power Apps or Power Automate. If any box stays unchecked, you're not ready. That's okay. Go back and close the gap.

From Module 1 (Pre-Build)

[ ] Problem statement, owner, and success measure are written down.

From Module 2 (Plan)

[ ] Project plan exists with scope, timebox, and stop conditions.

From Module 3 (Requirements)

[ ] Requirements (functional + non-functional) are captured and agreed.

From Module 4 (Design)

[ ] Data structure and app type are decided.
[ ] Security and access model are thought through.

Environment

[ ] You know which environment you're building in. Not the default, if you can help it. See Environment strategy. Dev, test, prod—or at least "where does this live and who can access it?"

All checked? You're ready to build.

Process Maps (Power Apps Plans)

Process Maps—the built-in visual workflow tool in Power Apps Plans—let you design the flow before you build. You create activities, decisions, and transitions. Share it with stakeholders. Get alignment. Then translate it into a flow or app. If you have access, it's worth using.

[ ] Create a process map for the workflow. Activities, decisions, transitions.
[ ] Share it with stakeholders. Get alignment before you translate it into a flow or app.
[ ] Use it as your spec when you build. See Process maps as part of your plan.

Don't have Process Maps? That's fine. A whiteboard sketch or Miro board works too. The point is: design before you build. The tool is optional; the discipline isn't.

What You Do Next

Open Power Apps or Power Automate. Build to your design. Test. Deploy. The Think like a Maker: Plan and deploy your Power App path walks through make, test, and deploy. You've done plan and design. Now you execute.

Before you go: read Module 6: When Design Gets Skipped. It's a short reality check on what happens when people skip these steps—and why the checklist protects your time.

← Index | ← Module 4 | Module 5 | Module 6 Next →

Module 4: Design the Solution | Design-First Delivery

Alan Williams — Fri, 20 Feb 2026 14:07:33 +0000

Module 4: Design the Solution | Design-First Delivery | elijah.ai

← Index | ← Module 3 | Module 4 | Module 5 Next →

Module 4: Design the Solution

The Blueprint

What this module covers: You've identified the problem and captured requirements. Now design the solution before you open the tool. Data structure, app type, and where logic lives matter more than you think. Get these right and building goes faster. Get them wrong and you'll rework.

Source: Design your app like a pro, Model data for Power Platform solutions (Microsoft Learn)

1. Design Your Data Structure

Where does data live?

Dataverse? SharePoint? SQL? Excel? Each has tradeoffs. Dataverse gives you relationships, security, and scale—but it's a commitment. SharePoint works for simpler lists and document-heavy scenarios. SQL when you need existing databases. See Model data for Power Platform solutions for the full decision tree.

[ ] You know where data lives (or will live).
[ ] You've thought about scale. How many rows? How often does it change? Who queries it?
[ ] You've thought about relationships. Do you need lookups between entities? Many-to-many?

Main entities and tables

Sketch or list what you need to track. A service request? A customer? An invoice line? What fields does each have? What connects to what?

[ ] You've sketched or listed the main entities/tables.
[ ] You've listed key fields for each. (Don't need to be exhaustive—enough to build.)

Data security

Who can see what? Least privilege by default. Don't give everyone access to everything and plan to lock it down later—that almost never happens.

[ ] You've thought about who can see what.
[ ] You've thought about who can create, edit, delete. Different roles?

2. Choose the Right App Type

Power Apps gives you choices. Each fits different scenarios. Pick before you build.

App type	When to use it	Notes
Canvas app	Custom UI, mobile-first, point solution. Forms, simple CRUD, field work.	Flexible. You design every screen. Good when the UI needs to look a specific way.
Model-driven app	Dataverse-based. Views, forms, and security are built in. Data model drives the UI.	Less design work. Good when the data structure is the main thing. Requires Dataverse.
Power Pages	External users. Public or partner-facing. Customer portals.	Different auth and hosting model. For when your users aren't in your tenant.

Rule of thumb: Consider a model-driven app unless your users have a specific need for a canvas app. Model-driven gets you up and running faster because the UI follows the data. Canvas gives you full control when you need it.

[ ] You've decided which app type fits. See Determine which type of app to make.

Where does logic live?

In the app? In a flow? In Dataverse (business rules, calculated columns)? This affects maintainability and where you'll debug when things break.

[ ] You've decided where logic lives. See App logic placement.

3. Security by Design

Don't bolt security on at the end. Think about it now.

[ ] Access model is defined. Who can see, create, edit, delete? Role-based? Group-based?
[ ] Data boundaries are clear. What data does this touch? PII? Financial? Regulated? Your admin will ask. Know the answer.
[ ] You've thought about connectors and DLP. Data Loss Prevention (DLP) policies group connectors into Business, Non-Business, and Blocked. Business and Non-Business can't mix in the same app or flow. Will your solution need connectors from different groups? That's a policy conversation with your Admin Lead.

Next Step

With your design in place, move to Module 5: Ready to Build (and Process Maps). That's the final checklist—and how to use Process Maps if you have them.

← Index | ← Module 3 | Module 4 | Module 5 Next →

Module 3: Capture Requirements | Design-First Delivery

Alan Williams — Fri, 20 Feb 2026 14:05:29 +0000

Module 3: Capture Requirements | Design-First Delivery | elijah.ai

← Index | ← Module 2 | Module 3 | Module 4 Next →

Module 3: Capture Requirements

What You're Actually Building

What this module covers: Requirements aren't bureaucracy. They're the guardrails that keep you from building the wrong thing—or building it in a way that breaks governance or security. Here's how to capture functional and non-functional requirements, run effective sessions, and get stakeholder sign-off.

Source: Work with requirements, Discover customer needs (Microsoft Learn)

Functional vs Non-Functional: What to Capture

It's useful to separate these. Functional = what the solution does. Non-functional = how it does it (performance, security, access, compliance). Both matter. Skip one and you'll hit surprises later.

Type	What to capture	Example
Functional	What the app or flow must do. Features. Behaviors.	"User can submit a request and see status within 24 hours." "Flow sends approval email when amount exceeds $500."
Non-functional	How it performs, who can access it, how it fits governance.	"Only HR can see PII." "Flow must complete within 5 minutes." "Must be audit-ready for SOC 2."

Leading a Requirement Capture Session

You don't need to be a professional facilitator. You need to ask good questions and write things down. Here's a simple structure.

Before the session

[ ] You've invited the right people. Business owner, key users, maybe someone from governance if you know it touches sensitive data.
[ ] You've sent a short agenda. "We're going to capture what this solution needs to do. Bring your questions and examples."
[ ] You have a place to capture. Doc, OneNote, whiteboard—whatever your org uses.

During the session

[ ] Start with the problem statement you wrote in Module 2. "We're solving X. Does that still sound right?"
[ ] Ask: "What must this do?" List every "must." Be specific. "User can submit" vs "User can submit a request with attachments and receive a confirmation within 5 seconds."
[ ] Ask: "Who can see what?" Access, privacy, compliance. This is where non-functional requirements show up.
[ ] Ask: "What would break if we didn't have this?" Helps prioritize.
[ ] Write it down in real time. Don't trust your memory. Read it back: "So I'm hearing that…"

After the session

[ ] Organize what you captured into functional and non-functional.
[ ] Send it back to the group. "Here's what I captured. Correct anything that's wrong. Add anything we missed."
[ ] Get confirmation before you start building. "We're building to this. Yes?"

Discovery Questions (If You're Stuck)

Sometimes stakeholders say "we just need an app" without specifics. These questions help:

Who does the first step today? What do they do? What do they need to see?
What happens when something goes wrong? Who gets notified? Who fixes it?
What data does this touch? Where does it live today? Who can access it?
What would "done" look like? How would you measure success?
Are there rules we have to follow? Compliance? Audit?

Requirement Capture Checklist

[ ] You've run at least one requirement capture session with stakeholders.
[ ] Functional requirements are documented. (What the solution does.)
[ ] Non-functional requirements are documented. (Security, performance, access, compliance.)
[ ] Requirements are confirmed and finalized with the business owner before build.

Next Step

With requirements in hand, move to Module 4: Design the Solution. That's where you decide data structure, app type, and where logic lives—all before you open the tool.

← Index | ← Module 2 | Module 3 | Module 4 Next →

Module 2: Plan Your Project

Alan Williams — Fri, 20 Feb 2026 13:55:15 +0000

Module 2: Plan Your Project | Design-First Delivery | elijah.ai

← Index | ← Module 1 | Module 2 | Module 3 Next →

Module 2: Plan Your Project

The "Why" and "Who"

What this module covers: Identify the problem, map the current process, optimize before you automate, and create a project plan. Professionals don't start building without answering these questions. The planning phase is the most critical step in the application lifecycle—get this wrong and everything downstream gets messy.

Source: Plan your project like a pro (Microsoft Learn)

1. Identify the Problem

What problem does this solve?

Be specific. "Make things easier" isn't enough. "Reduce invoice routing time from 3 days to same-day" is. The more concrete you are now, the less you'll rework later.

[ ] You've written a specific problem statement.
[ ] It includes what's wrong today and what better looks like.

Who uses the current process?

Who's doing the work today? Who will use the app or flow? Don't assume—verify. Sometimes the person you think is the user is actually the requester, and the real user is someone downstream.

[ ] You've listed who does the work today.
[ ] You've listed who will use the solution (they might be different).
[ ] You've talked to at least one actual user.

What does the current process look like?

Walk through it once. Where are the bottlenecks? Where do people get stuck? Where do they copy-paste between systems? These are your automation opportunities.

[ ] You've walked the process (or watched someone do it).
[ ] You've noted bottlenecks and pain points.

2. Optimize Before You Automate

This one catches a lot of people. Sometimes the answer isn't "automate more"—it's "fix the process first" or "fix the data first." Automating a broken process just makes the mess move faster.

[ ] You've mapped or sketched the current process. (Even a whiteboard photo counts. Sticky notes on a wall. Whatever works.)
[ ] You've asked: What would we change if we had no automation? Sometimes the answer is "reorganize the team" or "get the data in one place first."
[ ] You've identified automation opportunities—steps that are repetitive, rule-based, or high-volume. See Example: Identify automation opportunities.

Automation opportunities to look for: Manual data entry, copy-paste between systems, approval workflows that are pure routing, status updates, report generation, reminders, lookups based on rules.

3. Create a Project Plan

Doesn't need to be fancy. It needs to exist. Scope, owner, timeline, and a rough success measure. That's enough to keep most projects from drifting into the pilot graveyard.

[ ] Project plan exists. Scope, owner, timeline, success measure.
[ ] Timebox the pilot. "We'll run this for 6 weeks and then decide." Avoid endless scope creep.
[ ] Stop conditions are defined. What would make you pause or kill this? Write it down. "If we don't see 50% adoption in 4 weeks, we pause." "If the business owner leaves, we stop."

Element	What to capture
Scope	What's in. What's out. What's phase 2.
Owner	Named business owner. One person.
Timeline	Pilot duration. Key milestones.
Success measure	Baseline + target. How you'll know it worked.
Stop conditions	What would make you pause or end the pilot?

Next Step

With your plan in place, move to Module 3: Capture Requirements. That's where you turn "what we want" into "what we're building"—with functional and non-functional requirements that stick.

← Index | ← Module 1 | Module 2 | Module 3 Next →

Module 1: Pre-Build Readiness | Design-First Delivery

Alan Williams — Fri, 20 Feb 2026 13:44:34 +0000

Module 1: Pre-Build Readiness | Design-First Delivery | elijah.ai

← Index | Module 1 | Module 2 Next →

Module 1: Pre-Build Readiness

Before You Open Power Apps

What this module covers: Four things you must have in place before you touch the tool. If you can't check these, you're not ready to build. That's not gatekeeping—it's protecting your time and your stakeholders' trust.

Time: 10–15 minutes to work through.

The Four Readiness Checks

Think of these as the minimum viable clarity. Without them, you'll build something, show it to someone, and hear: "Oh, that's not quite what we meant." Or worse: you'll finish and realize no one owns the outcome.

1. Who feels the pain—and how often?

Not "the department." A person or role. Someone who wakes up and deals with this problem regularly.

[ ] You can name the primary user or role. (E.g., "Accounts payable clerks" or "Sarah in HR.")
[ ] You know how often they hit this pain. Daily? Weekly? Monthly? Volume matters when you're deciding if automation is worth it.
[ ] You've talked to at least one of them. (Even a quick call. Don't assume.)

2. What's broken today—in plain language

"Make things easier" isn't enough. You need a problem statement that a non-technical stakeholder could repeat back to you.

[ ] You've written down what's broken in one paragraph.
[ ] It's in plain language. No jargon. "Invoice routing takes 3 days because we're emailing PDFs and someone has to manually key them in" beats "We need better process optimization."

Example (good): "Field technicians spend 30 minutes at the end of each day filling out paper forms and then re-entering the same data in the ERP. We lose time and we get transcription errors."

Example (not enough): "Our field operations need to be more efficient."

3. Someone owns the outcome

A named business owner. Not a committee. Not "the team." One person who is accountable for the KPI and adoption.

[ ] You have a named owner.
[ ] That person has agreed they own it. (Don't assume. Ask.)
[ ] You know what happens if adoption fails—who gets the uncomfortable conversation.

4. What does success look like?

A rough idea. You don't need a full dashboard on day one. You need something measurable.

[ ] You have a success measure. Cycle time? Error rate? Hours saved? Requests processed?
[ ] You have a before (or can get it). What's the baseline today?
[ ] You know what "better" means. (E.g., "Same-day invoice routing" or "90% reduction in data entry errors.")

Why This Matters

These four checks prevent the most common failure mode: building something impressive that nobody owns and nobody uses. They also give you a way to say "not yet" when someone drops a vague request on your desk. "I'd love to help—once we have an owner and a baseline. Can you grab those and we'll pick this up?"

Next Step

Once you've checked all four, move to Module 2: Plan Your Project. That's where you get into the nitty-gritty of mapping the current process and creating a project plan.

← Index | Module 1 | Module 2 Next →

Design-First Delivery: Module Index

Alan Williams — Fri, 20 Feb 2026 13:36:05 +0000

Design-First Delivery: Module Index | elijah.ai

Design-First Delivery: Module Index

Why this exists: Low-code isn't failing because the platform is weak. It's failing because we skip the part where we figure out what we're actually building. You wouldn't pour a foundation without a blueprint. Same idea.

For you if: You're a Delivery Lead, Admin Lead, or maker who's tired of solutions that collapse under their own weight. Or you're about to start something new and want to do it right.

How to use this: Work through the modules in order. Each one builds on the last. You can also jump to a specific phase if you're already partway through.

Modules

Module 1
Pre-Build Readiness: Before You Open Power Apps
Four things you must have in place before you touch the tool. If you can't check these, you're not ready.
Module 2
Plan Your Project: The "Why" and "Who"
Identify the problem, map the current process, optimize before you automate, and create a project plan.
Module 3
Capture Requirements: What You're Actually Building
Functional vs non-functional requirements, how to run capture sessions, and getting stakeholder sign-off.
Module 4
Design the Solution: The Blueprint
Data structure, app type, where logic lives, and security by design. All before you open Power Apps.
Module 5
Ready to Build (and Process Maps)
Final checklist before you build. Plus: how to use Process Maps in Power Apps Plans if you have them.
Module 6
When Design Gets Skipped
Real talk on what happens when you skip these steps—and why the checklist protects your time.