Through years of collecting feedback from customers and users, we determined that a large percentage of our webapp product’s usage was in factory floor environments. These environments were often loud and with lots of distractions, and could sometimes include moving parts that had the potential to bump a touchscreen monitor running this product.

We chose to stick with a pattern that was familiar to our factory floor users when determining how to address this problem. A common pattern that many OEMs in our industry use is to require an access code to access certain features that should otherwise be locked.

After validating our approach with one of our key customers (and one of the originators of requests having to do with this feature), we go working on ironing our the requirements.

---

Requirements

• Users should be able to access the webapp through various access modes
  • In our case, we chose to go with
    • Readonly: No fields are editable, but all fields are still readable when this mode is enabled
    • Standard: All fields are editable, except for those flagged to only be editable in advanced mode. Advanced mode-only fields are not to be editable, but should still be readable when this mode is enabled.
    • Advanced: All fields are editable when this mode is enabled; 4-digit access code required to enable this mode. Mode times out and reverts to standard at the end of the configured inactivity timeout period.
• Different access modes will have different features/fields editable or readonly
• Top level access mode (in this case, Advanced) should require an access code to switch from other modes.

---

General Implementation Plan

In order to get this feature ready for development and core pieces of it deployed as quickly as possible, we chose to go with a 3-part approach:

• Part 1: 3 modes (readonly, standard, advanced) are hardcoded in based on [Customer name redacted]’s requirements
• Part 2: Users can configure which fields are readonly in standard mode using the webapp UI
• Part 3: Users can add and remove modes, set access codes for modes, and/or rename modes

The designs and specs for each part would be completed and then handed over to developers as soon as they were ready. While developers worked on implementing the part they now had specs for, designs and specs for the next part would be worked on.

---

Identifying User Flows

In collaboration with the Product Owner and the Applications Engineer who was paired with one of our key clients that requested this type of functionality, we identified which user flows we should accommodate via this feature.

Here is an example of one of the resulting user flows:

This flow went through a few iterations to achieve the result shown here. Reviewers included Applications Engineers (who were embedded with customers and so had good insight into customers’ needs surrounding this feature), our development team (to ensure feasibility), and our product owner (to ensure that this feature aligns with product plans).

---

Resulting Designs

Part 1: Predetermined, hard-coded access modes with the ability for users to switch between them; access code required to enable Advanced Mode

This part of the feature has been implemented successfully.

Part 2: Ability for users to configure which fields are readonly in Standard access mode via the settings UI

This part of the feature had been handed off and was in the process of being built at the time of my departure from RTR.

• 

• 

Part 3: Ability for users to add, remove, and set access codes for access modes

The designs for Part 3 were prepared for handoff to development in time for my departure from RTR. I am unable to post the designs here out of respect for the NDAs I have signed.