Frequently asked questions
Short answers about the book, the theory, and how to go deeper. If your question isn't here, email the author or post it in the discussion forum.
Why was the book written?
A decade of close study sits behind it. Certain apps feel effortless and capable while others fight their users at every step, and the book is an attempt to explain that gap with general principles rather than taste — principles extracted from examining well-known applications, feature by feature.
Is it a practical book?
Yes. The chapters are short, each grounded in software the reader already knows, and each ends in something you can apply. A second layer of independent explorations then goes deeper, tracing how concept design relates to neighboring ideas like data abstraction and design thinking.
Who is it for?
Anyone with a stake in how software behaves. That includes the people who build it directly, the people who shape it from product, design, and strategy roles, and the people who fund and advise it — as well as students, researchers, and curious users who simply want to see their everyday tools more clearly.
Is concept design only for software?
No. It began there, but a concept describes a course of action abstractly, without committing to any particular mechanism — so the actors can be people, machines, or AI agents. That makes the same method useful for designing software, agentic AI deployments, organizations, business processes, and policies. The method page walks through how.
Is a concept an object, an entity, or an idea?
None of the three. It isn’t a classification (a dog is not a concept here), a philosophical notion (neither is solipsism), or a data entity from a domain model (a Reservation record isn’t one either, though it may live inside a concept’s state). A concept is a behavior with a purpose. That’s also where it parts ways with object-oriented design: organizing functionality around domain objects welds unrelated activities to the same class, while organizing around activities and their purposes keeps them separable.
How does it sit with agile development?
It inverts one of agile’s articles of faith. Agile distrusts upfront design and treats code as the source of truth — sensible when code was expensive to write and cheap to change. With models generating code from explicit behavior, the design becomes the primary artifact where human effort belongs, and code becomes a translation of it, checked rather than handcrafted.
Where can I learn more?
Start with the book, or work through the free material: sample chapters, the ACM tech talk, the three stages of concept enlightenment, the tutorials, and a comprehensive summary. To join the conversation, visit the discussion forum.
Are workshops available?
Yes — teaching sessions and workshops of varying size and focus. Contact the author for details, or see how collaboration with the group works.
Will rude questions get answered?
Sure — there's a running collection on the book's site. And if your question isn't answered anywhere, email the author or post it in the forum.