Protecting data integrity
Verify & lock data
Currently in the application the user can release and unrelease certain sections.
Releasing a section will make the data not editable. In some cases, having specific sections released is a prerequisite to perform a certain task. For example, an invoice cannot be approved if the accounting data is not released.
Tools
Sketch
Role
Researcher
Designer
Deliverables
Workshop material
Research conclusions
Concept and final design
“The release functionality is used for non-verification required sections. It would be possible to split the release functionality in two separate actions: verify and lock, giving the customer more freedom to match application processes to business processes”
— Hypothesis
Research Questions
#1 Are there users that release data but don’t make changes to the data?
#2 Are there sections that are released more than some?
#3 How does the release behavior for different customers compare?
#4 Are the users releasing non-essential sections?
#5 Are releases of sections driven by software requirements or by business processes?
Scenario definition
As a starting point we mapped different scenarios and flows that users would go through during releasing or unreleasing certain sections of the application. User representation was done keeping in mind company size, team size, user data access, and relevance of the section (essential or non-essential) that was to be released.
With the help of the internal support team, we created a total of 10 representative scenarios for the Release functionality.
Release is mandatory
Release is optional
Small
Medium
Large
User data access
Team size
View
Edit
Release
Unrelease
Viewers
Editors
Reviewers
Company size
Non essential sections
Scenario analysis
Per scenario, it was relevant to mark down which actions the users were able to take per scenario, either read, write, release or lock (in case the section was non-essential).
After that, we identified users that were performing the same actions in different scenarios, which was a key elements for defining the user types.
Defining user types
The nature of the release functionality on its own implies two different user types:
Editor: user that edits the data
Editor/releaser: user that reviews, edit and verifies the data
However, our scenarios suggested that there could be 2 more user types:
Releaser: user that verifies only, no edit permissions
Locker: user that locks the data, to protect it from edits
Releaser
Locker
Editor / releaser
Editor
Data analysis
-
Usage per application
We analised the usage of the release functionality per application section. The results confirmed that the release functionality was used for non-essential and essential sections.
-
Users releasing per section
Before start looking at the users involved in editing and releasing sections, we narrowed down the sections to have five non-essential and three essential.
-
User type identification
After that, we analysed if our 4 different user types we performing actions in those sections.
Final user types
Data suggested that indeed users were releasing non-essential sections, which means that users use the release functionality as a locking tool, just to make sure the data is not edited.
Moreover, even though in small numbers, we did find users that released data without having an edit permission.
The data analysis served as a very strong foundation for design conceptualization and research.
Editor
Editor / releaser
39 Releasers
Maximum number found for essential sections
25% lockers
25% users locked non essential sections
Design research
Knowing the user types, the next logical step would be to understand how the release functionality was used and how the verify and lock functionality would solve potential issues of the Release functionality.
For answering these questions, we performed a series of questionnaires, workshops and user tests, were we iterated the design solution. All activities were performed with carefully selected end-users.
Final Design
The Final Design was created so that it solved the user needs found during the Design Research phase: flexibile, easier to access and interact with, non-obtrusive. Moreover, both verify and lock functionalities are equally important to the users.
The proposed component embraces both functionalities: verification of data, and locking data (from being edited). Splitting the functionality also brings more flexibility for user with different data permissions.
The design solution was add-on to the current submenu navigation panel, and could be inserted in any application that would require this functionality.
The placement of the element portrays that the functionality is not used in a regularly, but it still provides easy access to it.
Verify
Used for assuring the integrity and the quality of the data per section
Verification requires a specific permission
Edit actions from other users will immediately unverify the section
Lock
Used for protecting the data from being edited by other users
Locking requires a specific permission
Unlocking requires a specific permission
“I would use lock functionality for things that are not ready yet. I would use the verify functionality when the things are finished and ready. Seems like a good path to me!”
— Participant quote