I’m not a software developer. I leave the coding to my co-founder, Tony Nicholls, and our dev team. But that doesn’t stop me from creating all sorts of user experiences in trellispark. When we decided to create a completely new customer portal for Great Ideaz, we decided it was important that I was deeply involved in defining the portal experience. In fact, most of the functionality was created by me without any developer support. How we created our customer portal using our trellispark platform is summarized below.

Step 1 – Created the Data Model in Less than a Day!

Since we already knew what data we needed to collect, we simply needed to configure the required form definitions and field definitions in trellispark. This is a super easy step in trellispark because it’s a simple configuration exercise using our UX Creator tool. We needed to define the following concepts in the portal:

  1. Basic customer information (e.g. company name, address)
  2. Ability to download the latest trellispark release
  3. Create a support ticket to get help from our team
  4. Sign-up for a training package
  5. Purchase a trellispark license
  6. Subscribe to our managed trellispark SaaS service
  7. Subscribe to a premium support package
  8. View any invoices and their status
  9. Create a trellispark demo workspace that showcases example user experiences using the platform

Each of the above was created as a different form definition concept. Each form definition was then populated with the appropriate field definitions required to collect and display information in the user experience. All the information for these forms and fields is configuration data in trellispark. There is no code that needs to be created or even code generated. This makes it incredibly easy to change, even after production launch.

Step 2 – Define State Transitions and User Access

For each of the features listed above, we needed to define the state transitions of a record. For example, when a customer selects that they want to subscribe to managed trellispark, the record starts in a “Draft” state where the customer can select which product they want, then submits it to change the state to “Active“. The record can also change to “Canceled” or “Expired“, etc. Different fields and information are displayed to the customer at every state of the record. There is additional fields that only Great Ideaz staff are allowed to see, such as some of the technical details that we need to track when a new managed trellispark environment is setup. All this functionality is a configuration exercise in trellispark that I was able to do myself. Actual effort was under four days.

Step 3 – Implement Workflow Actions

This is where I did require some developer assistance. Although I can configure buttons in the user experience that change the state of a record without any developer support (like when a user submits a support request), there are specific workflow automation activities that require a developer to create a “code fragment” stored procedure. For example, when a customer wants to create a new demo workspace, there is a stored procedure that runs to generate the new demo workspace environment. These custom workflow activities only took a few hours for our developers to create because they are all small and contained stored procedures and only require a few lines of code to complete the task. Its important to note that trellispark utilizes a data agnostic storage architecture and any custom stored procedures require very few lines of code since all the custom CRUD (Create, Read, Update, and Delete) code does not exist.

Another element to note is most of the functionality we have exposed on our customer portal requires workflow activities to be processed with our internal teams. So, in addition to the customer portal user experience, we also have an internal portal user experience that requires additional workflow activities as well as aggregate dashboard views of product and customer information so our team members can work efficiently and respond quickly. All this functionality and user experience comes practically “out of box” in the trellispark platform and was ready to go with just a few hours of work.

Step 4 – User Experience Refinement

I can be very “OCD” when it comes to crafting a desired user experience, and admittedly, this is where I often spend most of my time and where I can drive Tony and my colleagues a little crazy. I will spend hours attempting to get the right background shading or border spacing. The nice thing with trellispark is we provide lots of flexibility and control over how you can customize the screens to satisfy your inner perfectionist. All the fields are displayed in a grid layout. You can map your field definitions to an unlimited number of layers on the grid and an unlimited number of rows. You can span fields across any combination of rows and columns. And with a little CSS knowledge, you can customize your field styles to any color or special effect. I probably spent about two weeks getting our customer portal to look “right”.

Step 5 – User Experience Testing and Launch!

Another attribute that’s so powerful about using trellispark is how fast testing and user validation can go! Because all the forms, fields, state transitions, and user roles are configuration data and not coded; testing is focused on validating that the desired user experience has been achieved + any custom workflow automation. In fact, most of the “bugs” were fixed by myself by going into UX Creator and changing the configuration. It’s almost embarrassing to state that we probably only spent 2-3 days of effort validating everything before launch! That’s because, frankly, outside of the things I needed to correct in the state transitions or how certain fields were displayed, everything worked.

Making Future Changes

Since launching our new customer portal a few months ago, we have already made a few refinements and I’m sure at some point we will want to redo the entire user experience again. But the nice thing is most of the user experience is “virtualized” and defined in configuration data, which makes changing it about as easy as editing a spreadsheet or document. I can make the changes myself in our dev environment, then export / import the changes into our QA environment to validate that everything looks good, and then import the changes into production. And it’s easy for us to try out new user experiences, get feedback from our clients, and refine / replace it quickly.

Conclusion

Adding up all the phases of building our customer portal totaled about 4-weeks of effort for 1 person (less than about 160 hours). About half of this effort was my time working and refining the visual aspect of the user experience and ensuring we have the right contextual information, etc. This was an entirely custom customer portal that could have easily included lots of other custom functionality with very little effort. But what’s more impressive is the lack of actual code and technical debt. Nearly everything was configured without custom code. And by eliminating the code, it means we can rapidly change the user experience without expensive development cycles. This also means we can quickly add or change different products and services anytime and service our customers better.

If you would like to learn more about how you can achieve similar results in your organization, send me a direct message through my LinkedIn profile, or contact us, or send us a quick email at info@greatideaz.com.