At most one email a week. Unfollow anytime with one click.
Transcript
The full narration of this video. The current sentence is highlighted while the video plays; click any sentence to jump there.
Show transcript
Introduction
Hi, and welcome to the closing practice episode of the Intermediate Artifacts session. We've built a dashboard, a quiz, a calculator, a form, and diagrams. Now we put them all together. In this episode we build a mini app to use with your team, from writing a specification and testing it with the team, all the way to launching and maintaining it.
Step 1: Define the problem and users
The first step is defining the problem. This is the Maju Bersama Co. operations group every morning. Bayu asks whether the Sinar store order has gone out, because the store keeps asking. Then someone asks who the courier for Makmur Store is today. Wulan has made the invoice, but doesn't know whether the goods are still in the warehouse or already on their way. And once again Dewi has to check them one by one. The problem is clear: not everyone can see the delivery status, so Dewi becomes the go-between for every question. After asking her team, Dewi writes a specification, which is a list of what the app needs. The goal fits in one sentence: everyone can see today's delivery status without asking in the group. The users are named one by one, with one important detail: the app is opened on phones, because the couriers and Andi are rarely at a computer. The data comes from the daily delivery spreadsheet: store name, goods, courier, and status. Phone numbers are deliberately left out. The format combines things we've already learned: summary cards, a table, a filter, and a button to copy a report. The constraints: simple, large text, no personal data, and the spreadsheet stays the main data source. We'll see why that last constraint matters in step four.
Step 2: Build the first version
Step two is building the first version. Dewi sends the specification along with today's sample data, and deliberately asks for a simple version first. Claude reads today's delivery file. The first version appears. At the top are four cards: eight deliveries, three being prepared, four shipped, and one received. Below them is a table with the store, goods, courier, and status. Notice what Claude said: the filter and report button come after the basic layout is approved. Building in stages like this makes mistakes easier to spot. Dewi checks three things: the layout matches the specification, the numbers on the cards match the table, and everything is readable on a phone screen. All three pass, so this version is ready for the team to try. There are a few principles for a first version. First, only include features that serve the main goal. For Dewi, that means the delivery status is clearly visible. Second, use real sample data from daily work, not made-up data. Layout problems often only show up with real data, such as long store names. Third, check the layout directly on a phone, because that's where the team will use it. What to avoid: asking for every feature in one long prompt. The result is hard to check, and if something goes wrong, the cause is hard to find.
Step 3: Test with the team and revise
Step three is testing with the team. Dewi asks Andi, Bayu, Wulan, and the courier Eko to use the first version for one working day, then note down their feedback. The feedback varies: Eko wants to see only his deliveries, Andi wants a change-status button, Bayu wants colors, and Wulan wants a monthly chart. Dewi asks which ones should go into version two. Claude weighs them against the goal in the specification. The first three directly help people see today's status. Wulan's monthly chart is useful, but its goal is different, so it fits better as a separate dashboard. This is where the specification earns its keep. Without a written goal, a mini app easily bloats with features nobody uses. Dewi asks for version two with the three chosen requests. Version two appears. The example in the panel uses the courier filter for Eko, so only his three deliveries are shown. Status now has colors: yellow for preparing, blue for shipped, and green for received. Below the table are buttons to mark an order as shipped or received, just as Andi asked. Dewi sends this version to the team to try for one more day, before launching it for everyone.
Step 4: Handle data safely
Step four is handling data safely. The key question: which data is stored where? The daily delivery list stays in the team spreadsheet, because a spreadsheet keeps a history of changes. The Artifact is used for the status view and the filter, so everyone can read it easily on a phone. Store phone numbers and addresses stay in the office's internal system. Sensitive data like this doesn't go into the mini app. The daily report is copied into the team group chat as an archive you can search later. Why does the spreadsheet stay the main source? Because Artifacts' ability to store and share data keeps evolving. Check the official Claude documentation for the latest features, and don't rely on one place you don't yet understand for important data. Before sharing, Dewi checks four things. First, there are no phone numbers, home addresses, or passwords in the app or its data. Second, there's only the data needed for the app's goal. Invoice amounts, for example, don't need to appear on the courier's screen. Third, the link is shared in the team group, not posted on social media or in a public group. Fourth, one person is responsible for updates. At Maju Bersama Co., that's Bayu's job every morning. The same pattern works for other teams. Laras can build a daily stock board for Dimas and the baristas, and Mr. Hendra can build a classroom schedule for the Cerdas Tutoring teachers.
Step 5: Launch and maintain
The last step is launching and maintaining. Before the launch, Dewi adds one more feature: a button to copy a daily report and send it to the group at four every afternoon. Version three shows the afternoon summary: six of eight deliveries received, two still on the road. Below it are the stores that haven't received their goods yet and the follow-up for tomorrow morning. This report replaces a dozen questions in the group. One copy, and everyone knows how the day went. For the launch, Claude helps write a short email to the team. In the inbox, Bayu has already reported that today's delivery data is filled in. The email explains three things: how to use the app, who updates the data, and who to contact if there's a problem. The last sentence matters: we'll review it together in two weeks. A launch isn't the end; it's the start of the next round of improvements. Let's sum up the cycle. First, start from one real daily problem. Second, write a specification with the goal, users, data, and constraints. Third, build a simple version first, with real data. Fourth, test with the team and choose feedback based on the goal. Fifth, launch with a short explanation, then review regularly. Two weeks later, status questions in the Maju Bersama Co. group have dropped sharply. Try this cycle with your own team.
Done!
We've closed the Intermediate Artifacts session with a complete practice: defining the problem, writing a specification, building the first version, testing with the team, handling data safely, then launching and maintaining a mini app. In the next episode we start the Research with Claude session with web search: Claude looks up the latest information itself and includes its sources. See you there!
Practice exercises
Try these on your own after watching to lock in what you learned.
Write a specification for your team's mini app: goal, users, data, features, and constraints
Build the first version and ask two team members to try it for one day
Write down all the feedback, pick the three most important points, then build version two
Ask the class material
Type a question or keyword; we find the part of this episode that explains it and jump the video there.
My notes
Notes are saved with the current video time and are only visible to you.
Questions & answers
Stuck on a step? Ask here; the instructor and other learners can answer.
No questions yet.
Your instructor
Cerdas Inovasi Digital Team
Software developers, BIM & 3D engineers, and AI practitioners
53 video classes1,281 episodes
We build software, BIM models, games and AI automations for clients every day, and turn that hands-on work into step-by-step classes: every step is shown on screen and comes with a PDF guide you can keep.
