Goals

Design a writing tool capable of being used by both writers and designers, that could interface with Unity and allow for full story creation, editing/revision, and technical scripting. An online component of the tool would also access a server to store data and ensure a source of truth for catalogs and scripts.

Challenges & Constraints:

There would be very limited engineering time available for work on the tool during the first the minimum first implementation. This meant it would be lacking implementation of many features at first, but still need to be as usable as possible.

Another challenge was the ongoing parallel creation of the content tools inside Unity, and the fluid nature of the process after writing, as the content team was still exploring workflows and solutions.

Brainstorming and Research: 

A core section of our team spent a long time figuring out the technical and practical requirements for the tool. This included what data would need to be created and modified, how that data links together with the final scenes in Unity, and how to best protect data when multiple users were working on the same file or story.

I researched other existing story creation tools to see if any of them could be usable or provide inspiration. Many were capable, but had serious problems for our case, such as:

• Focused on a small number of story branches, mostly linear stories

• Too complicated for frequent use by non-technical writers and editors.

• Lack of robust condition or scripting support built-in.

• Easily visually overwhelmed when working on larger files.

• Didn’t support navigating the story easily, or required mouse interaction to do common tasks.

This led to a deeper understanding of challenges we faced and pitfalls to avoid.

Next I interviewed members of the writing, editing, and design teams in small groups or one-on-one, and collected data on previous writing experiences, how they used existing tools in the past, and the process our writers used when creating stories.

These interviews were great for getting into the mindset of our target users; what the usability expectations were, what other programs they were already familiar with, and what actions were the most commonly used in those applications. Some key takeaways:

• Microsoft word was the standard for our writers and editors. This informed what common actions and shortcuts would already be routine for them.

• Most of our writers used the mouse only when absolutely necessary, and worked often on laptops away from their desk or at home.

• Moving lines around in the structure would be needed, as revising was going to be necessary throughout the workflow.

• Writers, editors, and designers, were all going to have different goals in mind when using the tool.

Task groups of Internal Users broken out, based on the 3 unique goals and positions of team members. These were based on both interviews and the technical guidelines, along with stakeholder discussions. Because of our small team size and internal usage, I did not create full personas, just groupings of tasks and user goals.

Process:

With the different user goals in mind, I laid out the basic structure and navigation, grouping together common actions and pieces of data.

After creating several simple user flows based on the most common expected entry points and goals for different users, I sketched out several types of views for the main scene/script interface.

Along with some simple interactive prototypes, we quickly refined the main story view and I started building the design for the rest of the tool.

Revisions:

I was able to get interactive mockups and a simple prototype of the first full design in front of writers, conducting a limited usability test as they navigated the prototype to reach their goal. We discovered a few areas that needed to be improved, and further refined the design, adding features to help navigation, and deciding which features could be left for a later date.

At this point, the final design of the first version was built out as a web app as much as time and engineering constraints allowed. This first version was successful at our initial goals, and allowed the writers to start creating stories in the tool.

After a few weeks, I conducted more surveys, in person and over the phone, along with contextual interviews, watching the writers use the tool in their normal work space. I was able to identify many pain points that could still be improved. Some of the solutions to them included:

• More in-script widgets and error messages

• Improved navigation and shortcut hinting.

• More robust find/replace feature.

• Expanded collaboration tools.

Using this, along with changes in workflow from further down the pipeline as the team started building content, I created an updated design of the tool. I built a more robust prototype of this version, covering all the main user goals.

Results:

The updated design prototype was met with very positive user feedback and user testing, and was in the process of being implemented as much as possible with engineering time constraints and deadlines. 

Storyscape was shipped on time, with no serious issues on the writing/editing timeline or workflow. The scripting workflow still had many pain points however, many of which had been documented and addressed in updated designs, waiting for implementation. 

By this point the Writing Tool had been in use by a full team of writers, editors, and a handful of others for about a year.

Unfortunately it was around that time that Fogbank was shut down, and Storyscape was taken offline.

Conclusions:

While the Storyscape app itself was short lived, it was a huge project with more moving parts, interlocking systems, and pipeline tools than I’ve worked with before. The writing tool was the first serious internal tool I’ve had the chance to work on, and unlike anything I’ve done before. 

Some key experiences:

How to better tackle qualitative research and evaluate it with a critical eye, uncovering the reasons behind user’s answers or behavior. 

Designing for a set of target users that either doesn’t yet exist or is very small. This meant sometimes having to trust my intuition, or designing for workflows that are speculative.

Involving multiple teams early in the process, including engineering and content, under considerable technical limitations and shifting requirements.

Overall I’m very proud of the work that was done on it, and it was a great learning experience.