In this episode, we dive into how Figma powers our UI/UX design process at Element Engineering Australia, helping us deliver top-tier web and mobile app user experiences.
UI/UX designer Kathryn Anema explains how Figma’s real-time collaboration, rapid prototyping, and reusable components streamline our workflow, allowing us to create stunning designs faster than ever.
We showcase our work on apps like Koodaideri’s HydraTune SafeAdjust remote hydraulics maintenance system, the innovative Cranio data logging and control web app, and our in-house BusMin business management software. Kathryn and Ayrton walk us through how Figma helps us turn complex user requirements into clean, intuitive interfaces, ensuring a smooth and cost-effective design process.
What do you use to design user experiences for apps? Let us know!
For those who would prefer to read rather than listen, here is a transcript of the conversation!
How we use Figma to design user experiences for web & native app software.
Ayrton: We're talking about Figma today. Previously we were using Adobe XD. We're still using a lot of the Adobe ecosystem to do general design and things like that. But Figma has become a major part of our workflow, especially for web app and mobile applications.
Kathryn: Our go-to for UI/UX design. It's just quicker. I can do things quicker, I can replicate things quicker.
I really like the sharing feature, which we use a lot. When we review, we'll put a pin on what we're looking at and we'll comment on that and tag in one of the designers, like myself and Nicole.
Ayrton: We were using Adobe XD and I remember it was kind of like a static file that lived on OneDrive or on the server. Only one person could have it open at once. But Figma's created that web based collaboration where you can actually see where the other person is within the file. You can follow them around, you can tag people.
Figma is the largest product in the world at the moment for graphic design, valued at something like $20 billion recently when Adobe tried to acquire it. But then it fell through, which is probably neither here nor there. But it's a great tool for collaboration and it's really changed our workflows.
Kathryn: I couldn't go back to XD, yeah.
What’s your favourite app user experience?
Kathryn: Stan is something I use a lot. And Spotify, multiple times a day. One of my favourite things about those types of apps is that you'll see a lot of content at once, which is so nice when you're trying to pick something to watch or listen to.
Ayrton: But it's not overwhelming though.
Kathryn: No, they organise it with vertical scrolling, but you've got your little categories up and down and you can scroll left to right amongst those categories. You don't have to actually deep dive anywhere unless you want to read more.
What's your favourite?
Ayrton: Apps that aren't clunky.
Kathryn: What about Meater?
Ayrton: The Meater probe is great, yes! Absolutely awesome. It's a Bluetooth cooking device that has two temperature sensors, one for inside the meat, and one outside for your air temperature. And I struggle to stuff up a piece of meat. It's very easy to get into, it's very easy to pair with the device, and it gives you just enough information.
Kathryn: I like the use of colours that they've got. I've seen the nice fancy dial with all the bright colours.
Ayrton: It does scream at you when you take it over temperature, like you might damage the probe. I've damaged a few of the probes, but I love them so I keep buying them. When you use a rotisserie it gets really, really hot. It'll create a local notification through Bluetooth to your device. And it will scream at you with an alarm, which is fair enough. You're damaging a piece of equipment. So, yeah, a great user experience.
On the same note, a really bad user experience. What's the worst user experience for an app or website?
Kathryn: Any real estate related app. For lodging complaints or maintenance requests, or even just...
Ayrton: Like tenancy?
Kathryn: Yeah, tenancy stuff. It does what it needs to do...
Ayrton: Does it feel like a form?
Kathryn: Yes. It's not very pretty, it doesn't look friendly.
Ayrton: Yeah. It’s probably not!
Kathryn: It's daunting.
Ayrton: I have a few IoT things at home. My pool, for instance, has an app to be able to monitor things on a little tiny LCD screen. You've got to click through different buttons. It would be really nice if I could change the settings on the app, but the app can only visualise some of the higher level stuff. And whenever you go into the settings, it crashes.
I think that the worst user experience is when you can't understand it, or you can't reason with it, or you don't know why this thing's crashing. And it's frustrating to me.
Kathryn: User feedback is important.
Ayrton: Yeah, just some sort of feedback. Oh, this is not available, or whatever. If it crashes, it feels frustrating. And frustration I think is the worst thing.
We've seen that with the ShockWiz app, for instance. For years and years we had hardly any bad reviews. We got a reasonable number of four or five stars on the Android app. But when we released the newest update, because we successively rolled out a few features and some were missing, all of a sudden we had a couple of really bad reviews. And it's like, hang on a minute. These people didn't give us a positive review before, but now they're giving us a negative review. Obviously they were the silent minority or silent majority.
It's a funny landscape, that sort of thing. We're doing it all day every day because the interaction with smart tech is all done through some sort of dashboard, a web application or mobile application. Frustration with that is what we're trying to get rid of and really trying to just give the user the feedback that they want in the cleanest possible style.
One of the main reasons I hired Kathryn was because of her clean style that I really loved. We try to focus on that here at Element because a lot of things we do are really tech-y. And tech can be real jargony and it can be really overwhelming to a lot of people.
Kathryn: Very complicated, very complex, yeah.
Ayrton: Simplification of the messaging is really important.
How do you create a good user experience?
Ayrton: What does it take to create a really good user experience with an app?
Kathryn: Plan your app. What are your main user journeys or flows? What is the user going to be doing? Where do they need to go? Do a basic sitemap, create a wireframe. Simple enough so you don't have to do that much work, but complex enough that you can see what's on each page. And make it clickable so you can click through your user flows.
Ayrton: That's one of the big discoveries we often come across, isn't it? We will usually have an engagement with a client, we'll have a workshop session. We'll put up some things on the whiteboard, figure out what those things are, and get some specifications. You'll start putting it into Figma, laying out those journeys. And as you've laid out the wireframe, we've found that we've missed something, or there's something that needs to be covered.
At that point we'll re engage with the client and say, "Hey, how about this? How about that?" And they're not always edge cases, but some of them can be. Usually, we find that the specifications just grow due to now understanding requirements a bit better.
That definitely happens in the mechanical & electronics worlds as well. Once you start delving into something, you think you've covered it all. Back in the day, I used to work on these big truck trays. And I'd work with a guy called Alan who used to create truck trays for 50 years. He would have everything laid out in 2D on paper. But once we got it into 3D, all of a sudden it uncovered something else. “Oh, I didn't know that because we couldn't see this.”
It's the same thing with Figma. We seem to figure out, okay, the wireframe is enough to get information that we need, now we need to do something else.
Kathryn: It lets them see what they're getting themselves into. Like, is it feasible?
Ayrton: And the clicking through. So from that point, you go from wireframe to mocking up the flow between different pages with different clicks.
Kathryn: That's when you can see when the users are clicking too much, when they have to deep dive too much. That’s not fun for the user. The user needs to see where they've gone, and be able to go back to where they came from. And you can refine it in the wireframe stage before you move on to design and styling.
Ayrton: We found over the years that some clients can't visualise it in wireframes. We have to go for a more polished version.
Kathryn: Yeah, you have to throw a few colours and images in there, and add their personal branding touch sometimes. Just so that it makes it more theirs, and they can visualise it better.
Ayrton: We have to profile the customer, in a way, or understand what their needs and desires are. Some customers will really pick up the wireframes and run with it. Other customers won't be able to get it unless they see it branded. We'll just attack it in different ways.
Obviously less detail is better, lower cost, less time. Putting the minimum amount of effort in to get the maximum bang for buck. Simple and clean is our preference.
Kathryn: Especially with visualising IoT data.
Ayrton: Yeah, that's very overwhelming.
Kathryn: You want to put emphasis on your data. You don't want all these little bits around there confusing you.
How can we produce user experiences quickly in Figma?
Kathryn: Make sure you have a generic, basic, and reusable component library on hand, and then take from that as you need. That allows you to replicate things fast and get something together really quickly.
Ayrton: Do you have any design templates? We definitely have the library of components that we keep reusing, but do you have any sort of general layouts that you use, or it's always just from the components that are selected depending what the customer needs?
Kathryn: In terms of menus and navigation, yeah, it's quite generic. Because what works, works. We don't want to fix something that's not broken. But most of the time we'll just figure it out, it varies from project to project or client to client.
Ayrton: We're not reinventing, you know, back buttons every time.
Kathryn: Yeah, we've got three sizes of each component as well. Three sizes of button, and we show different states of the buttons. The default state, the clicked state, the not clickable state.
Ayrton: Are these all aligned with Ravinder and the software teams' coding flows?
Kathryn: Yes. And it's using a similar language as well. When we build these components in Figma, we name them similar to what the dev guys would.
Ayrton: So we're all on the same page. That's another part of creating a product quickly, is having those things aligned between teams and being able to speak the same languages.
How do you design a cost effective user experience?
Ayrton: Cost is time, basically, for us. We don’t get engineers to create designs. That's one thing we learned early on in Element. If you give a design idea to a developer, they will, a lot of the time, freak out because they've got to go and do some design work. One of the major reasons why we hired graphic designers & user experience designers in house was that we want to alleviate the burden of design from the engineers.
Engineers work really well when they've got a specific template that they can use. And Figma gives us that, because the guys just grab where those icons are, they grab the asset picture in SVG format, and put it into their code base and just place it into the screen. Cost really comes down to letting the professionals do their job in their certain domains. You can iterate a lot quicker in design than we can, you know, build something in a dev environment.
We seem to be developing specific widgets for each customers’ particular use case. But what percentage of the time would we reuse the libraries we've already got, versus developing new stuff? Half the time? More than half the time?
Kathryn: Yeah, more than half the time I would say.
Ayrton: If we can get away with using our libraries just to get a flow down to start off with, we might be able to get more discovery done. And then if we need specific widgets, we can probably try and push that to the back end of the project and further on.
Kathryn: We've designed our component library with that in mind, so it's really easy to style and adjust. We publish that library to that file and then you can access everything. It's really quick to switch components out.
HydraTune SafeAdjust App
Ayrton: We worked on Koodaideri's HydraTune system, featuring SafeAdjust native tablet app that technicians can use to remotely perform maintenance on dangerous hydraulics out in the field. How did you approach the user experience for the app?
Kathryn: Definitely with safety in mind, so not putting the critical buttons in the line of where someone might accidentally brush past that and make a huge mistake.
Ayrton: It was more defined for us, this one, because we were given a specific tablet, a ruggedised Android industrial tablet. We had one screen size and one user experience. We didn't have to be scaling devices, so to speak, which is good.
Kathryn: That was really good, yeah.
Ayrton: In Figma, each one of those individual pieces is an asset that we can basically style from the library. And then we can bring over the top a customer specific styling palette, don't we?
Kathryn: Yeah. That's just your colours, font, little bits like rounded corners or logos or specialized icons.
Ayrton: So the custom icons go in the client's Figma overlay?
Kathryn: Yes, it's in their style. We'll just put a placeholder icon in there so you get the idea of what's going on.
The user will just come in, open up the app, log in, they’ll see, for example in this app, their tuning profiles. These are things that they can configure. To show that, you'll see these arrows that you can go and click into.
Ayrton: Yeah, so Figma is sort of showing us there that we can click into that tuning profile. Cool. If you click somewhere else, you can see where you can click, can't you?
Kathryn: Yeah, it highlights it. Really cool when you're going through and you're making sure you haven't missed something. You can see what's already been interacted with.
Ayrton: We definitely did this back in Adobe XD as well. It was the same sort of flow, but it was harder to deploy and share with people.
Kathryn: Yeah, I personally found it harder to use the prototyping feature. It was a lot more clunky.
It was easier to miss something there. You wouldn't see a connection that's not there, basically, a connection between two pages.
Ayrton: With Figma, the customer can easily come in and make changes on the fly as well. We can suggest changes, make changes within the day, create a new link. The customer logs on remotely from wherever they are, they click through the wireframe, you guys can do a Teams meeting. It's awesome.
The web team was able to take this design directly from the Figma layout.
Kathryn: There's actually a dev mode as well, where they can see all these little bits, the padding, dimensions, all in pixels.
Ayrton: One of the big things we were trying to do with this app was break it. I remember when we were doing things up on the whiteboard, we were trying to visualise, if you asked for the device to go to this point but then the device needs to catch up because it's a safety critical thing and it's not going to get there instantly, what happens when you do that? You direct it to where it needs to go, it then starts to catch up. You may make a move that needs to go back and forward in different directions.
We did it up on the whiteboard, and we all got a bit confused. We're like, let's put it into Figma. And then I think we got to the end of it.
Kathryn: Yeah. The UI needed to show what was happening in real time. This was me walking myself through the dial adjustments, basically.
Ayrton: We were trying to figure out, if we go round the dial further, then what do the colours and things like that do?
Kathryn: How do we show overlap, yeah, without it looking too complicated.
Ayrton: It's trying to go to there, trying to move in the degrees or half of degrees. The HydraTune device has a massive gearbox on it that takes a usually very fast stepper motor, but reduces it by 40 or 50 times so it gives a massive torque out. But the actual output is relatively slow. You can request multiple turns, so it's not just a simple 360 degrees.
It's coming back to me now, the pain! If someone wants to go much further than, say, a single turn, how are they going to visualize it? And how are they going to get the feedback that they've gone to where they want to go, or it's going to where they want to go and now it's safety critical?
Kathryn: It gives them enough time to stop that action.
Ayrton: Yeah. This dial was quite an important mock up that we had to visualize for ourselves, and obviously get the customer on board with it so we all understand it & get the specifications right, not only for the app development but also the firmware. Electronics not so much, but definitely the user experience, and what the customer wants at the end.
It's kind of become second nature that, you know, we put things up on the whiteboard and then all of a sudden they pop out of screens.
Kathryn: They just appear!
Ayrton: But there's a lot of work in the background to get to this point.
Developing the Cranio web app in Figma
Ayrton: We're currently working on our own data logging and control system, Cranio. A major part of this system is a web app in which users can find their devices and set up their own IOT system, like a visual programming language. It's a massive challenge. How did you approach this?
Kathryn: Massive challenge is the right way to describe this!
Ayrton: I have lots of things in my head that I'm trying to get out.
Kathryn: Constant refinement, constant revision, yep.
Ayrton: But it's also exploration in a way, because it's things that haven't been done before.
The whiteboard is our number one tool. Kathryn comes and sits in on me trying to figure out what something is on a whiteboard. A lot of the time it's me just trying to get it out of my own head and figuring out what this thing could be. But pretty quickly it ends up in Figma, and that's where we can really figure out what it is.
With Cranio, we're going for a cool, simplified web app that visualises devices and arranges them into systems. Each device needs to be super easy to interact with, which is not an easy task when you're doing web development of something that you have to visualize from a bunch of engineering specifications.
Everyone's seen line graphs displaying data before, different timelines and things like that. But for us to be able to look at live & historical data and be able to select the time period, zoom in, and then tag data so we can use it in AI later on, is something we’ve never seen before in a web application. It's a big project, and there’s lots of fun stuff happening in the background.
Kathryn: This hasn't been done before. I've looked, trying to find something to reference. We’ve needed to do it completely from scratch. All the widgets.
Some of this Cranio stuff can be quite complex. So that's where the wireframe comes in. It's really handy, so we don't waste time. We can see if there's something that needs to be refined, or we need to add to something else before we go and detail it.
Ayrton: Yeah, that's one thing that I think some customers can't understand, or they don't understand at the start of a project. You think you've got everything sorted out when you do it on the whiteboard, but once you actually get into the details, you uncover certain things.
Kathryn: Yeah, you uncover a lot. Good and bad.
Ayrton: And you want to unpack it as quickly as possible. If you don't discover something right at the end once you've already done the work, then it could be detrimental to the project and the team.
Kathryn: Exactly.
BusMin
Ayrton: We have long used our very own business management software, BusMin, for time tracking. I think it we originally made the first one around 2012, called BusMan, Business Manager. Now it's called BusMin, minimising the busyness. Because busy work is wasted time in our eyes.
This internal business management software is something that we mocked up using Figma, and Kathryn and Nicole did all of that here. We knew what we wanted, but we were iterating as we went because we were trying to go really fast.
BusMin has now been fully fleshed out with a bunch of features that far exceed what we need in the business. We see this going forward towards a commercial product.
Kathryn: At first we replicated everything that already existed in old BusMan in Figma and we just added to that any features we needed, with the same styling, using the same sort of components, the same sort of layout. With a bit of a refresh.
Ayrton: The original software was built on someone's flavour-of-the-month unmaintained software package that was quite hard to get developers in to maintain. BusMan was also slowing down, the database got very big, it didn't really handle what we needed to do. So we rebuilt the back end completely from scratch, and rebuilt the front end in React using TypeScript.
One of the biggest experiences that I can share is, choose technologies that are not just the coolest flavour of the month. Because the coolest flavour of the month might not exist in six months time.
Kathryn: It's not sustainable.
Ayrton: Exactly. Even if the technology looks a bit more boring, it’s probably much more sustainable.
Figma itself is a flavour of the month, but it's actually really, really good. And it's got a huge user base and a lot of support online, you can basically use Google if there's any issues with it and other people have come across the same things. That's what you want from any technology selection that you make, in any sort of product development, because if that developer or engineer gets hit by the bus, your project's still got to keep going. If their particular flavour is not something that was commonly done, you might find it hard to replace that person.
We use BusMin for time tracking so that every block of work is tracked for the customer, and making sure that our internal processes are quality. The team leaders sign off each individual block of work, they get billed to the customer or they go to an internal or R&D job.
We have a rostering system. Scoring KPIs within a business is often done by someone with a spreadsheet, right? But if we can visualize our KPIs on a dashboard, then everyone's aligned with their incentives. To be able to hit KPIs, you’ve got to know what the underlying working hours might be. That means we've got to go all the way back to the business calendar. Which days are people working? Which days are they rostered on? Okay, that day that they're rostered on, we can score the KPIs.
So we have to go through all these lengths to, in software, be able to make all those different pieces of the puzzle to be able to create a generic incentivisation system that can be applied to any business.
Kathryn: Yeah. We can visualize all of those stats, basically.
Ayrton: And you can be as aggressive as you want. You can have a big green tick and a big red cross if you want to.
Kathryn: Search for pages, search for components, whatever. There's a massive breakdown of these different time periods. The employee will be able to see how many hours they have, what their target is.
Ayrton: We mocked things up in Figma and didn’t do any development work until we were happy with this. And then giving a pixel perfect UI to the developers to go and do their job. Best use of time and cost.
Kathryn: The project manager tool was probably the one I spent the most time on.
Ayrton: It's probably the biggest one, bringing all of our workflows into one place and doing it better than what we've done with Jira and Microsoft Project. We're kind of reinventing the wheel, but adding important features that are specific to our workflow, like the rag/traffic light system.
If we had a project and certain elements were running over time, then we could have a KPI system which says this particular group of tasks is allocated for a certain number of hours. An employee would put in a work log that says, I have completed 50 percent of it, and I've done it in four hours. Okay. Green. We're underneath the threshold. I've completed 50 percent of it, but I actually used 12 hours. Okay, that's at risk, this thing's run over, and we've gone into a red traffic light.
Those are the things we're currently doing manually. You have an engineering team leader who's spending their time going through logs, aligning BusMin with the time spent versus the ticketed time. Having it all in one place would be amazing. And maybe there are tools out there that do it, but we haven't seen them.
📢 Don't miss out - subscribe to The Engineering Triangle Podcast for more!
Comments