Engineering in plain English
A product or a project? Compare the job before the tools
Compare an existing product, a connection between tools and a specific build using one recurring job, one essential rule and a plan for ongoing ownership.
THE WGMI JOURNAL
Better systems.
More room to grow.
Notes on better websites, connected systems, and the everyday work between them.
People and decisions
What can one interaction explain about your product?
Use a simple storyboard to decide whether a product idea needs an interactive sketch or a short video, with a fictional room planner example.
Engineering in plain English
Give your pilot a boundary before it starts
DOLFA's development plan opens a practical question for any proposed pilot: which workflow, people and test material are in scope, and when will you pause?
Engineering in plain English
Design the client view on purpose
A design choice in Taoro offers a practical way to choose what clients see, explain the next decision and inspect a project view before sharing it.
People and decisions
Who needs to be in the first project conversation?
Meet some of the people behind WGMI and use three questions to choose who should join an initial conversation about your next project.
People and decisions
Let your team lead the second run
Use one real task to turn a demonstration into practice, with the colleague at the controls and the specialist observing what needs to change.
Systems
Give every status a meaning your team can use
Define saved, reviewed and published through evidence, versions and ownership, using one documented WGMI Journal test as a bounded example.
Engineering in plain English
A second click needs a rule
Define what counts as a repeated request, what signals new intent and who checks an uncertain result. A filled rule note for an imagined repair process.
Engineering in plain English
One field, one owner: agree which record to trust
When two tools disagree, give your team a record to check and a person who can confirm the value. A practical note for one shared field.
Engineering in plain English
How to write a useful first project brief
Use a filled example to describe the problem, the users, your setup and the result you want, with clear limits and questions still to answer.
Engineering in plain English
Build around what already works
Define what stays, what changes and what your team needs at handover. A practical scope note for adding to an existing system.
Engineering in plain English
Before you call it done: the walkthrough to ask for
Before signing off a first release, ask for a walkthrough your team can repeat: the main task, what happens when it fails, and the handover that lets the team run it.