Jamie Ferguson
Product Designer / Sydney, Australia
Shorthand is a webapp allowing professional storytellers to quickly and easily publish stunning editorial features without code.
I joined Shorthand just before the product went into a closed Beta phase, late in 2013.
In my initial role as Project Designer I worked with customers to help design and build their stories in what was still just a very basic tool. I fed back any learnings to the engineering team in order to help them prioritise features.
As the tool evolved I moved into the Senior Product Designer role where I helped to conceptualise, design and build new features for the product. As part of what was still a very small team I was also involved in strategy and support.
As the company grew I was able to start building out the Design and UX function, taking on a Lead Product Designer role. My first hire was a UX Researcher, soon followed by a Product Designer, both of whom I managed. As a team we built out a more consistent, informed product design process that has enabled us to move from a scrappy bunch of individual contributors to a more cohesive unit within the Product team.
The primary concern when designing anything for the Shorthand app was simplicity. Where possible it should feel familiar or at least be as self-explanitory as possible. We believed the user should never feel overwhelmed with too many options up front so we focussed heavily on only showing extra options at the appropriate times.
Time and again, when asked for feedback about why they chose Shorthand customers said it was due to the ease of use in producing engaging and successful stories.
My role
- User research
- Ideation
- UI/UX design
- Prototyping
Case study Shorthand 'Projects'
The opportunity
As the product matured we noticed that many users were attempting to create multi-page stories and publications using a variety of workarounds.
With this in mind we set out to build a simple tool to enable our customers to create full publications as easily as creating a single story.
Process
Phase 1: Discover and define
Before this specific project started, I had already designed a version of that sought to solve just one specific part of the problem — how to easily build a ‘site’ in Shorthand. We developed a quick working proof of concept to test our assumptions, which was made available to some select users, both internal and external, who opted in to try it out and provide valuable feedback. We also did extensive competitor analysis which enabled us to better define the conceptual model and general requirements for the feature.
Phase 2: Ideation and testing
With a very tight timeframe myself and a second designer started an intensive ideation phase where we came up with as many ideas as we could in a few days and then refined them down from there based on stakeholder feedback.
We each worked on our own concepts then caught up to discuss where we were at and further brainstorm concepts.
After regular reviews with stakeholders we ended up with 3 concepts that we had some faith in. We then ran some user testing where each participant was asked to perform some basic tasks against 2 of the 3 concepts. We rotated which concepts we tested so we ended up with the least biased outcome.
Phase 3: Design and develop
Based on those learnings we proceeded with some concepts that combined elements that were successful in testing. With engineering already starting and a lot of stakeholders to satisfy we eventually narrowed it all down to one concept which we refined after a series of internal feedback sessions.
As the design lead, I did the final UI design in Figma and wired up a complex prototype ready for the engineers as well as actively working on the CSS and interactions in code.
Due to the timeframe we had to condense the changes down to just the guts of what the new feature required.
Outcome
We initially launched with an Early Access Program where we released the feature to a handful of customers, as well as doing some user testing with internal stakeholders who were fairly representative of actual customers. Based on that we fixed some bugs, made some iterative improvements and launched feature in early November 2022.
I set up a basic dashboard in Mixpanel to monitor usage but as it was still very early days it was hard to measure whether the feature was a success or not.
I finished up at Shorthand not long after this, but as the goal was to encourage our customers to use Shorthand for more things, more often, the key measures will be found in the number of published stories and engagement with the product as a whole.
Additional work
Some examples of the many mocks and rough concepts that I did while at Shorthand.