How to Design Forms for Amazing User Experiences with Mary Ann Castro

[00:00:00] Welcome to episode 99 of the Amazing Apps show. Join me with special guest, Mary Ann Castro, as we discuss her upcoming DynamicsCon session and learn about effective form design.

[00:00:11] Hey, it's Neil. How's it going? This is Amazing Apps episode 99, and you'll find the show notes at our new website, AmazingApps.Show/99. 

[00:00:46] I'm joined by Mary Ann Castro, a senior functional consultant At new Zealand's Ministry for Business, Innovation and Employment. Originally from the Philippines, Mary Ann worked in Singapore for four years before moving to New Zealand nine years ago. She's presenting at DynamicsCon in a couple of weeks and in today's episode we discuss her topic, designing effective forms for a better user experience. While you're listening, you can register for DynamicsCon at DynamicsCon dot com. I'll see you there. Until then, here's Mary Ann.

[00:01:17] Mary Ann, welcome to the Amazing Applications podcast. It's great to have you on the show. Thanks so much for joining us. 

[00:01:25] Ah, thanks for having me, Neil. 

[00:01:27] I wonder if you 

[00:01:28] and yeah, it's a pleasure to be on your show.

[00:01:32] Ah, thanks. I appreciate that. I wonder if you could just take a moment to introduce yourself, let us know who you are and where you're from, and we're going to be diving into the topic of your expertise in just a moment. 

[00:01:43] Cool. Yeah, my name is Mary Ann Castro and I am a senior functional consultant doing Dynamics CRM, or we now know Microsoft Dynamics 365. Originally, my Dynamics journey started in, in Singapore when I was working there before I moved into New Zealand. So when I first moved to New Zealand, I joined that Datacom as a functional consultant and back then it was I was working on the 4.0 version of, of CRM. So that's like maybe 8, 9, 8 years ago. So 

[00:02:21] I remember when it launched version 4.0, it was in 2007. It's a long time. Yeah. 

[00:02:26] Yeah, it's a long time and yeah, and looking at how that evolved to what we now know Power Platform or the first party apps, it's gone a long way, you know, a lot of enhancements and stuff. But yeah, I'm originally, so I now live in New Zealand, but I'm originally from the Philippines.

[00:02:48] So you've lived in the Philippines obviously and Singapore and New Zealand. So you're a well traveled functional consultant. 

[00:02:55] Yes, you can say so.

[00:02:57] But you're not in consulting anymore. You've taken a role with a Microsoft customer recently. Yeah. 

[00:03:02] Yes. So from Datacom, I actually moved to Walker Scott, which is also a service provider. And then I moved. Now I'm with the Ministry of Business, Innovation and Employment. So a government here in Wellington and I'm still doing Dynamics so I'm part... 

[00:03:20] Nice. So no more time sheets for you. 

[00:03:22] I still need to do a time sheet, but not into that level of, you know, the same as when I was in the service provider world.

[00:03:30] So what are the differences that you find between working for a Microsoft customer and working for a partner? 

[00:03:37] They say it's a little bit slower on the other side of the fence. But essentially, you're still working. I still work with the project team, although now I have to work with, with the vendors. So I think it's, it's a good way of when you have work with, as a vendor before you know exactly what they need from you and what you can help them with.

[00:04:05] So in that sense, that kind of helped that I understand both worlds. 

[00:04:10] So.

[00:04:12] I, I think it's great to have experience working on the other side of the fence. Like you said, it gives you a whole different perspective and you get to concentrate on just one application or just one set of users and give them a really good experience. And you don't have to hop around from project to project so much like you do whenever you're in consulting. 

[00:04:31] Yes. And one of the challenges I find actually, when I was thinking of consulting is the context context switching. Especially if you're juggling multiple projects at a time. But your day goes like that. It's going to fast, like, you know, you start your day, you look at the clock.

[00:04:53] Oh my God. It's already 4:00 PM. Where has the day gone? But you still have lots to do. Like 24 hours is not enough.

[00:05:01] Mary Ann, it's great to have you on the show because I was really excited about the topic of your presentation that's coming up at the DynamicsCon conference on Monday, the 20th of September, 2021. So if you're listening to this show, after that date, the recording will be available on the DynamicsCon YouTube channel. But if you want to register and join Mary Ann's session live it's 10:30 AM on Monday, the 20th of September. I think your presentation is on at 10:30 AM Eastern time. That's U.S. Eastern time, right?

[00:05:31] Yes. Eastern time. Yes. That's like, 2:30 AM New Zealand time. So good luck to me. Oh yeah. I'll have a few mugs of coffee around. 

