Loading...

simPRO Prebuilds

Project done with simPRO Software

UI/UX Designer for the Projects Squad:
Team responsible for the larger releases in their star product: simPRO Enterprise.

Key Deliverables in this Project

  • IA / User Flows
  • Wireframes & Prototypes
  • UI Design Solution
  • User Testing
  • Development Documentation
  • Look & Feel Test Cases
  • Duration 6 months (2017)

    Project Overview

    So let’s start with: What on earth is a Prebuild?

    A Prebuild is a ‘package’ of items. It helps you to arrange elements faster depending on the elements you work with (Eg. a ‘Residential Powerpoint’ prebuild would contain 1 mt of cable & an electrical switch from your stock + an hour of labor from one of your staff, for example). It allows you to assign the items you need for a quote faster, instead of adding them individually. It makes stock management and quoting easier.

    Brief drawing of a prebuild
    An illustration of what a Prebuild is

    I'll be dropping some comments regarding the process around this area

    We were able to collect the insights of the challenges through the following methods:

    • Ideas portal
      Users submitting requests for specific features
    • Implementation staff
      detecting patterns when assisting users with their implementation
    • Customer support tickets
      Tickets raised requesting help with this section

    Challenges

    Oh, and we had so many! As powerful as a Prebuild already was, there were a couple of limitations this section had:

    The prebuilds only allowed to store very basic information about an item. It was mostly: name, part number, description, a simple way of calculating installation prices and a section for attachments that was hidden in a separate tab.

    We detected that users wanted to store more information regarding each prebuild. How did we detect this? Because as we perused around some of their builds, we detected that the Prebuild’s attachment section was full of random documents. Photos, PDFs, guidelines - you name it. Users were uploading heaps of information in that random attachment section hidden in this feature. With a simple query around random builds we were able to detect that there was actually a significant amount of storage spent in the attachment section of this feature, so that allowed us to identify that probably a lot of users were following the same pattern.

    At the beginning of the project, we identified that Prebuild’s attachments were becoming a very messy area of the system because we were not making the changes our users needed.

    At this stage, another team was developing a Sales App that required the Prebuild’s data to generate quotes on-the-go. It was very important to get the right content of this feature right, cause all of it would waterfall to the Sales App too.

    As an extra element, we should cater for scenarios where users had different hierarchies and editing rights over a Prebuild. A business owner had a very different need when interacting with a Prebuild in comparison to an electrician that is using it as a reference on site for installation, for example.

    Personas

    The software can be customised in many ways, adjusting levels of ‘visibility’ for each type of user through the system setup. For the purpose of illustrating the differences between visibility depending on the needs, here we can find the personas of users that have a high hierarchy (full visibility) , mid-level hierarchy and low-hierarchy (low visibility).

    Support Materials
    Three different Personas that represent a sample of the different type of users and their level of visibility in the system

    UI/UX processes were mostly already predefined by DevOps manager & our UI/UX Lead, so depending on the project size more deliverables would be expected.
    Some projects (the larger ones) would have longer iteration processes to validate that the solution was adequate, while others (the smaller ones) would have a very short iteration one.

    Process

    The early stages there was a lot of bouncing of ideas between the Product team (Product Owner, Business Analyst and myself). In this step, we would get the implementation trainers and few clients involved, to collect insights regarding what we needed to include. Implementation trainers were a great asset to inform our process, because they were regularly on-site, helping users implement certain features and giving them constant follow-up.
    Once we were able to define user stories and user flows, we included more team members in the loop. The First Loop of Iterations (lo-fi prototypes) was used to generate different concepts and ideas, test different arrangements of items and in general to define if the user flows made sense. For this stage, I prepared what we needed to perform heuristic evaluations with some of the people inside the organisation and a remote user testing evaluation.

    Prebuilds Process
    Evidence of Remote User Testing (Screen Recording) done during this process
    In the remote tests we tracked user journey, heatmaps, and success rate of the tasks assigned. Most of my participants were people inside the organisation located in different parts of the world.

    The Second Loop of Iterations(hi-fi prototypes) was used to do usability testing with some of the staff, implementation consultants and few clients to validate if the solution made sense for the people that interacted with the system the most.

    Prebuilds Process
    Screenshot of Heatmaps generated during the user testing process

    In this iteration loop we also detected some scenarios we missed previously! How could we handle cases where there were no images, no description/notes and Prebuilds were opened in read-only mode? We had to create few logic decisions so the UI could handle these scenarios the best way possible. That meant hiding complete sections and rearranging elements depending on what was empty or not (the developer who implemented this is a genius).

    Once that bit was cleared, I prepared a handover with the Developers in my team, preparing everything they would need for implementation. At this stage, I also generated the Look & Feel test cases needed for the QA process. This last Look & Feel stage was done as one of the last steps of development, where I was able to evaluate that the feature was behaving as expected, following the expected functionality and matching the UI specs.

    Prebuilds Process
    The Process we followed to develop PreBuilds

    Solution

    We divided the Prebuild in two segments: Description and Pricing Calculation. Depending on your editing rights, you could potentially edit or view any of these two sections.

    In the Description section, we kept the Name, Part Number and Description. We added an internal notes section, the ability of adding a cover image and supporting documents. This supporting documents section was categorized depending on the most common types of documents users used to upload already in the existing attachment section.
    The attachment section was still around, in a separate tab. Existing attachments could be used inside Support Materials. Here, users could categorise existing documents or add them under each label, for better control and management.

    In the Pricing section, we introduced a switch so users could either assign a flat rate price or a standard price. We also implemented a graph where they could visualise the profit and margins they would generate with each Prebuild. This Pricing Calculator would be visible only for higher level hierarchies among the system.

    As much as I would love to share a detailed prototype of the solution, I don't want to get in trouble for showing too much because #copyrights. Instead, I'll leave here the link to their help guide, which includes a video with a walkthrough around the feature: PreBuilds Help guide

    Feedback usually was collected either by the implementation team, clients and staff in general.

    Feedback & Improvements

    Support Materials
    Description Section in a New Prebuild, full editing rights

    The good things
    In the Web Based solution:
    Users with full editing rights in general loved the implementation. Having the pricing area graph helped them to understand the markup and profit for each prebuild in a visual way. They felt more confident adjusting the pricing depending on the complexity of a PreBuild having that tool. The ability of adding a cover image and support documents arranged by type meant that information was more organised across the products (web based and app).

    In the Apps:
    The full integration with the apps meant that any information added in a PreBuild could be visible to people on site very quickly. Having access to their support material meant that they could easily find the attachments, guidelines or even installation details without jumping out of the app to do so.

    Support Materials viewed inside the app

    The 'not so' good things
    While for higher hierarchy users, the solution worked fine and matched their expectation, users with lower hierarchy (read-only view) still experience a very basic interface which wasn’t really engaging. In scenarios where images or support materials were not added, there would be almost nothing in this screen which made it appear a bit pointless.

    The users that already had a lot of information in the existing Attachment section weren’t completely happy either. The fact that they had to go manually and add them inside each label meant an extra layer of work. There could have been a smarter way for us to match an existing document type with the new labels (Manual, Brochure, Video, Other) and automatically grab them to populate the Prebuilds. Something to work on in the next iteration, if there is one.

    Topics covered in this project:

    UI/UX, HCI, Web Based Design & Mobile App integration, Usability