A few weeks ago, Ost were delighted to announce the launch of the new BFI Player. During the usual post-project review - a chance for the project team to critique their internal process, and share learnings with people not involved in the project (I fall into the latter group) - Becky articulated something which has been bugging me for a while too.
The many angled ones
When designing digital products there are often so many angles to consider, that picking the right starting point for documentation can be tough. Here are some of the angles Becky mentioned she had to contend with on BFI (this is not an exhaustive list):
Angles that apply to most projects:
- User history: How does what the user has done before affect what they see now?
- User status: User tiers, signed in, signed out, sub/shared accounts, parental controls
- Annotations: Technical (e.g. mapping where data comes from) vs contextual (what happens when you click that) vs product rules (this view lists 10 films)
- Sitewide hierarchy and interaction patterns
- Responsive design
- Device variations: Input paradigms, business model constraints (e.g. Apple’s 30% commission on in-app purchases)
- Regional variations: Currency, language, content rights, business models
Angles which are specific to the BFI Player project:
- Pricing status: Standard pricing, offers, bundles, free to watch
- Purchase status: Bought, rented, gifted
- Watching status: Unwatched, part/fully watched, downloaded
- Content structure: TV Series, soaps, standalone film, film trilogy, collections
- Content status: Pre-release, released, expired
This is already a lot of information to juggle, but for some bonus complexity, usually several of these angles are inextricably dependent on others. For example, a Gold user might see different CTAs (e.g. early access previews) or pricing on a film than a Bronze user would.
Historically, wireframes have been expected to cope with the bulk of these angles, and communicate them in varying degrees to three distinct audiences, simultaneously acting as:
- A document for clients to sign off
- A reference for designers to work from
- A spec for developers to build against
In my experience, this usually results in wireframe documents collapsing under the weight of all these expectations, becoming unwieldy and horrible to read for all audiences, and laborious to maintain. Alternatively, they’d fail to do at least one - usually several - of the multitude of tasks comprehensively, causing issues elsewhere in the project later down the line.
Some good alternatives which relieve wireframes from some of these tasks have become more feasible in recent years. Tools like Proto.io and Axure (or Foundation and Framer for more code-savvy people) have made prototypes quicker and cheaper than ever to produce. Designing in the browser is also great for prototyping and testing lots of iterations quickly, but for large product releases I haven’t found it to be helpful at solving the angles mentioned above. Sketch is a good tool for UXers and UI designers alike, meaning both roles can work in the same raw files, making the jump between wireframes and designs - a jump we unfairly expect clients to easily make - less jarring.
We’ve also trialled a new way of working across departments, slightly shifting the workload to share the effort and creative license everyone has on the project. More on that in a later post, once we’ve honed the process a bit, but initial impressions are that it’s a step in the right direction.
Finally, the rise of the Product Manager and Business Analyst in agency world over the last few years has had an effect. These people are better equipped to straddle the gaps between departments and project phases, and provide more rigour to a process that was previously shared awkwardly between UX, design and dev roles. New, fitter-for-purpose documentation introduced by Product Managers again reduces the number of angles wireframes need to cover.
Redistributed but not resolved
And yet, as more and more tools nobly rush to the humble wireframe’s aid, the problems haven’t magically disappeared, rather they’re in danger of merely being redistributed. Instead of maintaining one core file, now specs, content matrices, interaction prototypes, and multiple other documents must all be kept in line, like the proverbial spinning plates. On top of that, sometimes documents previously ‘owned’ by UX roles are now shared by different departments. Likewise, clients now have to understand and review multiple documents rather than just a few.
It’s also important to acknowledge that when working with large clients, you rarely start from a clean slate. There are usually a host of 3rd parties to integrate with, legacy software and hardware to take into account, and client stakeholders from multiple departments with different ideas, processes and KPIs.
While we are big believers in our own processes and documents, it would be naive and arrogant to think that we wouldn’t have to adapt them somewhat for each project. Everyone else is not going to drop what went before to fit in with us.
What we’ve worked out so far
A good process for maintaining various documents across various teams throughout projects is something we’re still hammering out, and the way we’re doing it right now definitely needs refinement. However, I believe there is a good balance to be found that doesn’t require everything to be painstakingly kept up to date, but still keeps everyone singing from the same hymn sheet. It will no doubt take a while to get this process nailed, but this seems like a better alternative to what went before.
In the meantime, here are a few tricks we’ve learnt which have helped us through this transition:
Create a glossary
Every project has new concepts, and these concepts need names. For example, BFI Player has varied collections of content. Some collections are based around a genre, others around subject matter, others around what the BFI team are watching. Some contain just films, others contain a mixture of films and collections. All of these variations were referred to as ‘collections’ and this ambiguous terminology led to needless confusion.
To address this, the team created a glossary, which all conversations and documents would henceforth adhere to. Not only did this give everyone a shared vocabulary, but prescribing a name and description to each type of collection helped the team solidify their understanding of the differences between them.
Use correct palettes and fonts
I used to firmly believe that wireframes should be deliberately bland, using standard fonts and various shades of grey. The rationale was that this encouraged clients to focus on functionality and high-level layout first, and the fidelity could be increased later in the project.
Now I’m more of the opinion that using the correct fonts and palette not only helps clients visualise the end product more easily (reducing the jump between wireframes and design mentioned above), but it also pushes me to solve layout and hierarchical problems that I wasn’t previously encountering at this stage.
Isolate elements (particularly dynamic ones)
To avoid having to roll changes across multiple sections of a document (or worse, multiple documents), try and isolate elements. Depending on what process you're using, this could mean adding classes to your prototype, creating dynamic panels in Axure or splitting out your wireframe document. Typically I think of it like this:
- Pages are made up of sections
- Sections are made up of modules
- Modules are made up of components (some of which are dynamic)
In the case of BFI Player, a film page breaks down like this:
Rather than show the CTA (a dynamic component) in full fidelity on every page, a placeholder with a reference is used, which the reader can refer to for a comprehensive breakdown of all variations of said component. This might not sound like a big saving at first, but as this particular component appears almost everywhere throughout the site, quarantining it can make for big time savings later down the line when changes inexorably trickle through.
With so many angles to consider, designing digital products can seem extremely daunting at times. As with all projects, the trick is to constantly review and improve your process, trial new tactics, and work closely across departments as much as possible.