[00:05:45] So you're going to be joining your session, answering people's questions in the chat and maybe available for a Q&A afterwards. Good for you. 

[00:05:53] Yes, live. Yeah. I've actually just did the recording with them this morning. So quite excited to see that.

[00:06:00] Good. Your topic is designing effective forms for a better user experience. I assume we're talking about model driven forms and applications, such as Dynamics 365 and Power Apps built on Dataverse. Are you also including canvas apps in your presentation?

[00:06:17] Yeah, so my topic is focused on model driven apps, but because the guidelines and like the design considerations, best practices that I covered are kind of quite general, so it can be applied to any types of forms as well, like canvas app, even for portals. Um, that will be applicable as well.

[00:06:41] Right. Okay. Do you think the form design principles vary depending upon the application? Is there a difference, for example, between, uh, designing a form for Dynamics 365 Sales compared to Marketing compared to Customer Service. It sounds like your principles are pretty universal across any applications. 

[00:07:01] Yeah, I think if you're talking about model-driven apps in general, it will be the same. I think where it will be very different is if you're talking about a front facing form versus the back end forms. 

[00:07:16] So I'm doing a review of a customer's implementation at the moment, and it's not so much focused on the user experience, but I have noticed some things about the user experience, and I just wonder why somebody did it like that. I was wondering if I could run these past you and you can give me your expert opinion. 

[00:07:32] Sure.

[00:07:34] What are your thoughts on required fields on a form? Is it a good idea? Does it improve data quality because every record has got something in the required fields or does it lead to a terrible user experience? I mean, sometimes you just end up putting anything into the field just to save the record with the required fields. 

[00:07:53] Yes, yes, yes, yes. I know. So it's, it's always a good idea to ask. So whether it is necessary for a field to be required because you need to consider whether, especially when creating the record, is that information already available? Because if not, you'll end up having the user just typing some garbage in there because they don't have the information yet.

[00:08:20] So what you could do is if you really want to, you know, make sure that that is not left blank, you do business rules. It could be, make it mandatory based on something. Just to ensure that is filled in by the user.

[00:08:36] Oh, okay. So maybe at the right point in a process, you would make a field required in order to proceed to the next stage of the process rather than the very beginning of the process. Okay. 

[00:08:47] Yeah. If it's on create then, you know, is that information available and if not, then maybe status change. You make it mandatory. 

[00:08:57] Yeah. Yeah. I like that idea. Okay. Another thing I noticed in this implementation was there was a lot of different case forms. Each one matched up to a different case type. So as the form loaded, there was an onload event detecting the case type and switching to the correct case form. But there's a little bit of a blink as the form loads.

[00:09:19] Is this a good pattern that you've seen or is there another way of doing it? I thought of just having different sections or tabs that are hidden and revealed depending upon the case type. And those don't have a flicker when the script kind of determines which ones to hide and reveal. What do you think about those complex scenarios where there's lots of data, depending upon the record type, have you seen a good pattern?

[00:09:43] Yeah, I think it depends on the complexity and how many fields you are talking about. So if, if it can be handled by, you know, a hidden section, a hidden tabs and just do JavaScript to hide and show them, you know, that would be much simpler approach. But if it's a form. If it's a lot of fields in, it's a form that you need to, to hide.

[00:10:07] I think there are, I actually mentioned that in my presentation, cause there's like a method that, it's an article by Andrew Butenko, where he did that Form switching form change based on the information available. So you could do that as well as a different approach, alternative approach.

[00:10:30] Okay. So it depends upon the circumstances. 

[00:10:33] Yes. Well, it depends on the circumstances.

[00:10:36] Yeah. Now you mentioned business rules and JavaScript, as a functional consultant, do you have a preference as to the approach that's used to do the interface customisation? I know that I don't, I don't have a technical background, so I would probably use business rules. That's really the best I've got available. Or I might need to go to Andrew Butenko's blog and copy and paste his JavaScript. 

[00:10:58] The 'You Ask, I Build', by Andrew. I've actually had this conversation, uh, with one of my colleagues before and he's a developer, so, for me, cause I don't do development. I don't actually do JavaScript. So if I have to do it myself, I don't have a choice, but the business rules, but it can get quite complex if you have a lot of rules and they're contradicting each other, you know what I mean?

[00:11:25] But if you have a JavaScript, so again, it depends on the scenario on the complexity. If it's quite simple, then do it in business rules. But if it's a big, you know, if it's complex, I would prefer using JavaScript and just put everything, all the logic in that JavaScript. And you have one place to update one place to look at and review and maintain. 

[00:11:49] Yeah, because the maintenance of it is pretty tricky when there's dozens of business rules. 

