These past few weeks have been incredibly busy. I actually didn’t have a chance to post anything last week because of the busy schedule of developing. That and the six-week old addition to my family. This last week however proved to be one of the most fruitful. Not only am I gathering requirements, designing solutions, developing and deploying at an unprecedented rate using Mendix, but I slowed down long enough to actually use the application. The insight was invaluable and something I’m going to spend a few minutes describing so that you, too, will remember how important this is.
In a RAD (Rapid Application Development) environment, the process unshackles the team of developers, business users, analysts, testers, and trainers in an unprecedented way. Gone are the days of creating administrative overhead for the sake of, well, CYA. Why should we impede progress if only to document some supposed requirement that we know is going to change the moment the business user has the request available to them? That’s not to say documentation doesn’t exist; rather, we capture and progress in a different manner by following SCRUM methodology. This alone accounts for some of the time-to-market performance gains a platform-as-a-service offers. The rest comes from the ability to create responsive applications without the monotony of looking for semi-colon errors in our code.
Something that is easily overlooked when developing new features and fixing bugs in this rapid development is remembering to occasionally use the application we are building. When was the last time you logged on to your application to use it from start to finish and deal with the UX you have created? After you get something up and running you as a developer tend to complete story after story, focusing on unit testing only and never end-to-end experiences. This is a mistake.
Business users are really great about telling you what isn’t working. Especially if you’ve added in the ‘Feedback’ widget so they can attach screenshots. Your users will really take advantage of this if you a) market it to them and b) BE RESPONSIVE! If you actively monitor the feedback, process it, and engage, they see real value in providing it because they realize they are being attended to. Otherwise it becomes a black hole that no one wants to use, and you do not want to lose this valuable communication loop. But what business users are not necessarily great at is communicating how things could be better.
Believe it or not, developers who actively stay current on industry trends, UX and UI research tend to know how features and processes could be made better much more so than your business users. What I uncovered yet again by stepping through this latest application from start to finish through all of the features was that there were many features that myself or other team members had designed and implemented as an isolated story that really needed a fresh look to enhance the user’s experience. Because it is so easy to extend and enhance your application piecemeal when working with a PaaS, we can get caught up in ignoring the integration of those pieces and mindful of the UX we are holistically creating.
While I took a fresh look at this particular application, I realized that our Administration features were a mess. We have spent a lot of time worrying about the primary application user’s experience, focusing on getting that process down pretty tight, that we essentially ignored what our administrators had to work with. Sure, we built them the tools necessary to manage and monitor the work being done by the end users, but there was virtually no thought put into the UX of an Administrator. For example, when setting up a new Department to use the application for the first time, we knew there was a process that involved adding the department, setting associations to new accounts, leveraging existing master data, etc. We built all of those features so that a new department could be created and setup in the application. However, unless you were one of the developers who built those features, you would never know as the Department Admin what button to press and in what order to successfully complete the setup process. This all became apparent as I stepped through the application.
Additionally, things we thought had been buttoned up and tightened down were not so in the greater context of use. For example, this application has a feature where data from SAP needs to be attached to a workflow ticket in our application by a credit card holder. The SAP transaction stores the Cardholder name, and our application stores that same name in our Account, yet we would ask the end user to manually link those two pieces of information in a certain case. We can easily automate this process by looking up that Cardholder’s name and retrieving that Account to link it without interaction and bother to our end user. They didn’t know that was a feature we could build so they weren’t coming to us with those sorts of UX enhancements, but it’s something as a developer I could blatantly identify as a quality of life enhancement.
The other key thing about using you application is that while you are using it, you can monitor your Console log in the Business Modeler. There are events that will trigger that throw a warning in your Business Modeler that a user would never notice. I had one, for example, where upon loading a page a Microflow was being called but the user didn’t have the role that allowed them to call that Microflow. The application is ‘smart’ enough to restrict access in the event of a conflict. The business users never saw a problem, but a warning was getting thrown in the Console because the visibility suppression rules weren’t correct on the Microflow Label Widget in use on the page. You certainly could write this off as a good job on the application for being smart enough to not show them the data since they technically didn’t have access, but I consider it to be bad coding. You don’t want your application throwing warnings because it means you’ve created overhead: efficiency’s biggest enemy.
This wasn’t a how-to guide that tends to be the most popular thing I write, but a call to developers out there to remember to step back periodically and use your application. You’ll be amazed at what this simple act will uncover, even if you think everything is working perfectly. Remember, you can always make things better.