How to make your digital tool a success

Author: Matt Harrison

Date published

23 March 2021

Price
Free

Online purchases unavailable

Unfortunately we are unable to process online purchases at this time.

Find out more

Back to Previous

How to make your digital tool a success

Blog
Date published

23 March 2021

Author

Matt Harrison

Price

Free

Online purchases unavailable

Unfortunately we are unable to process online purchases at this time.

Find out more

Author

Matt Harrison

Matt Harrison considers how users can help to shape digital tools. He discusses the merits of effective community engagement and shares his thoughts on best practice.

The vast majority of our jobs are conducted on computers, whether it’s modelling, analysis, calculations, or even simple report writing. The one task that seems to be exempt from this is conceptual layout of buildings. We could use computer-based tools to achieve this task, but instead we rely almost entirely on human creativity and logic.
 
In the current climate there is rightly increasing pressure to improve our material efficiency and consider all materials for carbon efficient designs. Given that we currently lay buildings out in a manual time-consuming way, is there an opportunity to use our computers to help us increase our level of knowledge at an earlier stage?
 
I gave a talk at the 2020 Digital design and computation e-conference on my efforts to implement a procedural method for geometric analysis of building floorplates. During the development of this methodology, I came across several unique challenges when creating tools and here I’ve shared some tips and tricks for approaching these.
 


Effective stakeholder and community engagement

 
Lots of people don’t like change, and engineers are no exception to this. We rely on our rational, logical brain and we are slow to trust ‘black boxes’ of technology. Therefore, when trying to develop tools to automate and enhance the engineering workflow, it’s essential to get the people who are going to be using them engaged early.
 
There are several ways I’ve tried to do this, all with mixed success. The key is to use as many channels as possible. This makes the development and vision of your tool or methodology so much easier to implement.
 
 I’ve found the following works well:
  • Briefings before, during and after development. This can help with getting volunteers for testing and people who are interested in guiding the tool. During these briefings it’s essential that you show how your tool or methodology fits in the current workflow. You must also demonstrate how the tool will impact on the lives of the users
  • Specific user focus groups with testing and feedback right from the start of development. I’ve traditionally run these with one or two users at a time. I get feedback on how they would use a tool on a specific project or in a specific situation
  • Post-release project support, initially offering specific projects dedicated support to use as case studies and presentations

It’s important to limit the problem space

 
Often when developing tools for the structural engineering community, the problem you are trying to solve is massive. With these types of problems, you are also dealing with numerous requests from the community.
 
During the development of my new methodology, I constantly faced comments such as ‘it looks great, but it would be even better if we could add x’. These comments are fantastically helpful, but your scope can quickly spiral out of control.
 
In order to combat this, I suggest forming a robust steering group for your tool or methodology. This should be formed of people whose opinion you trust, and will guide the project to a mutually beneficial development.
 
I filled mine with the technical and project leaders from my company, to ensure I had a technically sound, yet useful tool. Using this steering group, I could make use of agile project management methodologies like Scrum to prioritise requirements and handle the constantly evolving problem space.
 
 

The value of diverse development teams

 
When I start working on a tool, it often takes a few days to develop an idea or principle before I can show it off. During this phase, it can be tempting to isolate yourself to get your thought processes in order and think through the tool. However, you need to do the opposite of this.
 
To build robust and useful tools, it’s important to have a diverse development team, or at least a diverse steering group. This ensures you have considered the proper range of requirements, and that your logical flow is not siloed.
 
The benefits of this are:
  • Your tool will consider a wide enough range of variables and parameters to be useful for project teams to implement
  • If you leave or hand the tool to someone else, it’s not just a black box. Whilst code commentary or producing documentation is never particularly fun, it does allow for collaboration which enhances anything and everything you do  
Ultimately, if you want your tool to be a success, you need to focus on people. The users will make or (quite literally sometimes) break your tool and its acceptance within your business.



 

Additional information

Format:
Blog
Publisher:
IStructE

Tags

Blog Digital

Related Resources & Events

Blog
A man uses virtual reality with bridge in background

Virtual reality in construction: the future

Arthur Coates, a structural engineer at Price & Myers, gives the contractor’s view of the future of virtual reality.

Date ‐ 17 August 2017
Author ‐ Arthur Coates
Blog
Tim Lucas

Emerging technologies: understanding and exploring their potential

Tim Lucas discusses the importance of research taking place at UCL’s new “Here East” facility and how it relates to the Institution’s Digital Workflows Panel.

Date ‐ 20 August 2018
Author ‐ Tim Lucas FIStructE
Price ‐ Free
Blog
<h4>Embracing the opportunities offered by automation</h4>

Embracing the opportunities offered by automation

Jon Shanks discusses the skills structural engineers will need in the face of greater automation.

Date ‐ 6 February 2018
Author ‐ Jon Shanks FIStructE