Become a Creator today!Start creating today - Share your story with the world!
Start for free
00:00:00
00:00:01
What Does It Take to Design Great Software for The Construction Industry?
51 Plays6 months ago
This week's episode sees Jason and guest host Mike, speak with Aphex's head of UX, Rob Crichard, unravelling the subject of what good design looks like.
The trio relive design horror stories from their pasts, discuss the balance between adding complexity for power users and retaining simplicity for everyone else as well as shed light on why you shouldn't try to make a product that's everything to everyone.
Follow Carlos on Linkedin | Follow Jason on Linkedin | Check out Aphex
Recommended
Transcript
Introduction and Co-host Update
00:00:11
Speaker
You're listening to the Offsite Podcast with Jason and Carlos, where we talk all things construction and technology. Join us for discussions with industry leaders and insights into latest trends in construction.
00:00:28
Speaker
Welcome back to the pod. So episode 2 of our new temporary co-host. So I'm joined by Mike York, our CSO, instead of Carlos while he's still coming to grips with caring for a new human being as a new dad.
00:00:47
Speaker
Mike, how have you been? Very good. Thanks, mate. Good to be back. I'm very glad that you explicitly started temporary co-hosts. That was music to my ears. Just keeping the seat warm for a little bit before Carlos returns. I know you were saying earlier that it's very clear to you that the bench isn't that deep, that you got the call up for what I was going to say. Yeah, I wouldn't read too much into my call back up for a second.
00:01:17
Speaker
Cool, so we're going to do another slightly non standard discussion today. So like aside from recording podcasts thinking of things to post on LinkedIn. I do some other things throughout the day and the vast majority of what I do usually is product related.
User-Centric Software Design Issues
00:01:37
Speaker
And thinking about product, thinking about how we design our product, balancing features and what users are asking for it, and trying to make, at least, good software. And I think I've probably said hundreds of times in the past, and probably on this podcast, lots and lots of times, this idea that I have this overarching belief that too often in construction software, users are treated like the product. Their job is to input data.
00:02:05
Speaker
regardless of how time consuming or bad that experience is in order to get data into a system so that the company could do something or management could do something or the data can be used in some way. And often at the expense of not thinking about how do we deliver value for that person that has to do the work. And that's one of the things that we really think about a ton. So with that context in mind, I really wanted to have joined the pod very reluctantly.
00:02:33
Speaker
Rob Crichard. Rob is the head of UX AFex. He has been, I would say, single-handedly responsible for every pixel and every screen across AFex. And so, no one better to have this conversation with than Rob. Thanks for joining, mate. Quite a lot of pressure there. Every pixel. Every pixel.
00:03:01
Speaker
It sounded like a you know who to call statement that he was making. Rob's email address, his phone number and a complaints line. Yeah, we should absolutely stress that you have a single problem with a single pixel. Just give me a call.
00:03:23
Speaker
What I'd love to dive into today, Rob, is talk about literally what we spend most of our time talking about is balancing a lot of the trade-offs that it takes to make software
Balancing Software Design Elements
00:03:35
Speaker
good. And hopefully, we occasionally do that. And the balance of features, functionality, aesthetics, and trying to save people time and deliver good experiences. I thought maybe to kick it off, though,
00:03:51
Speaker
We might do a little round the horn of bad UX or bad horror stories that we've seen. So one of the things that we do in trying to solve design problems is we look at lots and lots of software, some in construction, some not in construction.
00:04:06
Speaker
Do you have, Rob, any thing that comes to mind specifically when you think of UX horror stories or design horror stories that you've seen? Nothing with an absolutely horrendous consequence. But there was one client that was adamant that when we were, this is for an old agency I used to work for,
00:04:27
Speaker
that when we were redesigning that software that we couldn't remove his quote unquote does buckle button. Basically, there was this button that was sort of like a save button when you know, Clyde functions take place. Typically, you know, you make an amendment and it sort of saves. But he was adamant that there was this effectively a similar thing that did nothing on the back end.
00:04:51
Speaker
but all of their users were absolutely convinced that it was like a thing tying the entire app together. So we kept the does fuck all button in and we got paid. So happy day. Good for those for those listening. Rob did a quick check before we joined the call of what's the swearing policy? And now it started to click from why should I of why he asked that question. So yeah, we clarified that.
00:05:20
Speaker
We used to have to do forecasting, so we'd have to forecast what our cost to complete for specific cost codes were on the project. We'd have to take in what the cost to date was and forecast forward. We'd have to do it in this software, which I won't name or the contractor, but in order to enter it, it was kind of look like a spreadsheet, but it had none of the, like any of the usability of a spreadsheet.
00:05:44
Speaker
So in order to add to what look like a cell, you had to double-click the cell to put it into like a select state. Then you had to double-click the cell to put it into like an edit state. Then you had to enter your figure or whatever you want to change. If you didn't hit enter, it didn't save. So it was like a four-click type something, type enter in order to make one edit to this cell. So because that obviously would just take forever to build up like a full forecast,
00:06:13
Speaker
What everyone used to do is we would have this really cool feature of importing a CSV. So we used to go and build the forecast in a CSV and then upload it. But the thing that it did is like it would do some like error checking on the CSV. So you go to upload it and it would say.
00:06:31
Speaker
Invalid CSV, end of story. And so you'd have to then go back to the CSV and try and hunt in every single cell. Where do we have a space before the number? Where do we have text in a number column? And so you're not playing the CSV tennis back and forth with this thing, trying to get it in every time. And so that is the epitome of what I think about.
00:06:55
Speaker
how much time I wasted from bad software. And we have to do that every month across, I don't know, by 10 cost codes or something. The thing that you've got to bear in mind, though, is that what was the intention of the UX designer? Because if that was their intention, actually, that's good UX. So they were optimizing for dwell time. And how long could they keep people on the software? Yeah, that's true.
00:07:22
Speaker
Were there any ads in there? Yeah, they could have been trying to run ads at me. That's probably what that was going on. They should have sold me some better software. I would add a high propensity to buy. Mike, do you have anything to come to mind mate? Not that I think can top that, but there's one story that I always reflect back on and
00:07:46
Speaker
large enterprise client, big website and product architecture. And so we're going through the process of trying to simplify the user experience for people navigating through the site. If you picture the header of the website, there's at the moment that was kind of 50 odd links that were there in this mega menu that would expand down and people could click to.
00:08:09
Speaker
And so we went through, did what we thought was right. Look at all the analytics on how many times are people actually clicking these things? Can we reorientate and restructure it? So despite proving that the vast majority of those links weren't in fact used, we ended up losing the arm wrestle and seeing that actually explode into about 300 links. So it ended up being another
00:08:34
Speaker
section beneath all of those expanded links because the person in charge is adamant that the only way that anyone can find anything is via the link in the header and so if the link isn't in the header it needs to be bigger and that's the reason we're not finding it.
00:08:50
Speaker
We lost that one. It's the classic thing, like you can never remove something. Once it's in there, it's never coming out. No. Because someone might need it sometime. You never know, right? Doesn't matter whether it's better or other ways to get there. Yeah, yeah, yeah. So I think, again, the reason I would have thought we could have a conversation, Rob, is I spend so much of my time every day talking to different projects and construction folks.
Empathy-Driven UX Design
00:09:17
Speaker
about what they do in terms of how they do their job, how they plan, how they track progress, what different tools they use. So many of them are interested in the process of how software is designed. So I thought, let's dive into that conversation. So when you think about how to design software, so blank sheet of paper, just run through the process. What do you actually think through? What do we do?
00:09:44
Speaker
Yeah, so it ends like begins and ends with the user. You're sort of always trying to empathize with pain points. Are you always trying to figure out what is someone cracking the whip on them to do every day? And is there a way that you can make their life easier?
00:10:06
Speaker
We've all dealt with certain processes that just take absolute yonks to actually fulfill. And half of that time, I figured you added it up, and you'd just be absolutely shocked about the amount of time that you were engaged in just doing busy work often. And so from a human perspective, actually, one of the big wins for me as a designer is just to give people their life back. There's just so many basic things that
00:10:34
Speaker
As things became digitized, they were so used to doing it pen and paper from an analog perspective. They just got complicated through poor design and all sorts of decisions. And so, yeah, it's just about sort of making sure that the digital experience is not the friction that people have to go through.
00:10:55
Speaker
And then so with that like principle at its core, you know, you start with this idea of, do you start with like, I want to solve a problem. Do you start with here's what the current thing looks like? Where do you sort of start from? You know, if you're starting from scratch, but it's interesting because you actually, where you begin is.
00:11:16
Speaker
You know, I mentioned previously, but it's it's all about empathy because the problems as a UX designer, especially if you're a gun for hire, which is what I was before I joined Apex, is you're having to, you know, walk a mile in the shoes of someone.
00:11:33
Speaker
And so you're trying to figure out, OK, these are not my problems. These are their problems. How do you best solve these for them? So that is absolutely the first step. And so the only way that you do that is by discussing at length through user interviews and then once you get a good idea of what they're trying to do, why the current solutions suck oftentimes,
00:11:56
Speaker
and you can go from there and try and figure out what is the sort of path of resistance. One of the good ways that we do that is we start with a thing called an MDP, which is a most viable product where you basically take stock of again on the set like all the workflows and things you want to achieve.
00:12:17
Speaker
and you analyze and you sort of apply like an Occam's razor sort of like aspect to it where you go like what can we take away so that a user can just get to you know a very basic simple outcome that they want to do in a way that is intuitive and actually at times pleasurable we sort of you know often forget like you know when we're using mobile phones or like smart watches and things like that actually there is a little bit of an
00:12:47
Speaker
sort of thing happening but you actually are delighted by it and so if we can not only make things better for people but actually make it so they enjoy that process then it's just that it creates a very very sticky experience for people that people want to keep on
00:13:07
Speaker
And so one of the things that we often spend a lot of time talking about is we've got this idea of a problem that we want to solve.
Innovation vs Convention in UX
00:13:17
Speaker
There's friction, whether it's in software or another thing that we want to try and bring into software.
00:13:23
Speaker
Where we're looking at like okay here's where the user is, here's the goal of what they're trying to solve and then there's the sort of here's the little description of what they currently do that might require all these steps and they click over here and they put the data over there and then they go run a little report in this spot.
00:13:41
Speaker
I find that often when we're talking there's this trade-off of if it ends up looking like what they currently do, the delta or the learning curve for the new way can be lower, but you can capture some of the inefficiency of what they currently do, whereas starting from blank slate gives you a whole range of opportunities to, I guess, reinvent the process. Which way do you think of it and how do you balance those two things?
00:14:09
Speaker
Yeah, so generally in user experience, there's a huge amount of conventional design that we draw upon. One of the sort of finding principles that I learned when I started out was the idea that you shouldn't reinvent this. Often, there will be familiar conventions that people will adhere to that get them to the exact outcome that they expect.
00:14:37
Speaker
There's still a balance to that, they still need, there are things that just need to be reinvented, maybe they're inefficient, maybe there's a cultural reason why people don't follow certain conventions as well, but often those conventions are not just digital things, they are real world conventions.
00:14:58
Speaker
So, for instance, when we are talking about who recently released the board feature, which is absolutely a reflection on how our users are running meetings with their colleagues. And so we wanted to present, yeah, we wanted to present a digital version of something that they are familiar with. You're writing a post at night, they're discussing their plans, they're discussing progress.
00:15:23
Speaker
and they're moving those post-its around as the plan is changing day by day. And so it just felt like it was a natural thing to offer them a similar digital space that you could either put on a TV screen sticker instead of a whiteboard, and you would have very tangible task cards where rather than having to rewrite the tasks that you're working on every single day,
00:15:50
Speaker
you know, you pull that in automatically, the user can interact with those in a very, very similar manner. So again, it's sort of balancing the convention of how they use analog systems as well as the conventions of using digital systems.
00:16:05
Speaker
Yeah, in that case, I recall we had lots of discussions where you fought for what will I quite technically complicated to implement interactions that made it feel supernatural and not supernatural. It was spookily good.
00:16:28
Speaker
No, but you did. I felt like we kind of knew that there was a bar where it would be good, and then you wanted to push to make it feel like a very natural interaction of moving those things around, I guess, based on that principle. I guess another thing that we
00:16:46
Speaker
We talk about a lot is people ask for things all the time. If you build something that people like, I guess we're in a super fortunate position where they want us to try and solve other adjacent problems or do things in a slightly different way or add functionality.
00:17:05
Speaker
Over time, if we look at the landscape of construction software, I'm very nervous about adding lots of functionality generally because I see what other software looks like with a thousand menus with a thousand hidden menus of options and special controls and things that people don't know how to find. And oftentimes, as we've been through that process,
00:17:27
Speaker
I've seen you find ways to implement things that were at risk of making the core experience more complicated for certain users in order to benefit the people that want these other functionalities. Are there any things that you kind of draw upon or principles that you use to try and think about how to structure that if you've got kind of these, let's say, power users or edge cases that are wanting more functionality, but you've got this core group that
Managing Advanced Feature Requests
00:17:56
Speaker
that value simplicity. So when we're taking on board feedback, particularly from power users who are very opaque with digital systems and are quite happy to put in the hours and learn, maybe they learn accidentally, for instance, they happen upon a people shortcut or something like that.
00:18:18
Speaker
You absolutely have to balance their requirements with the person that is going to bounce off the book piece of software. They can't sort of figure it out very quickly. In those situations, again, sort of talking about conventions, like my background is not in construction.
00:18:37
Speaker
And so when I'm considering someone's request, I'm pulling on what I do know about the industry from talking to people, but I'm also balancing that with, you know, a much wider net is a convention that I can learn from, you know, global real estate software that I've worked on or telecommunications software. And so you can sort of learn like best practices that a user wouldn't really
00:19:07
Speaker
you know, within construction would not be cognizant of. And so, you know, you're taking, you're taking a request and you don't know that the solution actually might live from another piece of software that you've been inspired by or something that you've worked on in class. There's some saying that I've heard you say before, which is like this idea of like the like inspiration is like another person like copyright infringement or something. I don't know exactly what you said.
00:19:36
Speaker
Mike, do you want to jump in, mate? Yeah. When you were talking, Rob, two things you said really struck a chord with me. One was when you guys were reflecting on that board piece that was built and introducing things that were technically competent, technically more complex, sorry. And then also drawing from other industries. It definitely made me reflect some of the design and development teams that I've been a part of and
00:20:02
Speaker
how big that friction can be between the design function and the development function. How have you, I guess, balance that? Because the dynamic I've observed in the team here is one where you are pushing for sometimes really technically complex things. We're blessed to have a technical team who can actually do it. But how do you balance that complexity of
00:20:28
Speaker
what I think is ultimate and really required to do the right thing by the user and not create that kind of tension where the development team feels like it's another handball over the fence with a big kind of ladder to climb to deliver what you've asked for.
00:20:46
Speaker
Yeah, you're trying to balance a billion things that can be the complexity of working in an analog space. We have so many shortcuts when we are discussing something in the real world. So if you talk about drawing something on a board, we can cut so many corners where there's just an inferred understanding of what we're talking about. There's context conversation. The system itself doesn't know that. You have to tell the system,
00:21:13
Speaker
What to make and I suppose this is like the power of AI has been sort of turn that corner.
00:21:21
Speaker
So balancing the complexities of that with the development and sort of technical limitations that we find ourselves having to face. There is certain, you know, you talk about the design to dev handoff. We've worked extremely hard to speed up the way that we can
00:21:43
Speaker
get to a design, hand it off to our developing team, and get to sort of like an AP 90% finished state very, very quickly. And the way that we do that is we developed, when I actually joined, one of my first tasks was to develop a design system where the design team and the development team had a sort of common language that we could refer to the designs. So
00:22:09
Speaker
you're shortening that journey from design to debt. And what that means is that that gives us the mental bandwidth and the space to be able to actually tackle some of the much more challenging technical innovations. They're not worrying about the space of text to a button because that's long been discussed and it's codified from a design and a development perspective.
00:22:35
Speaker
that button on a you know on a mock-up hit exactly the button that will be
00:22:41
Speaker
you know, picked out of the design library and then pushed into the staging environment. And so what that means is, yeah, we can just absolutely focus on some of the things that feel a little bit like science fiction. And we are absolutely blessed to have a CTO in earlier to make some of these sort of like more fanciful elements a reality.
00:23:07
Speaker
Yeah it's so right I think what you're saying in terms of if you get those basics and those little bits almost running on autopilot you're trying to free up the really good mental horsepower to go and solve the big gnarly ones and not get burdened I think.
00:23:26
Speaker
Yeah, I think Jase is excited. You've got him thinking. No, I was going to steer us towards the elephant in the room and that being construction, Rob.
Construction Industry's Software Adoption Challenges
00:23:38
Speaker
And so a number of the things that we've talked about so far would be applicable generally in I guess in the
00:23:46
Speaker
the UX world and yet somehow a number of those things aren't prevalent across software that construction teams use and there is definitely, well it appears to me that there is some uniqueness in the experience of trying to build software for construction teams. Would you agree with it that it is unique and what in your mind makes it unique in construction?
00:24:11
Speaker
Yeah, there's absolutely some unique aspects. I mean, I could say that literally about any industry. There's never been a project that I've worked on that doesn't have its idiosyncrasies. What's particularly interesting about construction is not how reluctant it is to adopt new stuff, but
00:24:33
Speaker
There is a little bit of a good modern options out there. You mentioned, you talk about the idea that the user is sort of really taken for granted in old software. And actually, that's not just a construction thing. That is just a legacy system software. Like in my career,
00:24:59
Speaker
I often would rub my hands if we would get brought on to work on a piece of software that was an old sort of like an XP era software, because there was almost zero appreciation for how does a user onboard, how does a user learn the complexities of the system, how do they, there's zero understanding of how you promote a
00:25:27
Speaker
new user to a power user, you basically would just lay everything out. Think about how many times you've been in the menus, like three menus deep of a piece of legacy software. My aim really is to sort of bring that in a learnable manner.
00:25:47
Speaker
So you do a small piece of the puzzle, progressively disclose the next action that is the next logical action, and you sort of snowball that effect out to the point where suddenly they're doing something that could just be a keyboard shortcut away that previously would be three main
00:26:07
Speaker
Yeah, you're right. I think every industry has its idiosyncrasies, I'd imagine. I guess my personal view might be that construction has probably more than maybe overweight in its fair share of idiosyncrasies. We've got people that have
00:26:26
Speaker
Their context for using software is wildly varied. You've got people that work in an office. You've got people that literally never go in an office. You've got people on bad devices, good devices, small screens, big screens, no screens. You've got people that are extremely time-poor. Their time-poorness is often contributed to by the bad software and things that they might be using.
00:26:52
Speaker
And then you've got this overarching theme in construction of just the whole thing being a high-risk, low-margin business. These teams are managing lots and lots and lots of construction work that all could go over budget, take longer than planned, and cause bad outcomes for them or their client, all to make a relatively, I guess, low margin. So the room for error and experimenting with new tools and stuff is very, very low for them.
00:27:21
Speaker
And so I think what we've seen is kind of what my view is that we see a lot of these people like inventing their own software, just spreadsheets that have lock cells and those do certain things and you enter this thing into the thing. How much weight do you put in the like I guess invented software on top of the spreadsheets when we think about how we could digitize that process?
00:27:48
Speaker
Yeah, it's a bit of a blessing and a curse, actually, because you have people that are really, really engaged with not only their process, but also why their process is better than other people's, right? The reason that someone is going to try and enforce, that's a bit of an extreme term, but encourage people to do it. I think that's fair.
00:28:11
Speaker
Yeah, that's obvious, actually. But yeah, you know, I want my team to use this software because it allows me to get this outcome.
00:28:21
Speaker
Um, and, uh, you know, you talk about the idiosyncrasies, like everyone is time for everyone wants to take data and reveal some information either. But while the information and the, uh, learnings you take from it are idiosyncratic, it's a, it's actually extremely common thing. Like there's data that exists out there and we can better make sense of that data for users.
00:28:51
Speaker
So when you've got this situation where you've got kind of look lots and lots of these people inventing their own software sat on top of say spreadsheets and each of them have slight variations on how they do things to each other in the I guess in the nuance of their spreadsheet but on the whole it looks a lot like each other's.
00:29:10
Speaker
That can kind of manifest for us and I guess for any team doing trying to build software in kind of this bulk of use cases in the in the middle of the bell curve in this big old long tail of these edge cases with slight variations on the on the theme.
00:29:27
Speaker
And it kind of goes back to this you end up having to trade off to a certain degree, you know, some of those things maybe you don't support at all. Some of because there's a better way to do it or something. Some of them you.
00:29:42
Speaker
you have optionality within the software and sometimes you're trying to curate this is probably the best way for you to do it. So I don't know if they're like truly the three option of like curating the best experience giving some flexibility in the system and then just not supporting certain things. Do you see it the same way or am I looking at it in kind of like a pragmatic way?
00:30:02
Speaker
No, I absolutely see it the same way. I suppose one of the big challenges is to the temptation to try and be all things to all people. You sort of look at those edge cases and you think, oh, it would be great if we could do that. Like, how do we balance adoption of our software in the direction?
00:30:21
Speaker
We're not actually just competing with other construction software. We are competing with people's individually created spreadsheets with all of their macros and all of their calculations that are taking place. You're always going to fail if you try and achieve all of that. And so our challenge is absolutely going, OK, well,
00:30:44
Speaker
we can make a better experience for 80% of all of the use cases because we know that what we can do is we can bring in so much more data from such a wider range of people in a way that maybe even those people that are creating very, very complicated and brilliant pieces of, you know, Excel spreadsheet, softwares, really, they are programs.
00:31:11
Speaker
Because they, you know, they take data and they output some sort of insight, sort of exactly what we do. But the point is, is that by sort of being not a common denominator, but quite a pride pleasing piece of software.
00:31:26
Speaker
collecting more data that people are much more happy to provide. One of the big things to bear in mind is that often the person who has made that spreadsheet is really invested in making sure that that data is completed. The person who is actually tasked with filling that stuff out or maybe knows and has the authority and accuracy of data
00:31:52
Speaker
probably isn't on the same page and so you have to make sure that you can make it accessible and as I said earlier enjoyable pleasant to capture all that data from all those people that the data doesn't serve and that's a real challenge and I think that's that's probably one of the most fulfilling things actually for me
00:32:14
Speaker
working on Apex is, you know, when you see people really, really gel with a very uninteresting, quite unsexy process, and they feel compelled to do it. And the data becomes better, more accurate. And you can learn so much more. Yeah, for sure. Mike, did you have a question, mate?
00:32:37
Speaker
Yeah, what you're talking about definitely rang true for me, Robert. Sounds like one of those things that's simple to say, hard to do though. And so what I was reflecting on, I imagine definitely in construction businesses, but when you have internal teams who are trying to build software,
Influential Customer Requests and Product Focus
00:32:59
Speaker
Or you have products where you have really influential customers that are hard to say no to, which is quite similar to kind of being in an internal team. How do you navigate that when sometimes it's not as easy to say no to the requests that they're asking for, because you do end up with this need to almost satisfy all use cases for it to get the green light?
00:33:28
Speaker
Yeah, what are your thoughts on that? I know I've sat on both sides of the fence and seen that before, but I love your thoughts on it. Yeah, there's definitely sensitivity and a sort of degree of politics when you're trying to provide solutions to the industry because, you know, every company will have their own process.
00:33:51
Speaker
and you're trying to learn their best practice and you're effectively trying to sell that to someone else. And so, you know, there's absolutely a sensitivity for that. In terms of managing it, I suppose it absolutely is a challenge. It's not an easy thing to balance.
00:34:11
Speaker
you sort of do it by building relationships and I don't know what the best sort of phrase would be but like a you know a high tide rises or boats sort of thing you get out what you put in sort of deal so it's like yeah you you you might be sort of making it easier for someone else but
00:34:31
Speaker
actually, does he really care like you're also making it better for you. So yeah, there's sensitivity there and it is a challenging thing. And in terms of prioritizing what goes into the product.
00:34:45
Speaker
Again, it's also very sensitive. There could be a feature request from very like an influential person, and you just have to manage expectations. And luckily, sometimes that falls on me but often not. I think we do well to manage
00:35:05
Speaker
features and making sure that we're providing a really good solution for the industry to help. It sounds like it ties back to what you're saying at the start. Like it starts with the user, it ends with the user and that it comes back to the empathy and relationships. I think when they know that you're doing it with the right intent, it doesn't make it an easier conversation. It's still a tough conversation, but if you synced up on the intent, you can at least have that conversation honestly and then work through the problem.
00:35:35
Speaker
And also, some people are just happy for the product, or for the industry, or for the best practice. So actually, some people are just working from a altruistic perspective. And it will never lose sight of the fact that you're interested in helping them anyway. If they are helping us, we are helping them. It's a pretty happy cycle that happens.
00:35:56
Speaker
I've been very surprised picking up on that how broad that cohort is Rob of you know I think there's an element of like you said people have struggled to try and find solutions to things you know the software that they've built that they know is kind of like
00:36:13
Speaker
hard way solving it, but kind of clunky or hard to use or people don't like to, you know, it breaks or whatever. And so having someone take a specific interest in trying to help exactly their use case, there's a lot of people that really just are willing to share whatever information they can to try
Knowledge Transfer in Construction Software
00:36:30
Speaker
and help that. That's been a like real joy through the process and a massive help. Uh, I don't think we could have even built what we built without, without the help of that cohort. Absolutely not.
00:36:42
Speaker
Furthermore, if you think about the movement of people between projects and companies as well, the idea that they're going to build a spreadsheet that they've developed their expertise and their process and their experience over the years and that they're not going to take that to the next project is just fantasy. So it's the same thing.
00:37:05
Speaker
Awesome, I'm just looking at the clock and I think we should probably wrap up there. But Rob, thank you very much for joining us, mate. I think this conversation has probably shown that you're wildly understated in your brilliance at what you can do. I really, really dug this idea that we discussed that engineers have essentially for such a long time, more construction people have been building their own software on top of this
00:37:34
Speaker
you know, no code platform of Excel kind of thing. And I think if, you know, if time goes on and anyone listening to this had wanted to dive into specific topics around, you know, different software or how it's designed, I think we'd definitely do a follow-on conversation in the future, Rob. Thank you very much for taking time. I know you were reluctant. I think it was quite painless and you did well. Thanks, Rob.