ForceProof is a 21st century, comprehensive software and hardware product solution for materials testing.
Entrepreneur; Product Management, Front-end development.
We have been on this product development journey since 2010. So far, we’ve engaged customers in industry and in educational institutions in Finland, Sweden, the Baltics, and in Germany.
Customer Centered Design Challenges
The implementation includes Qt desktop applications for industrial materials testing, reporting, and data management. I designed the OO architecture and we SQLite for the application databases, as well as NSIS for the Windows installer.
- Online marketing, f2f sales, support services,
- stakeholder mediation, wireframing, usability testing
- conceptual and data modeling
The product we replaced in the market actually had more flexibility than ForceProof. It turns out that in many cases, the overwhelming flexibility of existing competitors was in fact slowing our users down, and the complexity made the learning barrier exceedingly high. For example, the predominant competitor in Finland had a hierarchy of Project -> Item -> Test result. Items were hidden inside projects, and to find a specific item, they had to remember which project it was in.
It turns out that…
- having a flat hierarchy of Project -> Test result and
- allowing users to define additional free text data fields
… allowed for sufficient structure and at the same time made it easier to find your data afterwards.
To give you an idea of the level of internal complexity, below is a state chart for the UI mechanism of the core testing process, in ForceProof Tester.
On the PLC (programmable logic) side, there is a corresponding state machine that controls the testing process from its point of view.
The most fascinating part of this project has been figuring out the degree of variation required, and balancing the needs of different clients here.
During first four (or so) years, lots of mistakes were made and features scrapped that seemed important at first. The big picture of what’s relevant to most customers has built up slowly.
Expanding architecture: Meet needs of a wider variety of stakeholders and organizations
The first version of the software was for testing steel. As we learned about more materials and more standards for testing, we slowly added different parameters and started supporting
- different materials,
- more kinds of testing processes, and
- more needs for data management.
In 2014, we got a deal for modernizing a machine that was a lot more complex than previous ones. A dozen tests, and various units in which the measurement data and the results were to be analyzed.
It was clear our existing architecture couldn’t handle this, so we had to step up the abstraction level.
Both the PLC and the desktop application had to be largely rethought. That client project was complex, but the client was very patient with us, and eventually we finished the project.
For that project, I ended up designing a domain specific language (DSL) -ish API as an immutable data structure, for testing machine and test definition. This provides a single source of truth across the software to adjust customer specific behaviour of the app.
Using definitions created in that DSL, we generate the database, UI and reporting for specific machines. Entire application installation packages can be generated from the data of a single configuration file.
The benefits have been very tangible, of handling the variation between clients at the architectural level. We can handle lots of customers, faster, and so we are scaling up fast.
In all this, I have done a lot of usability testing both explicitly and implicitly in customer support situations to maintain a base level of UX at all times.
UX Stakeholders include
- Automation programming professionals
- Testing managers
- Materials Engineering professionals
- Materials testers on factory production lines
- IT administration
To understand the scope of the effort better, see also: ForceProof suite documentation (in Finnish)