[00:11:54] Yeah. The maintenance. Yes. 

[00:11:57] When I've led bigger development teams, and we know that we've got good JavaScript developers in our team and the customer has got JavaScript skills to do the support and maintenance later, my preference is to try and do everything in JavaScript because having some of the customization in business rules and some of it in JavaScript just makes it a support nightmare. And you're just trying to figure out why is the form behaving like this? 

[00:12:20] Yeah. And debugging, will be a nightmare. Like why is this business rule not working? Because something else is doing something.

[00:12:30] All right. So do you think learning JavaScript, at least to be able to do the kind of user interface customization, is that worth it? There are not that many methods to show and hide and make things required. Do you think it's a worthwhile skill for a functional consultant to learn? Are we going to be so bad at JavaScript that we're better off leaving it to the professional developers? 

[00:12:49] Personally, I'll leave it off to the developers personally. Yeah, I'm not really. Yeah. I'm not really into coding. I don't trust. I don't trust myself with coding. 

[00:13:02] Yep. Well, you know, play to your strengths. That's awesome. 

[00:13:05] Yeah. Yeah.

[00:13:06] Taking it a step further. Can you set up a PCF component? If you saw something nice on the PCF gallery, would you be able to deploy that into your environment? Do you think PCF custom controls add a lot to the user interface experience or are they overly complicated and, you know, lead to forms that are very fancy looking, but actually don't work very well. What are your thoughts on custom PCF controls? 

[00:13:28] Yes, you need to be very careful in choosing those controls because there's a lot available. You go to PCF gallery, but in terms of, because out of the box, you already have all those controls and Microsoft actually, you know, release from time to time new controls as well to use.

[00:13:50] But, um, there are a few that really helps you up your form design game. Previously, like when you don't have those star rating and sometimes you know, of the business users, oh, can we do this? And it looks so good. It looks so nice. So you have to get that balance between beautifying your form on, does it really serve the purpose?

[00:14:17] Is it functionally good. So I'm not against, I actually like using PCF components, but I'm quite selective of what to use and I have to trust the person who did that as well and make sure I tested and tested well.

[00:14:36] You mentioned that there are users asking for star ratings, for example, do you leave it up to the users to ask for those kind of little whizzbang features or do you think it's the functional consultant's role to introduce beautiful UI touches even that the users might not have asked for? Or are we going too far by delivering over and above and making the system more complicated than it needs to be? 

[00:15:00] I like to keep it clean and simple. So only if it's really necessary that I would add in a, um, a fancy control on the form. Because at the end of the day, we're after the functionality, the data. It just adds into maybe, you know, beautifying the form. It just look at, make it nice.

[00:15:21] So it's not a must have, but a nice to have, um, for me.

[00:15:25] Good. All right. Well, you've answered all the questions I had from my current review that I'm doing. Thanks very much for that consulting input. I really appreciate it. What other principles do you cover in your presentation and what can people expect when they tune into your session at DynamicsCon? 

[00:15:40] Right. In my topic, uh, for DynamicsCon, I touched on the design process and the considerations. So, you know, what are the steps you need to do when doing the design, um, designing the form, what are the things you need to consider, your user base, their roles, that kind of stuff.

[00:16:03] And, and then I dig in into the, uh, I'm going to spill what I'm going to show. Um, I made my 10 commandments of a good design. So yeah, watch out for it. And, and then I shared some tips and tricks of form design. So those are what I normally use whenever I do my work. And, um, I touched us well, concluding the session all the PCF components and other articles. Articles from Amy Holden, she's got that posts around enhancing your timeline control. So I kinda like that. So I messaged her. I was like, oh, can I refer to your article? And she said, yes, go girl. So, yeah, I just, I put it that in. 

[00:16:59] And then I concluded my session with other UI components that you actually, you know, have a factor in delivering that better user experience. So like your navigation, the areas within the navigation. And I touched on the, the help pages, custom help pages, because 

[00:17:23] Right. That's usually overlooked in every project. 

[00:17:26] Yeah, so I, and there's a article about it, which is posted by Dian Taylor. I think she was in your podcast, like just last week.

[00:17:36] That's right. Yeah. She's also presenting. 

[00:17:39] Yeah. Yeah. So. She did, she did that post and I referred to her post and show a screenshot of what a custom help page looks like. And I quite liked the idea of using help pages because we normally, we're very traditional with user guides being somewhere else. So now we can actually live within, within Dynamics or within the form itself. And it's contextual, so it knows where you are and it loads appropriately.

[00:18:11] You mentioned there knowing who you're designing your application for and I think that's a great call. I've worked with some users who are brand new to business applications, and they're maybe going to be using it on a touch device, a phone or a tablet. And we want to minimize the amount of data that's on the form, minimize the number of fields and controls.

