Library / Technology / KEVOS® original book
Engineering Tools People Use
Designing in-house engineering software so designers enter the right inputs, read results correctly and keep using it
Design in-house engineering tools people use correctly: observe users, design inputs and results, write messages, fit the workflow, test with five users and measure use.
Start readingAbout this book
Engineering firms are full of small tools written by engineers for engineers: a spreadsheet that sizes a beam, a CAD add-in that checks a drawing, a calculator for bolt preload or a tolerance stack. Most are technically correct. Many are used wrongly, worked around or quietly abandoned, because the person who wrote them understood every input and every result, and the people who use them do not. An input that one engineer reads as a total tolerance band, another reads as plus-or-minus. A result shown to five decimal places looks precise and says nothing about whether the design passes. An error message written for the author makes sense only to the author.
This book is for engineers, CAD administrators and developers who build tools for colleagues. It shows how to watch people use a tool, design inputs that prevent errors, present results that support the right decision, write messages and help that work, fit the tool into the way people already work, test it with a handful of real users, make it accessible and consistent, and measure its use. Each chapter works one decision through the running case with real numbers and ends with an exercise and its worked answer.
The running case
The book follows a fictional machine builder’s design office of 14 designers and an in-house tolerance stack-up tool, written by a senior engineer five years ago. It calculates worst-case and statistical (root-sum-square) stacks for linear chains of dimensions. Designers use it for gearbox, bearing and housing assemblies. The tool works, but the office suspects it is misused: two field problems in a year traced back to stacks that the tool passed.
All quantities, times, results and names of fictional products are invented for teaching. This is an illustration. None of it describes a KEVOS® project or product.
How to use the book
Read Chapter 1 first, because the observation method it describes is the source of almost every improvement in the rest of the book. The other chapters can be read in any order. The companion books CAD Automation by the Numbers and Engineering Software You Can Sell cover building, deploying and selling tools; this book covers making them usable.
Source limits and professional responsibility
A 2009 book on CAD add-in development was supplied for this series. It informed only this book’s attention to menus, property pages and planning an interface before coding. The structure, case, calculations and figures here are original. Usability findings from published research are attributed and paraphrased.
This book is educational. A clearer tool reduces errors but does not remove the engineer’s responsibility for the design. Tools that support safety-related or regulated decisions need verification, review and approval appropriate to those decisions, whatever their interface.
Who this book is for
Engineers, CAD administrators and developers who build calculators, add-ins and small tools for colleagues and want them used correctly rather than worked around or abandoned.
What you will learn
- Observe how colleagues really use a tool and find where inputs and results are misread.
- Design inputs with units, ranges and conventions that prevent the commonest errors.
- Present engineering results so the decision they support is clear and hard to misread.
- Test a tool with small rounds of real users and fix what they find before release.
- Make tools accessible and consistent, and measure their use and error rates over time.
Inside this book
Chapters
- 01Watch people use the toolFind out how colleagues really use an engineering tool by watching them do real tasks, recording time, errors and workarounds, and tracing field problems back to the interface.
- 02Design inputs that prevent errorsReplace ambiguous fields with explicit ones, show units and limits as people type, check plausibility, import values instead of retyping them and convert old files safely.
- 03Present results people read correctlyShow an engineering result against its requirement with the margin, put the cautious answer first, state assumptions, show which inputs matter most and round without hiding a failure.
- 04Write messages and help that workWrite errors, warnings and help in an engineering tool so users can act on them: what happened, why it matters and what to do, with examples where they are needed.
- 05Fit the tool into the workPut an engineering tool where the work happens: launch it from the model, store results with the design, link them to the dimensions they use and re-check them automatically when a drawing changes.
- 06Test with five designersRun small, repeated usability tests on an engineering tool: realistic tasks, five participants a round, problems rated by severity, fixes between rounds and a review against known principles first.
- 07Make it accessible and consistentMake in-house engineering tools usable by everyone: readable contrast, meaning not carried by colour alone, keyboard and scaling support, and consistency with other tools.
- 08Measure use and keep improvingMeasure whether a redesigned engineering tool is used and used correctly, choose measures that cannot be gamed, collect usage data openly, and run a steady cycle of small improvements.
References and source notes
The manuscript and worked examples are original KEVOS® writing. References inform particular concepts; their authors do not endorse this book. Web references were consulted on 26 October 2026.
- Luke Malpass, AngelSix. SolidWorks 2009 API: Advanced Product Development, first edition (2008–2013). Supplied source, read for its chapters on menus, property pages and planning a tool's interface before coding. No text, code or figures are reproduced.
- Jakob Nielsen, Nielsen Norman Group. Why You Only Need to Test with 5 Users (2000). Source for the problem-discovery formula and the typical single-user discovery rate of 31% used in Chapter 6.
- Jakob Nielsen, Nielsen Norman Group. 10 Usability Heuristics for User Interface Design (1994, updated). Background for the review checklist in Chapter 6. Paraphrased, not quoted.
- World Wide Web Consortium. Web Content Accessibility Guidelines (WCAG) 2.2 (2023). Reference for the minimum text contrast ratio of 4.5:1 and the principle of not relying on colour alone, applied in Chapter 7 to desktop engineering tools.
- International Organization for Standardization. ISO 9241-110, Ergonomics of human-system interaction: Interaction principles (current edition). Named by number and scope only as the international standard on interaction principles. No content is quoted.