1. Users find a graphic interface more intuitive than a text based interface

2. The target literacy level is beginner children (PreK - lower elementary)

3. Child users have access to a teacher or other helpful adult who can read documentation and troubleshoot

4. Users will likely be using tablets

5. Users intuitively understand the ways to delete each element type (undo, drag off screen, press and hold)

6. Users find small icons accessible due to this age group’s dominant traits of good eyes and small fingers (a zoom feature is not a requirement)

7. Users remember what they learned in documentation and don’t need to open icon descriptions while building a project

8. Color coding is a clear differentiation marker between buttons with different functions.

9. Buttons/icons are intuitive to understand and different enough to easily distinguish functionality

This redesign targets the assumptions that “Child users have access to a teacher or other helpful adult who can read documentation and troubleshoot” and “Users understand intuitively the ways to delete each element type (undo, drag off screen, press and hold),” and it also somewhat addresses the assumption that “Buttons/icons are intuitive to understand and different enough to easily distinguish functionality.” 

It is consistent with the assumptions that “Users find a graphic interface more intuitive than a text based interface” and “The target literacy level is beginner children (prek-lower elementary)” because it does not introduce additional text. 

In the exclusion scenario, Valerie encounters this pain point because currently, to remove a Sprite added to a project or a backdrop page from the animation sequence, users can tap and hold the element, and the element will start to shake and a red X appears on the upper left corner of the element. Users can tap this X to delete the element. This sequence is not as intuitive as it could be for the users of Scratch Jr. because there is not a visual cue that pressing an element will make it possible to delete it. The ux seems to be based on the iphone app removal ux, where widgets eligible for deletion shake. 

Meanwhile, if a user wishes to delete a code block, this press and hold, X method is not available. Users can drag the code block out of the program writing section of the screen to any other area to delete it. With all element types, an undo button is available, but it is difficult to distinguish from the “return Sprite to starting position” button. 

The easy, graphical solution is to add a trash can to which users can drag any element they wish to remove, while keeping the undo button. The trash can icon is in the same child friendly graphical style ScratchJr employs throughout the UX.  I placed it near the undo button because of its somewhat related functionality. When an item is dragged towards the trash can, the lid will open indicating that the element can be dropped there. This trash can will include a sound cue that indicates an element has been placed in the trash. If a user makes a mistake, they can use the undo button. 

This redesign makes the new assumption that skeuomorphism is a clear communication tool (NN Group heuristic “Match Between the System and the Real World”) and that options should be visible (NN Group heuristic “Recognition Rather than Recall: Minimize the user's memory load by making elements, actions, and options visible”).