[00:18:30] Whereas, somebody coming from maybe a finance background and they're migrating into Dynamics 365 from a spreadsheet, and they're used to very high levels of information density. They love having lots of columns and rows and fields on the page. And you need to pack your Dynamics application with a lot of information. Otherwise, they're going to complain that it takes too many clicks to get all the data that they need. So that's a critical skill, I think is knowing who your audience is. 

[00:18:56] Yeah, it is. It is. Yeah, I think it all comes down to what really is necessary to be on the form. And sometimes I feel that users are kind of stuck to their old ways of doing things. So you need to make them realize that you're innovating and what will be the benefits for them if we do it this way, do it that way.

[00:19:20] And I think they need to see that benefit so that you get their buy-in. Yeah.

[00:19:24] How much work do you do on a typical project bringing your users along in the journey. Do you give them workshops where they can give you feedback on the user interface design? Or do you leave that all until the end, when it comes out in acceptance testing. What's the right balance with involving your users in that design given they don't always understand Dynamics or Power Apps to begin with and their feedback is often out of context? But that early feedback really helps you as a project team build up, you know, build a great application. Where's the balance there? 

[00:19:55] I'm really against surprising the users because that's just, it's not a good idea. I go and check in with the users whenever I have something substantial to show and just to always make sure that we are going the right track and the right direction. So for example, if you do a two weeks release, a weekly catch up on how things are. Will probably be in terms of the design form design. So you walk through them and show them where you are at and whether that's what they're expecting as a result of the workshops that you did. 

[00:20:36] And I normally, before delving into workshops and stuff, I do an overview of Dynamics. And in that overview, when you explain to them, or this is what we call a form, and this is how the Dynamics work, and we can do this, we can do that. Business rules can do this, can do that. So they can, they will have an idea of what is possible and they'll be able to, when they're doing the requirements, they have that in the back of their head that this is out of the box. This is not customization. And, you know, customization word is, um, yeah. 

[00:21:12] Oh, that's evil. You can't customize the system. 

[00:21:15] It's yeah. Especially from the vendor's point of view. So yeah, that that's money. So, yeah, it's good for them to know where to cross the line. 

[00:21:27] Have you ever had a situation in those workshops where there's conflicting feedback from two different participants? One user wants it to be on the left and one user wants it to be on the right. They can't agree in that workshop and you have to somehow wrestle them into similar position. 

[00:21:42] Yeah, that, that happens sometimes. But I think you just need to find the common ground between the two and prioritize what are your requirements? And what's the, what's the scale, or what's the priority? And then based on that, we can make a call or if you can't handle them then escalate.

[00:22:06] Yeah. I always like to have one person in the customer team, the product owner, who's got the final call for the user interface design and take some of these decisions to them and let them make the call on it. 

[00:22:17] Yeah. 

[00:22:18] Just keep on moving. You've got to keep the pace up and we can't spend all day discussing whether to put the buttons on this side of the form or that side of the form. 

[00:22:26] Exactly. It's not going to be the end of the world.

[00:22:30] So Mary Ann, if people want to follow you in the lead up to your presentation, where's the best place to find you and connect with you? Are you on LinkedIn or Twitter? Where can folks find you? 

[00:22:39] I'm on LinkedIn. I'm not on Twitter, but you can link me up on LinkedIn. Just search Mary Ann Castro. 

[00:22:46] Great stuff, excellent. Well, we'll make sure your LinkedIn profile is in the show notes. And as well as that we'll have a link to DynamicsCon so people can register and make sure they get there at 10:30AM on the 20th of September. 

[00:22:58] So make sure you get that in your calendar and learn all about designing effective forms for model driven applications and delivering awesome user experiences. Mary Ann, thanks so much for joining us on the Amazing Applications show.

[00:23:10] Awesome. Thank you so much, Neil.

[00:23:12] Thanks so much for listening to the Amazing Apps podcast. You can join the show's mailing list at https://AmazingApps.Show. You'll get a personalized welcome video from yours truly, and a notification when there's a new episode available. 

[00:23:29] There are also shortcuts so you can follow the show on all major podcast players and you can follow Amazing Apps Show on Twitter, LinkedIn, YouTube, Instagram, and Facebook.

[00:23:40] You can send me a message or a voicemail if you'd like your question answered on a future episode and even support the show through BuyMeACoffee or by buying an Amazing Apps t-shirt.

[00:23:50] Visit https://Amazing.Apps.Show. 

[00:23:53] Thanks again for listening. I really appreciate you. Until next time, take care and keep sprinting!