Rob is a product and multidisciplinary design leader with over 20 years experience building things you’ve probably loved.
Building for small business through data-driven account-tech
Small business has a big problem. They’re high risk. They’re so high risk that the majority fail within five years of incorporation. The reason that the majority of small businesses fail is complex. Some simply fail because their owner isn’t good at business. Some fail because the market rejects their offering. But if you have a business that is viable - and you have some business acumen then your biggest risks are - making bad decisions and a lack of access to capital.
Most business owners make bad decisions, not because they don’t seek out good advice - but because they don’t have the right numbers in front of them to make a good decision.
Most business owners lack access to capital because, as a whole, small business is high risk. For a bank or lender, the general risk is often not worth engaging with. For a viable business, they lack the ability to de-risk themselves from their contemporaries. Risk is a numbers game, and the house always wins.
Quota was founded to resolve that weighted bet, and it resolves it through providing small business owners with SPOT - a single point of truth in their business data, that can be verified by banks and lenders and underwritten by accountancy professionals.
Accountancy professionals are uniquely placed to validate small business data. They’re also uniquely trusted by banks and lenders. Accountancy professionals are also in a race to the bottom - stagnant pricing and the threat of AI is undermining their business models, and their only respite is to move up the value chain towards offering services that mom and pop bookkeepers cannot offer.
So the problem space Quota finds itself in is rather unique and multi-sided. It serves the small business owner, it serves the lender. But it also serves the accountancy professional. And it is the accountancy professional who ultimately drives Quota - in both its legitimacy and reach - to the small business owner and the lender.
Quota is a heavy data product. It’s also a finance product. It’s a product where precision wins and errors can cause real life pain. It relies on complex data connectivity with dynamic ledgers and bank APIs, and it requires incredibly deep categorization models to provide the insights required by those making large capital decisions.
In short, Quota is Bloomberg Terminal for SMB. But it’s a Bloomberg terminal simultaneously used by a highly qualified accountancy professional and a business owner with a financial knowledge largely limited to ‘number go up’.
My role on Quota was broad and it encompassed leading Product and Design from the position of co-founder.
Quota allows Accountancy professionals to quickly onboard businesses through automatic connections to QBO and Xero.
From there, Quota automatically maps the history of the company using a proprietary codec called QCS. QCS is a complex beast of a codec that required very stringent information architecture. That architecture then is able to generate a parser logic, which can be leveraged by AI query engines.
This complexity is hidden in Quota - the categorization, the logic paths - to generate a smooth onboarding experience where the Accountancy professional is able to input, connect, sync and categorize any small business in under four minutes. Quota is also able to handle interdependency between types of businesses, industries and connected businesses, such as franchises and groups of companies.
This means for the Accountancy professional, businesses can be compared, reports generated and up-market advice created at-a-glance. However the big win for most Accountancy types is the way which, thanks to the QCS codec, any business on the platform is instantly compiled. A compilation in most industries is the financial standard for investment of any type, and for most Accountants, a compilation is (a) time consuming to produce (b) has very slim margins and (c) is immediately out of date at the point on compilation. Quota provides real time compilations for every connected business.
QCS also powers the finite details behind equations. It’s able to show past and future trends per equation with tabular detail.
For analysts who require additional details into individual numbers and QCS outputs, X-Ray mode provides the granular breadcrumbs. With X-Ray in QCS the analyst is able to leverage QCS to ‘no code’ the ledger. The AI agent QAI also leverages this X-Ray layer, able to allow for general prompts by both the Accountancy professional and small business owner.
What’s fascinating about Quota, and QCS as a codec in general is the power that exists within the codecs ability to find patterns within the abstracted data - and for that I thank the analytic mind of my PM Jay Dort. This allowed us to build smart budgeting tools based on prediction models, effectively running spread-bets against a company ledger, and allowing QCS to amend its variables when the budget was made actual.
The most interesting thing for me with Quota was the creation of flows. In product design and product generally, we talk about flows in terms of usability and execution. What you can see. What is tangible. What is human. In Quota those flows are the data itself, and the usability is determined by the way by which that data is not only presented but how that data is referred to, architected and made accessible in a variety of deep-use cases. The product challenge then becomes understanding the data layers, understanding where the leverage is and understanding what is possible.
In many ways QCS - and Quota - is a pure design product, but a design product with no true visible render. Where the aesthetic is the function and that function can be anything.
I intend to write more about QCS and Quota in the near future.
Building and incubating Products for capital-G-Good with MTR Labs in Hong Kong
The first half of 2020 sucked - I think everyone can agree on that. Projects got derailed, paralysis kicked in, diaries emptied, products died. In the second half though I’m trying to make up for that a bit - I’m excited to be working with MTR Labs in Hong Kong who have started a new incubator focused on Products for Good, with a focus on investing in Green issues, Transit technology and more. It’s early days but I’m excited to see what gets built and I’m happy to be lending my product skills to a new cohort of entrepreneurs. Thanks to Gene Soo who is always a pleasure to work with on basically anything.
Launching a rewards network for people under 30 that raised $60M in one year
As VP Design at Verve, I oversaw a lot of product elements, comms and users. Verve itself as a Saas is a complex beast - it allows you to sell event tickets to your friends to get rewards. This sounds simple enough, but with events spanning from sports to travel to festivals, with ticket integrations like Ticketmaster, See Tickets and more - and multinational e-commerce - US, UK, Germany, Belgium to name just a few, the amount of possible user interactions become huge. A user booking a sports ticket for 3 friends and wanting to choose where they sit is vastly different to someone buying a festival ticket and needing the tools to sell 30 more.
The one consistency across the Verve universe was the concept of rewards. You sell X tickets, you get Y reward - it became core to the user interactions on the site, and we saw it becoming a core driver for both acquisition and retention. Your average Verve user sells a few tickets and will probably earn themselves free access to the event - for these users this is realistically their end goal. Free is a great driver and for many it allowed them access to events they usually couldn’t otherwise afford. What we noticed though was there was a growing super user group who didn’t stop at a free ticket. They wanted more. They leveraged their social networks like an influencer, and had generated an extended reach. We wanted to build a product that could harness this super user behaviour and turn these self-made ‘influencers’ into acquisition channels. We did this through the creation of Pollen.
If Verve was a Series B, 200 headcount, in-rev company, Pollen was a pre-seed startup. We had user data, 100 users and some limited resource to hit MVP.
My role as Design Leadership in Pollen was possible due to the amazing work of Antony Shaw and Peteris Bikis. Hire those guys. They’re very very good.
The Problem
Can we take the power users we have on our existing platform and, through a combination of behavioural nudging, CX support and exclusivity, deliver a rewards network that enables higher sales per user, higher retention, better network driven promotion and cheaper acquisition? To solve this our definition of success would hinge on a few key metrics - on the quantitive side we’d look at GMV, NPS, Campaigns Joined (a user must join an event campaign to sell tickets for it) and Dwell Time (time spent inside or discovering a campaign). Qualitatively we’d look at the feedback we’d get from the CX teams, the semantics of the interactions, and we’d run face to face events to align to our testing - at the events our users were selling for. This last point was key to solving the desire lines in the product, as we saw event attendance as the last part of the user flow.
Pre-MVP
Because Verve is by nature a white label platform - it allows clients to rebrand their Verve site to match their event of campaign - we began initially by using this as the basis for what we were now calling Pollen. This allowed us to first of all test the flows we already had created in Verve, and work out which would be repurposed, but it also allowed us the ability to begin approaching the market with something to show. If Verve is a single sided marketplace through it’s white labeling, then Pollen, with it’s own branding would be a double sided marketplace - we needed users and events to transact at the same time. Without events we couldn’t get users, without users we couldn’t get events.
Reutilising existing flows and product elements was key in initial acquisition
This pre-MVP approach allowed us to begin building acquisition channels and gave us the breathing room we needed to begin brand and product scoping without blocking operations and sales. It also allowed me to quickly create pitch environments for client side partners.
Brand is everything
Building brands for the under-30s market is easier than it’s ever been in terms of broadcasting, but tougher than it’s ever been in terms of communication. Channels like Instagram, Snap, TikTok have given brand and content publishers the ability to reach people visually, way beyond the known limitations of Facebook. Paid acquisition is more impactful, and the organic story features with a focus in video and image get significant reach if done well. In researching these channels heavily with agency The Big Thinks, we defined some key focuses for communication:
Authenticity - Facebook has killed trust, and users are more cynical than ever before. Truth is king, and it has to look genuine - no gimmicks, nothing that can be conceived as BS, transparency is key, be bulletproof, but not to the point of being arrogant.
Don’t look like a pyramid scheme - Seriously, open up your Facebook and find one old school friend not trying to recruit you into a dubious scheme selling protein or moisturiser or something. Users are tired of this ‘friend drag’ and see right through it - in fact this came up again and again in our qualitative research. If it’s too good to be true it usually is, and the people your want to acquire will write you off as a scam. If your friends is offering free tickets on your feed and all you have to do is ‘click here’, people turn off.
Vibrancy - Seems obvious but not to be overlooked. Vibrant content really stands out and can act as a Trojan horse for complex messaging and boring terms and conditions. It’s actually hard to find good, vibrant content - people talk about their content or story being vibrant, but in truth it rarely is. Just because something is colourful doesn’t make it vibrant, and maintaining vibrancy from acquisition to process to retention is unbelievably hard to do.
Elevation - AKA ‘aspiration’ in some circles, but rarely is UX or CX ‘aspirational’, so ‘elevation’ it is. Elevation is usually the missing piece in product and brand flows, and it’s the oil in the engine. You can ‘nudge’ users and force desire lines, but elevation is more effective if it’s baked into the DNA. It’s the ‘too good to be true’ with real Authenticity and ‘not looking like a pyramid scheme’. It’s also incredibly difficult to define and needs to be user led.
I’m not immune to the brand think cynicism and it’s sometimes hard to type brand think into product design without feeling a little like you’re talking fluff to logic, but time after time I’ve seen products fail over and over again due to a lack of foresight and ‘feels’ when it comes to user acquisition. Acquisition is a lifeblood, yet it’s often talked about in terms of part of a paid strategy and usually nothing more. If you want to encapsulate a true sense of usability and elevation in a product, you have to have some mind in brand and marketing. This blending of the marketing and product, the ‘cross-pollination’ if you will that I was able to place into the teams at Pollen, in retrospect, was key to its organic success. Why? Pollen never lied, and its marketing and voice never wrote a cheque it’s product, CX and real-world presence couldn’t cash.
If Marketing and Product converge (which they should) on one action it should be ‘managing expectations’. Marketing should not be acquisition at all costs, nor should Product be ‘execute flows on the acquired user, everything else can be dealt with by CX’. One of the biggest issues I think we solved at Pollen was applied constraints. While it’s easy to promise the earth and tell the stories you want to seal the deal, it creates a falsehood where the brand overtakes the product and disappointment or suspicion gets seeded in the community. If there’s one thing to be learnt from Fyre Festival, it’s probably that.
The outcome of this Branding period was Product was educated enough to consult on imagery and copy for campaign, organic and paid. In fact post-MVP at Pollen saw Product Design working directly on Marketing campaigns alongside Marketing Designers with equal positioning.
MVP - There’s an app for that
You don’t need an app for that usually. In fact an app usually slows things down when trying to find the thing you need to build. In the case of Pollen however we wanted to build an app because our data told us to build one. In Verve world, where the web is accessible to everyone, an app isn’t a priority (it’s something that’s always in early stage development at Verve, but never ships). Pollen needed an exclusivity angle and using React Native allowed us to make an exclusive container for Pollen while keeping web on target. There are pros and cons to React Native, I’ve read them all. Pollen was the perfect React Native candidate.
Pollen MVP powered by React Native
If Verve was single campaign driven (one user, one festival), then Pollen was Multi-Campaign driven. This created a lot of complexity in both our user testing, but also in our personas and known quantitive data. Verve had been built and tested on a single campaign approach, focused flows, simple checkout - in fact simplicity was the 100% focus with Verve.
Pollen was very different. It was a discovery product first, with user choice and communication coming at the top of the funnel, leading to multiple checkout flows, options and end goals. If a Verve user had one definition of success to manage (sell X tickets, get Y reward), then there were potentially unlimited defined successes in Pollen, with different actions delivering different rewards at scale.
To navigate this we couldn’t equate X=Y anymore. We had to develop a different system for rewards based on a framework that could adapt to different values and different frequencies. If selling 5 tickets in one campaign as a Verve user equates to 1 free ticket as a reward, what is the reward if a Pollen user sells 1 ticket in 5 different campaigns? Do they get a free ticket? And if so, for which campaign? What if the campaigns are priced differently? Does a $400 holiday score more highly than a $10 gig ticket?
We began to build a rewards system that assigned point values to sales, weighted towards cost of sale. A user sells a holiday - 10pts, a user sells a gig ticket - 2 points. This made logical sense. Something costing more is harder to sell, therefore would get more rewards. We created Blue, Gold and Black statuses, each requiring a certain point value to access. Each ‘tier’ entitled the user to a range of rewards they could claim relating to their interests. The limitations of this system however began to show itself immediately in testing with users.
Reward behaviours
In testing rewards behaviours we began to realise that a weighted point based system wasn’t elevating our users. There were a few reasons for that. The logic of more cost equating to more reward makes sense (AMEX has built an empire from this dynamic) but for Pollen users the dynamic was too capitalistic. What we were doing was equating an experience someone was having with the cost of its purchase, which is to say that something that costs more MEANS more in our ecosystem. That just wasn’t the case. Our users saw straight through it - they saw money meaning access and immediately we began to loose authenticity. Money meaning access is something we’d originally sought to avoid with our users - those under 30 for the most part don’t see their personal wealth as an elevating element. We saw claims of unfairness, of ‘so if I’m rich I get more stuff’, of ‘this isn’t for me, because I can’t afford a holiday’. The reward behaviours we began to see positively emerge were non-hierarchical - every sale gives you a something towards a reward. And it was this non-hierarchical reward structure that unlocked the retention model we were looking for.
What we discovered was that ‘fandom’ played a large part in retention. In the world of ‘fandom’ someone who sells 5 tickets weekly to a club night has more worth than someone who purchases one large ticket item. In turn that ‘fan’ has more leverage with their network through constant broadcasting, making them effectively a micro-influencer within their domain.
‘Fairness’ in this world then becomes less about spend and more about usage. It’s less AMEX and more Foursquare. Removing money as a contributing factor began to make the reward dynamic more trustworthy, and more accessible. It removed the unnatural calculation of cash vs points.
We switched the tier access in Pollen to ‘amount of sales’ rather than ‘sales amount’ for MVP and it immediately opened up the concept of value to the users. Value that wasn’t monetary. Value that was calculated by the user, not Pollen itself.
Aiding Discovery
The quickest way to gain a user and retain them in Pollen was to give them the opportunity to discover new and exciting things, but more importantly let them find things they were looking for. With a marketplace built for scale, there’s only so many items you can place in a carousel before the intent to search is lost. We began with a powerful search tool front and centre in the UI, with predicative search display and the added options to request a search item if none was found - this allowed us to poll our users in real time.
The smart search feature in Pollen
For many products (such as Citymapper) search is bread and butter. It’s the 99% use case. In Verve world, search was non-existent, so integrating search into the product was a big deal. In fact it was such a big deal that multiple revisions of the discovery product were trialed before we tackled search being given such prominence in the UI. Search really began to take centre stage (and become more smart) when we finalised the first quarter of MVP trials in London. Pollen was expanding quickly and was showing astonishing GMV values, and the pressure was on to begin rolling Pollen into the US as soon as possible.
Adding location switches into Pollen
Much like Citymapper, we added a city switcher into the product which put more and more pressure on search, along with hyper-localised discovery. The back end required work - more tagging, more controls and the partner requirements equally grew as we added new locations. We also began reworking our initial MVP style guides to incorporate geographies. The UK is largely a single territory clubbing / festival market, with hyper-local users attending hyper-local events, save for annual festival pilgrimages. Stylistically and semantically its London - sorry to say that, but its one city that aligns the country in ‘how things look and feel’. The US is vastly different. We found our users travelling from NYC to attend a Diplo event. People from LA travelling Okerchobee, people from the east coast making the a pilgrimage to Coachella. Would someone in London use the city picker? Probably not. Would someone in NYC? Most definitely.
The more time we spent with our users on the ground in the US the more we realised that culturally the geographies were very different. Can we display an event in London the same as in LA or NYC? This opened up design framework discovery and a focus on an ever simplifying style guide.
Management
One consistency across all the locations we added was the core functionality of sales management. With users selling tickets and experiences across multiple events, locations and dates, to multiple friend groups, through WhatsApp, SMS and email - we needed a robust sales flow that would be easy to use and not require large amounts of CX spend.
Sales management in Pollen
Integrated into that sales management was SMS flows, allowing a user to send their friends checkout links and tickets, along with ‘sales links’ giving the user the tools to pitch their friends events they wanted to sell from within the app interface. These integrations were significant complexity - event discovery through to event selection through to adding friends, pitching and checkout - and getting them operational across multiple ticket providers in multiple currencies in different geographies was an impressive feat to achieve for MVP, but it was so core to the product experience that they couldn’t just be a redirect to mobile web. React let us build cross platform delivering consistency in our flows and user data.
What now?
Pollen continues to grow. In fact what was an MVP in one territory now controls the majority of collegiate travel in the US and Canada and continues to dominate in Europe. That growth was so strong that Pollen - in the space of two years - replaced Verve as both the core product and the core brand - and now leads strategy. Verve is no more - Pollen took over, and seems to be continuing to ‘pollenate’ within the experience and events market year on year.
Pollen continues to dominate
Update
In October 2019, Verve raised $60M in Series C financing with Kindred and others on the strength of the Pollen marketplace - and in turn rebranded Verve to Pollen. Pollen now leads the influencer sales market in both EMEA and the US, and through M&A owns the lion share of student travel in the US.
Making student travel visually not suck and scale across multiple destinations
I never intended to visually design Spring Break. It just kind of happened. It’s not my normal design brief.
Student travel is a money-making beast. It’s a billion dollar market with a guaranteed influx of new users every year. But because every year this new influx of thousands of students hits campus with zero previous experience of what it is to ‘Spring Break’, student travel providers are pretty lazy when it comes to trying to move things forward. To progress. And as such, everything is just a bit…well…tacky.
And because it’s a bit tacky - no designer wants to tackle it. I love a challenge which others won’t touch with a stick. For more context, we’d recently acquired a millennial / student travel company, and we had three months to roll out live campaigns.
I’m going to go through the iterative process of tackling this project from start to finish, so it’s not all portfolio - there’s some duds here, and I’m going to show them. I should also point out that my role in this project was as Design Leader, overseeing Product, UX and Marketing, so many other talented people with specific skills worked on these over numerous revisions (hence I’m showing you process and not a link to some shiny Dribbble account).
A look at the current market
The current market in Spring Break world is pretty grim. It’s cartoon-y. It’s cheap. What’s crazy about that however is the cost of actually going to Spring Break - students are paying $800-$3000 for a one week vacation all-inclusive with flights.
An example of existing artwork for Spring Break Cabo San Lucas, 2018
There’s also the additional complication of Sororities and Fraternities - large family style travel groups who seem to not only have large amounts of money, but also transcend trends. Investigating trend within Greek groups opens up levels of inner hierarchy, and history - these are establishments where you gain societal status, not where you gain cool. To that extent understanding the current output of Spring Break providers makes some sense - cheap, quick, fun. But our research showed that whether it was Greek groups, Sports groups or just random large groups looking to Spring Break they were all unified around Trust, Transparency and Value for Money. Taking this into account we can begin to build our mood - it’s got to be clean, trustworthy and high value - and in the student / socially-led world this is an easy find. But while these students are driving the decision making and narrative, it’s not usually them paying for it - the decider is mom and dad. So if you want to scale the stories you tell, want to increase the experiences you offer and, by proxy, increase the cost of your packages - you have to get mom and dad onboard, because they hold the AMEX.
Beginnings
Early discovery into new textures
Early discovery into type
Normally with Marketing Design I’d begin with a moodboard, some brand analysis - but with this project we knew we were dealing with complexity. 50+ schools, 10+ destinations, merch, staging visuals - not to mention social media, UGC and below the line campaigns. A quick calculation early on revealed that per-destination a campaign might require 200+ assets for below the line use, including variants of those assets across an average of 10 different schools. That’s a lot of assets, and with a high-growth strategy involving HTML and SEO, this means multiple variants of variants, A/B testing and constant key word changes.
We’re a remote / distributed team, with the bulk between London and Los Angeles, and stakeholders in Las Vegas. This meant two things. Firstly we’d use an asynchronous tool to coordinate our design process. Secondly, with the complexity and timezones in play, we’d need to change our working practise to not require stakeholder approval for every asset variant.
We created a Campaign framework that presented parent key art to stakeholder, with cascading variants from the parent key art being asynchronously available and editable. For this we chose Figma, which not only allowed us to sync our critique with our Product Design and CX teams, but also allowed for asynchronous feedback from stakeholders along with shareable permalinks.
Our Figma templating for the Marketing framework - 10 destinations ready to export in multiple formats
Scalable Design - V1
To scale the design with the amount of variants in the brief we immediately moved away from bespoke illustration or specific key photography and began to look at montage styles and design frameworks based around core patterns, rhythms and devices. One clear device was gradients - they were flexible, allowed us to chose complimentary colour-ways per destination, would scale to partnerships and brand guidelines, and could be used across multiple brand touch points from web product to merchandise to CSS. Another clear device was emojis. Emojis allowed us to quickly add mood or a sense of social to the campaign. The reason this was strategically important was that with a new influx of students every year, and the average college student last only four years in their degree, the ability for us to re-use photography from the student trips wasn’t a long-game solution. Sure when you’re 22 us using you in a poster campaign is cute - you and your friends, drunk, enjoying the sun. It’s a slightly different story when you’re 25 and trying to lock down that finance job. This meant we were largely reliant on UGC and social imagery to fuel our content pipelines, and with that comes lower quality, shaky footage and ‘embellishment’ (be that Insta-Gifs or general LOLz). You can deny that reality by heavily polishing your content or having a high refusal rate - or you can lean into it and make your professional content look as accessible and as fun as the UGC. We chose the latter. By combining UGC with stock imagery you achieve an unusual look - neither appears what it was. The UGC looks punchy. The stock imagery looks relevant. It also most importantly looks truthful.
Another range of devices we utilised was a mixture of in-destination specific stock imagery (locations, buildings, mountains), in-country specific stock and vector imagery (flowers, tropical fruit, palm trees) and experientially specific imagery (pool floats, surfboards, boats, fruit). There’s a few reasons for these using devices which are beyond general aesthetic. We used experiential imagery to ‘shortcut’ the destination - what you see is what you get - if there’s a boat, there’s a boat party, if there’s water there’s a beach, if there’s a pool float there’s a pool. But we also used this imagery to bypass restrictions - the boat party supplier wasn't confirmed, so a cartoon boat fills in, you can’t advertise alcohol to under 21s in the US, but in Mexico you can drink it and it’s part of your holiday package - so we show cocktail fruit, ice cubes and bubbles.
We also introduced patterns into the designs, although they play a largely supporting role - this is a ‘unknown unknown’ scaling element. Do we need staging backdrops? What colour are the tote bags? These patterns were our backup if all else failed. A consistency in the framework foundation - spots, stripes, circles, squares - a bread and butter element that we treated like a Swiss Army knife in case the on-site experiential got tricky.
Scaleable Design - V2
Our designs were rating well in user testing, however our stakeholders wanted more options relating to ‘premium destination’ feels - with more a focus on the destination itself. We began by breaking down the framework approach to its components and simplifying our approach. Could we make an impact with UGC and without UGC? Could we keep stock elements as destination-specific triggers? How could we make this feel more tropical and more luxurious?
We began using less vector and more photography in our foundation to ‘luxe up’ the destination IDs, and we found that in doing so we validated our framework further through it’s flexibility. We also retroactively applied our tonal changes to our existing designation designs. We still kept the UGC focus, but we offset it with more detailed execution, and developed a pictorial destination ID and a ‘lockup’ that operated better on social video stories and web page headers.
Scaleable Design - V3
One of the limitations we discovered with our UGC framework style however was how it worked with artist imagery. During our discovery of the campaign we began to look more closely at the experiential execution and the events we’d be coordinating at the tail end of the campaign when in-destination. With that came headliners for events, and with that came artists bookers and agents. We began to adopt the framework for a more typographic led approach to allow for studio quality imagery which had IP limitations attached to them, such as crop, orientation and scale.
We took many of the elements and devices of the montage framework and applied them to block type treatments. This allowed us to - in a single type treatment - encapsulate a destination in a locked self-contained logo style, which made its application more scaleable across static and video backgrounds, and gave us clear options for animation.
We also began to play with other messaging, adopting the framework within other typography to experiment with storytelling, along with using it in the context of broader storytelling imagery.
Using a self-contained type-based framework allowed us to use more large scale imagery, and incorporate UGC as part of that on social with framing devices. The frames allowed us to take devices and use them to provide contextual impact while not interrupting the core imagery.
Most of our communication strategy was aligned to Instagram, and as such we had to operate between 1:1 and 9:16 formats, while also making sure that artist imagery remained uncropped and untouched.
So - does it scale? Yes it does. Does it make Spring Break cool? Not sure yet. Head to Cabo San Lucas in March to find out.
Designing a product to shake up the world of Digital Asset Management
The Problem
DAMs (Digital Asset Management systems) are pretty established these days. Once your company gets over 100 in headcount, the need to control you assets between yourself internally and with partners externally starts to become a strong need. Even more so if you’re a remote or distributed company.
There are some clear problems with DAMs though. They’re usually large and cumbersome. They have features you don’t really need. Their pricing is opaque. They’re sold as enterprise and at huge cost. They’re bespoke yet weirdly inflexible. They don’t really iterate like a Saas, nor are they as accessible or as easy to use as a Saas.
Enter Workshake. Workshake is a Saas approach to DAM technology with a focus on user experience rather than technical need. If a DAM is usually a badly skinned database built by backend engineers, Workshake is a careful crafted and intuitive product based around what people need.
The Market
DAM is a market that is growing quickly. As cloud storage solutions become lower cost and higher value per GB, there has been a significant growth the the cloud services market which is scaling to support it.
There’s also another reason for that. As companies increase their global distribution and remote enable workforce, the need to provide colloid solutions and cloud access to employees increases exponentially.
The Solution
Workshake allows businesses to consolidate all their Cloud storage solutions into one space, and use powerful search tools and meta data passporting to be able to quickly find, share and categorise their assets. Their assets exist within a solid AES 256 encrypted environment which only they can access - and control access to - through user IDs.
On synchronisation with Workshake, assets from wherever they may come from are analysed and applied meta data through a lightweight Wolfram engine that looks for format, file structure, image type, colour, existing meta, location and GPS tags, making or versioning formats and basic semantics.
The Product
Workshake operates like an inbox for your assets. Add assets or asset sources, view, browse and search existing cloud services and simply share with integrated platforms or the product’s secure external portal.
Use Case One
Here a distributed team want to share - in this case - a World file amongst themselves. Workshake allows for groups to be created quickly and simply, and for files to be made private, team enabled or all-team enabled though basic, easy to use statuses.
Use Case Two
Here a team want to share a file externally with a client or partner and wish to do so through a secure and trustworthy portal.
Use Case Three
Here an agency has uploaded some imagery - both photo-based and graphic. Workshake uses Wolfram Engine to analyse the basic properties of the asset to automatically assign editable meta data to the asset to aid in its retrieval. The user can also add additional meta data, or edit and correct existing meta data. In the case of the image, this analysis includes location tagging, colour extraction, and some basic image recognition to aid in it’s retrieval - is there a tree, it there sky, are there people, is it a portrait. In the case of the graphic, this analysis includes typographic suggestion, file size, letter recognition, colour extraction and file type. The reason this is applied is to expedite retrieval. Often we don’t remember what an image is called or where it is located, only that, “It was a picture in a park I took last year of some flowers”. Workshake allows you to search using these parameters.
Use Case Four
Here a user has created a document in Workshake to share with their team. As the user types, Workshake analyses the semantics and the imagery being uploaded and applied automatic, editable meta data to aid with its retrieval. The user can also add additional meta data, or edit and correct existing meta data.
Meetings mean time, time means money; so I build a product that times meetings
The best products are built from identifying real problems. In a previous role (no names mentioned) I ran a product line and associated team doing pretty deep and complex work, however it often felt we were executing that deep and complex work despite the negative cultural elements that surrounded us. There were pressurised long hours, expected attendance, clock watching, micro-aggressions and micro-management. So far so uncultured start-up I guess. I won’t delve into that culture too heavily here - except to say that it’s the opposite of what a good work culture should be, I’m thankfully out of it, and I’ll never return to it regardless of the equity thrown my direction.
That aside, the one element of this company culture I truly detested was unplanned, unstructured and un-time-boxed meetings. I’m not (at least I don’t think) arrogant enough to describe my ‘time as money’, but I do consider myself experienced enough to consider flagrant and mandated bad use of my time disrespectful. And I’m not talking about the kind of meeting which is ‘hey, could we all meet and have a chat about some ideas I’ve had’, which, you know, often are unstructured and wavering meetings, sometimes seemingly with no end - but sometimes there is a need for those meetings which become a rolling critique or discussion, specifically if the focus is there in the room and there’s a clear need and everyone is engaged.
The fact that my team invented a side-app to cope and expose the futility - and cost - of the meetings we encountered, should probably be proof that they weren’t those meetings. No, these were undirected ‘hey come into this room now’ meetings which often roped in 10 to 20 participants and could run from 2 to 4 hours on a bad day. If you were super lucky you could claim ‘something urgent came up’ and find your way out of them - but that was rare.
And so a product was born. Born from the question, “Hey there were so many of us stuck in that meeting and it was totally pointless - I wonder how much that just cost?”. A very valid question, specifically if you’re in the process of burning venture cash in search of a market fit, and time is described as ‘runway’.
Designing this product was pretty quick and scrappy. React Native, some quick sketches, a few conversations, empower the front end designers and embrace the feature adds that magically appear. Let’s not call this a portfolio piece, but let’s call it a useful and fun product. It’s a product that everyone who sees it says ‘Man I wish I’d had that on my phone in this meeting I had the other day’.
It’s simple. So simple that you show it to someone and they immediately go ‘OH!’ and grab it from you. It’s probably the only product I’ll ever make that will be so simple and have such an immediate reaction.
Simplicity aside, there’s some cool features in the product though. The great thing about these mini-features as they came from - clearly - a passive aggressive moment, probably in a two hour meeting.
Yes, you can share the scary multiplying cash value by hitting the link icon - send it to whoever, however to show the futility of your meeting existence. Yes, you get a report on the total bill due from your wasted group session, but with the added value of being told that the meeting cost the same price as a thing you’d maybe like.
In seriousness though, the app does provide shocking value in the moment. Using it in anger to disrupt pointless meetings, and claiming that time back to yourself is a glorious outcome. Using money as a metric also seems to be a metric everyone can understand.
Now all I need to do is work out how to get it to track my personal social media ‘burn’.
Launching smarter buses as a service with Citymapper
Since October of last year I've been at Citymapper, and I've been building a bus. Well - more accurately, I've been leading product design on a Smartbus. In that time we've built and shipped 2 productised Saas platforms, a full hardware stack, an Android framework and an App. We've also stripped down a fleet of buses and rebuilt the tech from the ground up and productised it all. We've even wrapped the interior and exterior, rebuilt the seats, and deployed a super-cute bus icon on everything.
I'll go into more detail about the whole product stack soon enough when I catch a breath, but for now here's some better writers than me talking about the launch:
There's also more product elements at Citymapper.com/smartbus for anyone who is interested and we're also experimenting with crowd sourced bus routes with a crazy beta drawing product here.
If you're a holistic product type who sweats the details, then I've got you covered - check out the blogs coming from the product team on Medium and some 'finely crafted' copywriting here that involved more than a few late nights. That's right - product is a full stack requirement.
How we built and exited a big data Saas using global remote teams
Sure it's a cheesy metaphor - but it is the actual sunset on my last work day in San Francisco
Leaving a product - especially one you've built from whiteboard to public release is a hard thing to do (and especially one where your desk has the above view). But that's what I'm doing, and as I leave Sonr - as goes the cliche - I've had the chance to reflect on what we've done, what we've shipped and the processes we've developed. This isn't a post about personal failure and / or learnings - I'll be delving into that in a medium post at some point soon (lucky you) - nor is it a commentary on startups or being part of a founding team. It's more an overview of product creation - specifically from my point of view as a Creative Director / builder / shipper / strategist of product (i.e someone with a strong preference relating to pens). Anyway, here's a quick fly-by-night overview of my past two years in Sonr-land.
Breaking ground on the product in Potrero Hill with the founding team - the first sketches
We started the product design in San Francisco in 2014 after the initial pre-seed round had closed. We had a whiteboard, a development team and had time-boxed a few days. I'd had a few weeks before my arrival to get some homework done - I'd performed some business canvas workshops, we'd done our requirements gathering from the business and from our potential customer base, we sorted cards, and we'd created our first round of user personas (knowing that we'd end up trashing them within the month). What we came up with in that first office in Potrero Hill was a very basic product specification that focused on business and user verticals - in fact much of the technology at that stage was a relative unknown (such were the joys of social APIs in 2014) but the focus was very much on building a proof of concept. We did this by utilising existing frameworks - specifically Bootstrap - to build the basic front end and get the ball rolling. Using existing frameworks is a great way of bypassing needless development - we were using the framework to test UX hypothesis, but also to give the backend something to output to. That first iteration, those first pre-MVP versions - we excepted their inevitable generic bland ugliness because we knew we'd be throwing them away sometime soon anyway. Using a simple framework can give you an advanced front end in minimal time with minimal spend compared to bespoke front end noodling. It allowed us to take the whiteboard process above to the UI below in weeks rather than months, while giving us the opportunity to quickly iterate front end elements around without slowing down backend development schedules.
The initial Bootstrap mockup which raised Seed
Active and Ambient states mapped out
From here we moved as fast as we could to prove hypothesis - I placed these early versions in front of as many possible end users as possible. This was quick and dirty guerrilla-style user testing, the type straight out of the IDEO playbook. We changed some things off the back of that. We - of course - also trashed our user personas and wrote new ones, and began to really figure out the structure of the data behind what we were now building. We deep-dived into API documentation, we attended conferences (see below) and spoke with possible partners, we scouted competitors, we tried to work out better user flows, oh, and we had to raise some significant money (which we did). I created user flows, overlaid with data architecture to try to break down and visualise the actions of the user and the impact on the product. This broke down the product into 'user intentions' (which were effectively collections of related user flows) and 'product reactions' (which were how the product would react to a 'user intention'). This gave us a high level overview of user and product intended behaviour, with both influencing each other. A user could be administrating, searching, curating or exporting - meanwhile the product could be active or ambient at any given time.
Visting Twitter Flock 2015 NYC
Visting SXSW 2015 Austin TX
Iterating to v2 with our awesome new product team in Midtown, NYC
Around this time we'd begun to crystallise a product team in New York who were beginning to build out processes, set up Jira workflows and form QA schedules. We began to form more stringent user testing systems, and began to do one-on-one Google Hangout interviews. The distributed nature of these teams, between New York, London and San Francisco at this point began to place strain on product development, and marshalling it became a full time balancing act of clear documentation, scheduled Hangouts and constant Slack use. With this in mind we spent time in New York training the team there to become product design focused, allowing them more time autonomously working with the west coast team on product features. We also began to iterate the designs to fully incorporate our user feedback from testing. With new front end developers being hired we were now able to break away from our Bootstrap framework, and move to something more advanced and scaleable in ReactJS. Initially we kept the Bootstrap aesthetic (there was no rush for design beyond UX elements at this phase of the build) - icons, drop-downs, transitions - they were all defaults and generics. We were ignoring the details until we solved the bigger UX picture.
Distributed teams are *really* hard work and can 'jetlag' a product
There were also organisational problems to solve - distribution meant we had the problems that all distributed teams have - things fall through the gaps, and communication is hard. Being on hangouts across multiple timezones led to long days for those on GMT and deep investigations into the best conference calling and video calling tech (bottom line: there are no 'amazing' conference call headphones - but it's all about the microphone. We ended up with Sennheiser PC36's for group chat and the Jabra SPEAK 510 for portable conference calling - and always using Google Hangouts. Slack may change this space, but for now Google is the best).
I began work on two things at this point - mobile (which was based in London) and documentation upgrades for those on the west coast. Documentation is often seen as a failure to pair-code, but while pair-coding is indeed best practise, it becomes near impossible with a 6-8 hour time difference. Here is the 'Manual' that was produced (below). The 'Manual' is written with a group definition (say 'Search' ) which is defined by the user Action, Behaviour and the related user stories that created the Action and Behaviour to be defined. Within each group there a section of each element that combines to group, each element having precise schematics defining it's default state, basic behaviour and basic action. This level of precise documentation prevents any grey areas forming, but also focuses the UX and product into defining every inch of the product and it's intended action - and making sure that this action is being supported by at least one user story (here's an excerpt from the 100 pages it eventually ran to).
With mobile being in London, the need for such precise documentation wasn't so great. We could pair-code and whiteboard solutions. We still needed to define the actions though, and we used Flinto for the bulk of our prototyping. These prototypes were then user tested by the product team and with our user groups for feedback. The feedback was then incorporated into the wireframes (see below).
At this time we were getting significant feedback on the web side of the product, mainly about it's complexity. Now was the time to begin stripping away elements and beginning a process of reduction. Feature creep is inevitable, especially with diverse user testing groups, stakeholders and partnerships. The technology had also changed - our stack was nearing full development, but the partner APIs we accessed were developing at their own pace and changing. We also had ReactJS to consider as a framework - React works better in certain load scenarios than in others, and we were noticing lag in the front end performance. We began to simplify the design, but as we had defined and tested user stories we could focus more on the technological execution and making things more reliable, faster and economical.
Partner APIs are tricky beasts and by now, with large changes across most of the major social networks underway, some of our features - specifically the ones that attempted to unify some of the social network content - were becoming swiftly outdated (or worse - redundant). We were facing capping, call limits, sandboxing - the APIs were fluid and at the whim of their development teams. We soon realised we needed to simplify further. Like - waaaay further - and get to the core of the user stories that mattered and reduce the strain on the APIs. Some of the features were cool - some were 'wow' - but with the APIs in drift they would more often than not throw up an error or a time out. Effectively the experience we'd built was great when it worked, but was so prone to third party error we'd inadvertently built a frustrating experience that seemed buggy, but was in fact just feeding errors from APIs that we had no control over. This was a serious UX issue that needed resolving. We went back to the core ideas of the product and the subsequent research we'd done - along with all we knew about the APIs we'd been using. We chose to treat the APIs as individual elements which allowed for outages that wouldn't affect the UX as a whole. This also allowed us to prioritise individual network onboarding, sign-in, OAuth and sign-out.
Onboarding became a big focus at this stage. We'd done enough user testing and design reduction to know the sticking points of the product. We were focused on simple, clear and progressive steps to getting the user to make their first actions within seconds of sign-in.
Focusing on making the APIs individual not only meant we didn't have to worry too much about outages, but it also meant we could develop API specific features which could be seen only when that API was being used. This allowed users to search certain networks for people, but for us to allow background actions within certain rate limits. Returning back to the days of us whiteboarding it all in San Francisco - we could allow action and ambient processes. And now the action and ambient processes were decoupled from the various APIs, we could now focus on making them stronger features in their own right.
And with that - we shipped to public beta. We began some low level growth marketing around Medium (see here) and after getting some publication acceptance we quite quickly gained a lengthy beta waitlist.
When to Design - and when to *design*
I've been designing Sonr for about 16 months in total. We've built prototypes, raised capital, tested, prototyped, tested - and then began to build out the core product - which is now in private beta. In all this time I never actually designed any icons. I used UI Kit for iOS. I used a variety of resources like Noun Project and Iconmonster. I originally used whatever came with Bootstrap. It's not because these design elements aren't important - they are. But they are not important until the workflow, framework and UX is designed and tested. When we initially moved past whiteboards and paper at the beginning of the Sonr project and we need to build a solid prototype, I sat in a room in Potrero Hill 8 weeks before the first investment round presentation and delivered a paper prototype with boxes and attributed actions. I didn't care so much what it looked like, but I did care about what it did. We chose a low latency framework - Bootstrap - and using it's modules and components which looked like ***generic website template no.4*** began to flesh out the boxes and actions. This was a time to design rather than design.
Bootstrap-alicious
That was enough to do a few things - it allowed us to raise capital, test back-end architectures - and allowed us to realise quite a few things we got wrong with the product. Much is talked about technical debt - but design debt is also a silent killer in new products. Building a fully fledged front end too early inevitably means having to squeeze in features and newly validated workflows into an increasingly creaking - and expensive - architecture. Bootstrap got us around that. Much as it hurts to admit as a designer - no one cares about your icon set. Or your colour selection. Or your font. None of that is even noticeable if your product is weak or badly considered.
Colours finally making it into react.js
Spin forward 16 months and 50k airmiles later - and I've designed a v1.0 icon set (see above).
I have a hard coded set of colours. I have a GUI font in testing. Bootstrap has been replaced with a more scaleable and enterprise framework in react.js.
The icon set is a little complex as we run it as a font, allowing multi-state rollover / fill options to reside with the development team. This was a conscious decision as it prevents design slowing down product design and development. Design can be easily changed on the fly and through pair coding - not constant revisits to Sketch or Photoshop. Breakpoints can now influence icon behaviour. The downside is that we can't make cool interactive SVGs and GIF icons - but for a product in beta...it's just too much design for what users need right now. I mean I'd love to make 'em, but I know deep down it would be a waste of time.
In truth, the design in the product has moved on with the implementation of react.js - we now have flexible components, but these components have been simply assigned colour HEX and behaviours - they haven't been designed. This is sometimes a tough thing to communicate to stakeholders. Yes it looks sexy, but it's effectively still a lightweight wireframe - a really really nice one obviously - but it's still the product at its most basic. The design priority right now is load times, rendering issues, improving UX and architecture, testing, bug tracking, iterating quickly...not adding more design layers and slowing things down on the development side of things.
Now in react - with plenty of design, but not much design
When we set out on the road of designing a complex SaaS product, we wanted the design to scale with the engineering. I didn't necessarily want to design a flat UI. I didn't adopt an existing design framework. We just ended up here through research, iteration and product / engineering requirements. It will of course be designed one day in the near future, once the beta stage is cleared and the feedback compiled. The design layer is of course required. But when that will happen I'm not so sure - it's probably going to be up to the user.
Building a product for Creatives who don't really know what they want
In most of the interviews I've had for roles (and interviewing people for UX focused roles is tough, I sympathise), there are always two questions - or variants of two questions - that consistently crop up: 'Which product do you wish you'd designed?' and 'Which has been the best product you've worked on?'.
The answer to the first, if you must know, is Slack. Why? Because it solves a very complicated problem, and it does it in the difficult B2B space. It's elegant. It feels good. Yes - that's right - it has feels. Which is gold dust. It's a remarkable mix of bread and butter UX and magic. And the magic stuff - which is sometimes really simple interactions, manipulations or renders (like the way it parses HEX codes into the IM thread with colour swatches) is jealousy making. I love that product. It completely knows what it is. I'm jealous of a product that is so...product aware.
Ok, so Slack is awesome. But the answer to the second question changed for me about two years ago when I got to work on a wonderful - if intimidating - project, which I still think brought out some of the best critical thinking I've ever done. Not because the final 'product' was amazing and shiny. We didn't make Slack - we had 3 months - but we made a process which was validated, tested and used to impressive results. But answering that second question is hard in an interview, because we didn't produce a 'product'. It could easily be a product, but we didn't make it into one. Which means that if you ask me that question and want a response I'm probably going to need half an hour and a whiteboard - and maybe some playing cards. Because the best product I've designed was meant to be a 'product' - we actually did set out to make one - but we ended up designing a card game instead. And it was awesome. Like, Slack awesome.
Through random circumstance and Twitter I was introduced to Matt Locke. Matt is an interesting character, and it's evident the moment you meet him. Total energy, focus and hyper intelligent. Matt was Senior in BBC R&D before leaving to head up Channel 4's digital OnDemand offerings. Now he runs an agency called Storythings (among other things like The Story conference). And the team he had amassed was rather intimidating. Project Producer was Kim Plowright - an Emmy award-winning talent from the BBC and Dan Catt - original lead front-end technologist from Flickr. Unlimited Theatre - one of the first theatre companies to combine technology with experiential theatre - were there to lead user research. There was a lot of work completed on this project, and I'd hate to speak for anyone else about their processes, so with that in mind I'm going to talk through my perception of the project, and not really go into what others were working on in tandem. It's not really fair to do that.
Investigating the product
The product we were investigating building was based around the concept of aiding writers with writers block - or more broadly - aiding writers to develop concepts and narrative arcs quicker, easier and through collaboration. This is - as you may be able to guess - a pretty complex problem. It involves ego, creative fragility, personality, voice, networks and...so much more. A day into whiteboarding and card sorting and we were somewhat closer to identifying a focus and a hypothesis. The hypothesis itself here was important as we had a client - namely a BAFTA award winning client in the form of writer Graham Linehan and his production company Delightful.
Client focused product is different to internal stakeholder product in many ways - the client is paying and there is usually a time box as time is money. Clients usually have a varied interpretation of the 'definition of done' and the 'definition of success' that needs to be navigated. This isn't a bad thing at all - in fact it's one of the reasons agencies can produce such incredible work - but it's a different approach to an internal stakeholder scenario where these definitions are core to the company ethos - or at least they are in product focused companies.
Delightful is easily one of the most interesting clients I've ever worked with. Graham himself is incredibly clued up on product development. Oblique Strategies? Done it. IDEO Cards? Yep. Agile? Tried it. Kanban? Sure. *Name book about creativity, UX, design or creative management*? Read it. He owns a copy of Gamestorming. All of this was something of a first for me. We researched his tools, interviewed him about his work processes and had hours of notes and audio files. Then we prepared a workshop.
Workshopping the product
I've prepared and managed many workshops, but in this instance we were going to collaborate with an experiential theatre company. This was also a first for me. We had a theatre space, and we used all of it. Every wall, table and box was eventually covered in cards, notes and whiteboard sheets.
The experience was very interesting. Having a theatre company craft an experience around the workshop added a very unusual - even uncomfortable - sense of personal distance that is very difficult to explain, but seemed to really focus the process. It's something I'd certainly like to try again on other projects and products. It allowed the participants to fully investigate the user journeys they were trying to explain or imagine - the process of theatre seemed to provide an empathic element I've never experienced in a product workshop. The idea of applying a narrative (even music) to the investigation of a proposed narrative sounds overly-complex and bizarre - but it isn't - and it works. It forces the workshop group to forgo their rational defaults and the professional roles and look deeper into why things are important in a possible product rather than what is important in a possible product.
The research we gained was invaluable, and in particular for me the narrative tools that can be used in crafting stories - specifically the processes of Kafka and Neil Gaiman, plot processes and character arcs, mcguffins, and hide/reveal - all added to my toolset . I've used these since in other projects, but it was a rare chance to learn these things directly first hand from people who have mastered their craft.
From the research we began the sort process - breaking down the ideas into stories we could build, and from there we built out the tasks within the stories. The workflow was also starting to form from these processes. We'd identified the user flow but not the technology stack, however we knew that the product felt 'bot' like, so we created a temporary element in the workflow to mimic the stack - and we called it DelightfulBot. We also began some external user research, asking writers from a variety of backgrounds and disciplines how they write and how they collaborate.
Research
Copyright - Storythings 2015
It's worth pointing out now that I'm not going to delve into the stack. I'm only going to talk about the UX and design elements in the build - mainly as the stack is not of my making, is under IP and...I'd do a bad job of explaining it.
Identifying the need for a bot meant working out the interaction design around it. Specifically the bots tone and reach. We focused research on the the emotive interactions the bot would be required to interact with, along with the level of interaction it would be required to maintain. Around the time we were building this, there was little research being performed into AI and generic bot interactions - what would be annoying, what would build trust and what would form a preferable bot personality.
The result of this research was to create a set of principles for the bot, and to do this using the same structure we would use for a user story. So instead of "The user is..." we worked with the structure of "The bot is...". This allowed us to match up user stories with bot stories and allow a cross-pollination of interactions. So with this in mind, "The bot is..."
'Polite and clear. Not too cutesy. Says please and thank you. Is just intermediary - it goes and asks other people. It doesn't do things magically or automate creative processes.'
It has the following attributes:
Approachable
Helpful
Likeable
Responsive
Alert
With the following tone of voice:
Excited
Loveable
Friendly
Honest
The bot also needed to have a definition of reach. How intrusive would it be? What environments would it find itself in? From this we could begin to create a playbook for how the bot would begin to react in certain environments and situations (and designed a small bot mascot to begin humanising the playbook with users).
Copyright - Storythings 2015
With this we'd created a framework for both the bot and the user, and from here we could begin sketching product solutions to both factors. We also began to look at adding game elements into the product to increase user interaction with the product, and focused initially on habit forming processes which required the user to add 5 writing ideas per day (which was based on feedback we'd received around procrastination in some users). This would address the issue of re-engaging users in the bot network, and also hopefully aid writers in their ideation processes. The bot at this stage became a true go-between in the forming product. A user would add ideas, and the bot would deliver them more based on the ideas they generated - but the bot wouldn't be an NLP powered AI, rather an anonymous mechanical turk - as more ideas were added, so the bot distributed more ideas the human layer, and by proxy the human trust in the product would remain intact.
Realising the frameworks
From this I began to build wireframes to flesh out the user frameworks. I based my default interaction style on Twitter Bootstrap to aid modular building and known icon sets - this had the benefit of not slowing down product development prior to MVP with design related bottlenecks, which are so often icon or CSS related and have little impact in user testing. These were wires to flesh out the user interactions and workflows - nothing more. We also started to look at easier ways of ingesting the users ideas into the product, and began to sketch and test early prototypes of a capture app allowing words, images, audio, video and geo elements to be uploaded and categorised.
Copyright - Storythings 2015
With the user framework realised, I now began to look again at the bot framework. The more we looked at the bot, the more we began to think that it could form the core element of a bigger game dynamic. The wireframes are just that - framing of interactions - but the bot could move more freely in this product. Yes it was a tool to allow anonymous sharing of ideas - and in effect it was a CDN in it's own right - but it was at the core of what the product was. We were looking at ways of testing the bot framework, and validating the wireframes prior to further development - we were also looking to expand the game element of the bot. With all this in mind, and user testing deadlines approaching it seemed a good time to remove the wireframes from the testing schedule and go back to focusing on the user workflow framework and the bot framework, and to increase the testing parameters, apply a game framework to it which would compliment the workflow.
So we made a card game. Here is the original game framework we developed. It's overly complex, but at the time we were effectively testing three games in one session.
The game
Game Setup:
Coloured cards - one colour for each player. (Or white cards with coloured stickers).
Cards have double sided writing ability.
A selection of cards with Stars on them to indicate a reward.
One archive box with a slit cut into it.
One external person is the Bot.
Writers sit on chairs facing away from each other. Each has some wall space to stick up ideas. Players do not talk to each other. There should be some indication that players are in a game environment of silence so they can exit it to talk. I’m suggesting a bell or similar - maybe a line drawn on the floor. Players must feel they transition from individuals to the workshop group at certain points - we will required them to imagine themselves writing alone. But then transition to talking in a group about the process of the game. It could be two area with different lighting or two rooms.
Game Dynamic:
The basic DelightfulBot concept is described. Introduction to the game environment and the rules required.
The players decide through group discussion on hashtag descriptors for the tonality of their writing. This is a group process. These hashtags are pinned up so they can be chosen and discussed. They maybe:
#serious
#family
#adultcomedy
#teencomedy
#melodrama
#romcom
#documentary
Ideally these would be debated from a larger list then broken down to 5-8 descriptors. Once these are agreed the players can be briefed on game dynamics. Players can use the hashtags.
Game 1: Individual Writer
Players are grouped into 3/4. Each group has a Bot who is a facilitator. One player is randomly designated as the Player by Bot. The others are designated as the Writers. The writers must not talk to each other or acknowledge the Player.
The Player is kept separate. The player produces 3 ideas or problems on cards. These ideas are numbered then pinned up by the Bot for the Writers to see. Each Writer must create an idea or solve a problem for each of the cards pinned up by Bot - and do so on a card numbered after the problem. The Bot then takes these back to the writer. The writer chooses the ideas they like and favourites them by starring the card. The other ideas are archived. A writer whose idea has been favourited receives a ‘starred card’ in return by Bot.
This process is repeated 2 more times. The Bot then takes the cards that are favourited and pins them up. The group then come together and discuss the process and the results. Focus on if the process of idea generation was fun, how people felt about writing ideas for others. Also to discuss the ‘hook’ or game dynamic - do they want to play it? Did they need to feel their ideas were well received?
Game 2: Write the Story (closed group dynamics)
Each player is to write a short 50 word story from scratch. They will use the group to do this. The story structure will be:
Beginning > Middle > End
Each transition between these structural elements will be group sourced for narrative ideas.
A player can- at anytime - ask Bot a question on a card. Bot will respond with a stock set of answers derived at random but this is very much like the Brian Eno card process - Bot will ask questions mainly such as “Where is this character going?” or “Where would the character go if they became lost?” etc. Bot to write these on the fly. They are handed back to the player in question.
Beginning (single player creates their own initial set up)
The player then hands this to the group by placing it in the box provided.
(The Bot then duplicates this idea 3 times. The three ideas are then randomly circulated to there players who write their development or idea on the back of the card). The players then deposit these cards back into the Bot Box and they are redistributed back to the original players. (NO PLAYER MUST RECEIVE THEIR OWN)
Middle (the single player takes their 3 group sourced ideas, chooses one and develops their story further until they need to develop an end to the story).
The player then hands this to the group by placing it in the box provided.
(The ‘Bot’ then duplicates this idea 3 times. The three ideas are then randomly circulated to their players who write their development or idea on the back of the card). The players then deposit these cards back into the Bot Box and they are redistributed back to the original players.
End (the player then concludes the story)
Each story is then presented by the player telling the story and pinning up the group sourced idea as they used it. They also pin up any Bot answers they requested.
Each player then explains the process of them writing the story and how they felt the idea helped them or hindered them.
The conclusion
The game was successful in testing all the hypothesis we had related to the user workflow, bot frameworks. The game dynamics needed simplifying certainly, but it was very successful. At this point however there is a need to 'define' success in this type of user testing - and the first stage definition of success we chose was 'does it help the writer solve a problem'. And it did. I can't tell you what that success looked like for various reasons, but I can tell you I watched a writer solve a problem in real time, trust the Bot, revel in the game dynamic, and receive a visible spark of inspiration - one that made their final draft some months later.
The question now is - is this the product? Is the user and bot framework wrapped in a game framework - now the conclusion? Does it need a technical solution? We'd certainly concluded the project as a whole - we had tested and validated frameworks and a solid game dynamic with the research to back it all up. Did we now need to build something more? Was what we had an MVP?
I think so.
How to make video user experience not suck
I've spend much of my career making products that publish content or try to solve problems relating to publishing content. I was preparing a new talk for a UX Conference, and as is normal for me this involved standing, staring into mid-distance, wondering what I was going to talk about. I wanted to identify a problem and discuss a solution. Three or four drafts in - and a week later - I had a talk completed. As it turned out, I really wanted to discuss one issue that I felt had never been properly solved - editorialising video and by association consuming editorial video. As part of the talk, I'd mocked up a really basic slide to explain the problem and what a solution might be. The problem it turned out was pretty simple: videos are too long and have no context - if you want to show me a clip of a single joke in a comedy show, you'll probably link to the entire comedy show via YouTube (unless someone has edited it for you) and tell me to 'check out the funny bit at 2.33'. So to boil that down to a user story: 'The user should be able to see a section of a video in an embed, understand it's context, and before watching it, decide if they want to actually watch it.' Here's that (really basic) slide:
That really basic slide
So for some context here; what I've mocked up is (from the top down) a HTML video component, underneath that - instead of a scrub bar - I've placed a SoundCloud music player with user comments, then below that - GIF modules from Buzzfeed which play scenes of the video, which in turn underneath them have editorial space, comments and share options in the style of Facebook. So the demo ran a bit like this - watch a GIF of a scene from the video which has some copy around it telling you what the context is, then if you tap it that scene of the video loads in the main HTML video module. It's a quick and dirty solution to a problem, but it was designed to show how problems can be solved with existing ideas and technology - that taking an element which SoundCloud uses for content navigation, out of context and repurposed - can be used differently while still keeping the elements core UX or USP intact. The feedback I got was surprising (considering how basic the slide was) - people loved this idea and many had opinions on how it could be implemented and other user problems it could solve. A successful talk.
The thing is - this idea didn't go away after the talk. I became slightly obsessed by it. The idea was kind-of solving the problem, but wasn't solving it in an elegant way, and this was itching something in me. It was too clunky. To busy. It was, in too many ways, pulling focus away from the content I was originally trying to uncover - so while it solved some problems, it actually generated more problems. I ended up working on it for a month around other work. I'd walk away and then come back to it. I'd apply knowledge I'd picked up on other products I'd worked on to it. I'd refactor the whole thing only to start again. I used Design Sprints to try and break out alternatives. I Gamestormed it from concept to business to find other perspectives. I made people who didn't care about my random obsession give feedback (and I bought a lot of people drinks until they did care). I was using guerrilla UX tactics to prototype and iterate - asking people their thoughts and almost pitching them it as if they were going to invest.
At the end of the month I felt I had something. Well - I'd found a solution anyway. Maybe not a final draft. Maybe not an MVP. But a solution. It desperately needed engineering minds to collaborate on it to move it forward, but with that cost insurmountable at the time, work pilling up on my desk and the itch scratched...it stalled. It became clear this was a product with more complexity that the engineers I knew could budget for. As an element of closure, I called it RPPLE - named after the process of 'ripple editing' I used to use when I edited video and After Effects promos. Also it felt nice to have an old Final Cut Pro reference in there somewhere. It was branded and sadly abandoned. But the learning, research and discipline I got from the whole process - I still use that constantly. Anyway, here is that solution.
The RPPLE concept
To solve the user story 'The user should be able to see a section of a video in an embed, understand it's context, and before watching it, decide if they want to actually watch it.' I had to look at the point of embed first. This player would need to be part of a distributed media strategy, so it would need to work within a Tumblr post and the Tumblr video embed, but also link back to a main core player experience. In the same way, that main player would have to export elements of itself into embeds with a distributed media strategy, and at the same time allow for revenue generation through standard metric driven advertising formats such as pre-roll and post-roll. The embed is a single scene that has been shared, except rather than it be a full video without context (or a full video with a defined start point in the timecode) it would be context driven: a headline and sell summarising why the video scene should be viewed, with a looped GIF of the scene being played - much like a GIPHY preview. This would then be used to draw the user into experiencing the main player and full video. The key to the embed however was not to generate a defined 'media card' style initially (which would involve a lot of support) but rather it would 'cuckoo' itself - adopting the style of whatever network default it found itself in. The next stage with embeds would be to define a more refined card style once user testing across multiple networks had been completed and evaluated.
The RPPLE player
The 1280 x 720 breakpoint for the main RPPLE embed player
So this is the basic solution at a 1280px breakpoint. The player is completely responsive, but I'm talking about breakpoints for ease of presentation (I find wireframing initial RWD solutions easier to plan and communicate using 4-5 breakpoints) . The RPPLE player is made up of some consistent elements, regardless of it's position or size. In hierarchical order these are:
A user avatar and <h1> global title
The main HTML5 media player component
A scene based navigation, displaying edits and basic heat mapping
An editorial 'carousel' that editorialises the scene selected with <h2> and <p> tags
A share button that exports the scene as a GIF for distributed media embedding
The user avatar displays the user who generated the video (more on that in a moment), and the title and media player component are self explanatory. There are two elements here however which require some clarification.
The scene selector - a new way to navigate video
The 'scrub bar' has been replaced with a selection of scenes shown in a ripple effect. Each scene shows it's length in time relevant to it's width in size. The wider the scene, the longer it is. These scenes are made of metric subdivisions of the total length of the video: 30 seconds, 20 seconds, 10 seconds, 5 seconds and 3 seconds. These metric subdivisions are there for a reason - 30 seconds is the maximum length of an Instagram video. 5 seconds under the length of a Vine (6 seconds) but with space for an end frame (if required for advertisers). 3 seconds is the minimum for Instagram. Additional to the width there is colour. The colours range from green to yellow to orange to red with green being the scene with the lowest metric of engagement and red the scene with the highest. This performs a few actions - the user can immediately see in a video which element of it everyone is talking about and sharing - it becomes a heat map of engagement. The producer of the video can see a breakdown of their edit and which part of the narrative gained the most engagement (almost as a direct feedback tool) to aid them in making better edits in the future. It also however shows the narrative of the video in a bare, visible metric. If this was a video of the new Star Wars trailer, the red section is going to be the really cool bit - the bit everyone is watching - but the orange bit beyond it is also gaining traction. This means that the user is more likely to browse through the video rather than just watch the 'bit everyone is talking about'. So it aids discovery through colour, it aids discovery as the video is broken down into scenes which are easily digestible. But it also aids navigation - scrub bars are notoriously fiddly on mobile, and these 'scenes' allow the user to simply tap on them to view them, knowing approximately what the engagement is on the scene - but also it's approximate length. It's hiding nothing from the user - it's transparent. Well - transparent except for context.
The carousel - adding context to the scene selector
The carousel provides this context. As the user plays the video through, or jumps to a specific scene, so to does the carousel below it. The carousel contains an <h2> headline and a
<p> body copy option which are completed by the video editor. The <h2> and <p> have - as shown here - character maximums. These are to allow the scene descriptions to accompany the video scene onto any social network regardless of minimums. 200 characters? This is a good amount to boil down what the scene is. 70 characters? The perfect length to form the basis of a tweet or Reddit post - and still give the user room to add some emojis. The carousel is also a navigation however - a user can scroll through the carousel looking for content in the same way they can use the scene selector, and they both move in sync through a simple flowing animation process. Hitting share in the carousel opens up modal dialogues for a variety of video enabled network APIs, and the resulting export is a GIF of the scene with the appropriate context copy depending on the character limits enforced by the API.
Editing a RPPLE
So they're easy to navigate and to share...but obviously they have to be created in the first place. For the end user, the experience is great - 30, 10 seconds chunks of content, easy to view and share. But what about the user trying to create these 30, 10 second chunks of content? And what if they have a two minute video? How do they consistently edit and cut varied chunks of content into a rippled edit? It's a tough ask. So I had to build an editor.
The trouble with online editors are they're a bit 'meh'. They give you too many or not enough options. And they're really expensive to run too - hosting video, streaming it to an editing portal and rendering the result. So what if you can do the upload somewhere else? What if you have video elsewhere already being hosted?
The RPPLE uploader
The uploader allows you to upload video - of course - but also pull it from somewhere else. Youtube, Vimeo - even Dropbox. All you need is a URL (and the copyright to do so of course). This allows a user to remix existing videos and distribute them in a different way. Once uploaded or linked, the user can then edit them.
The RPPLE editor
The editor is pretty slick. At the top you add your title and set your video to public or private - and we assign you a URL. Assigning the URL at this point is useful - it shows the video is uploaded (not in some partial storage or cache) and allows you to return to this page if you need to (say your browser crashed). The URL follows the video through the edit process through to completion.
The user can edit the video by clicking on the scene selector, which is all green and single width. By clicking they immediately create an edit with the option to choose the duration. A duration is chosen (in this instance it looks like 30 seconds is the right one) and the user fills in the header <h2> and body <p> copy. Then, going down the hierarchy the user can add comments, voting elements and metrics. Then they can choose an optional end board - for non-looped video this will be the bit that is freeze-framed at the end of the clip. For looped video this will be the pause before it restarts. This would allow you to add a note, small advert, or credit to the video.
The user can go back and change edits by clicking on the scene and changing the length, editorial copy, settings or end board, with the carousel below the scene selector scrolling to interact with the user interaction above. It replicates the process of watching the video - the two processes are purposefully similar. Editing the video should be as easy as watching the video which should be as easy as sharing the video.
In Summary
The player has many variants - voting modules, nested comment styles, proposed media cards, audio options...but these are all subject to any user testing. There are mobile wireframes. Flinto prototypes. But these are all 'nice to have' additions to this core player - in that the core player solves a problem. Hopefully one day I'll be able to return to it and make it better, refactor it again - and maybe finally release a working version of it.
Yes, hi-def prototyping is still important
I spent some time this year looking at framer.js and working out how it would fit into my workflows. Sadly it doesn't. Well, not currently. It doesn't currently because I'm quicker with other tools, and I'm a big believer in speed of execution - whatever it takes to 'show the thing' for initial feedback is the right tool to use. I use a lot of paper prototypes, but my normal workflow is:
Paper sketch > Paper prototype > InDesign wireframes (basic) > Feedback > InDesign wireframes (mid-def) > Engineered prototype (pair coded) > User testing
However, I've also started to add some tools to my toolkit for certain scenarios (usually visually lead stakeholders, AdTech people and content publishers). I'm a fan of Flinto for mobile mockups to demo transitions for example. I've used InVision before to mock up basic interactions for pitches and quick user testing (see here). For specific interactions I've even used After Effects - mainly because I'm pretty proficient in it after my time in broadcast design, but also as it sometimes has the nuances of actual interactions. By that I mean Z space, speed and time. The danger of After Effects prototyping is obvious - it takes ages to build and render and it's not 'hands on'. But sometimes it's a great tool to show the scope of interactions and it can be a great tool to bring designs to engineering when pair programming isn't an option (for example in multiple timezones). It's also a good way of breaking down animations and interactions into frame-by-frame elements. To give you an example, below are two videos. One is a high definition finished product I was working on at Dennis Publishing, which has been screen recorded with actual user interactions. Below it is an After Effects render of a mid-def wireframe to show proposed user interactions, prior to it hitting engineering. Sometimes interactions can make flat prototypes - well - make more sense.
Whatever it takes to 'show the thing'.
Balancing advertising and content in an age of fake news with The Week
A while ago I was invited to produce some designs and concepts for The Week - specifically their new online presence. I'd done work on their tablet and mobile app concepts - I'd even worked on some of their print based special projects - but this one was harder. Redefine new AD environments. Put imagery first. But hardest of all was trying to define The Week online. Here is a print title that defines itself by it's weekly retrospective on the previous weeks news. It's old news effectively, made new through considered and often complex hindsight. So how do you interpret that to an environment where the new, the immediate and the simple is encouraged? Grids, timelines and new AD formats? And before you ask - yes it was responsive. In fact the mobile views even had a daily podcast download ability that could be geo-fenced.
Building flexible online experiences for Somethin' Else
Back in 2014 (?) before I pivoted my agency, I was approached to produce a treatment for the broadcast agency Somethin' Else by the producer Kim Plowright. Somethin' Else are an agency that look after broadcast talent - and even broadcast production and programming for the BBC among others. It was specifically a web brief, but distributed media being what it is, a CMS driven flexbox site - while looking nice - probably wouldn't scale and adapt to a media landscape increasingly dominated by distribution networks, embeds and timelines. Well - it had to go beyond 'cards' anyway.
