Rob is a product and multidisciplinary design leader with over 20 years experience building things you’ve probably loved.
Citymapper Smartbus - the world’s first 5000lb 50mph beta release
I’ve written and talked quite a bit about Citymapper’s Smartbus project and my role in it - including all the ‘official’ writing I did about it on the company Medium blog and in the press. But I wanted to give an overview of the project / product in one space because it’s such a vast project / product - and one I keep forgetting the sheer complexity of. So while this serves as a nice portfolio piece, sure, it’s also a static reminder for me about what I did for the entirety of 2017 and why I should be constantly in awe at what we achieved - especially over the first 4 months.
Before Smartbus was SimCity
SimCity started life as a MapBox map with some simple data overlays. The idea was born of a hack in the FE team to figure out how to overlay some of our live app and open source data and make sense of it. We wanted to investigate transit products, but we didn’t even know if there was even an opportunity - mass transit dynamics are complex, subsidised and buried in policy. This means that even calculating a basic business model is complex as everything is in constant flux and renegotiation.
SimCity with Journey Duration data overlaid
We started building a basic web app that would allow us to overlay user centric data onto maps. If the business models are complex and subsidised by price, then you can always compete on the singular level playing field - quality of UX. With UX our main play we began to look at population density, A to B desire lines and where the black holes exist in a cities infrastructure - black holes though politics, restrictions, funding or lack of density. Mass transit is for the masses - this means its focused on scale and broad strokes. A smaller operation could exploit those gaps, compliment the existing network and still remain competitive.
SimCity with Journey Duration data cross-referenced with live transit links
We ended up after about 4 weeks with a product that did some pretty cool things in multiple city environments (not just London as shown here). Using various live data overlays and historical archives, you could choose a time, day and place, draw a transit route you liked the look of - and the product would auto route your selection via GPS, chose the best stops and stations for peak traffic at the time and date provided, and show you your competitors.
SimCity in action - a hyper powerful Saas that allowed route planning combined with live transit and app data
You could plot a route, save a route and analyse it using algorithmic processing of millions of known and projected data points based on known human movement. From this we were able to calculate projected passenger numbers - by stop or station.
SimCity’s brains - predicted route analysis could be then be calculated in minutes via algorithmic processing
Combining live and archived traffic data we could then predict the P&L - along with labour and machinery costs - of running any transit route it the city. From this we could rank routes by user need or profit potential, make quick changes and tweaks, and use the analysis tooling and infographics to understand the stop-by-stop dynamics in terms of passenger potential vs cost. A shorter route is cheaper to run in fuel and depreciates assets less - it also costs less in labour and has a higher frequency (which passengers love) - but it limits its profit potential and reach, while also reducing the chance of that route joining two areas of a city that actually need to be connected.
The SimCity ranking system
We build many data analysis tools and infographic overlays to our data. But this was an internal tooling system, not a commercial Saas - and as such it was allowed to be quick, clunky and navigated by feel. This was very much a service design led project with some limited usability considerations.
We had now analysed thousands of routes, and worked out where to throw our chips. We had a route. We just now needed to work out how to build a bus.
Project Grasshopper begins
The full development stack of Smartbus from API to App to Bus to User
Building a Bus API isn’t easy. Neither is placing a server on a bus to facilitate that API. Buses are not really cutting edge tech - they’re cumbersome, heavy duty and - well - not a Tesla. We also wanted to deliver a Smart element to the buses. Sure, the bus was running on a Smart route thanks to SimCity, but we wanted to make the bus smart too. There are two key Smart innovations in this stack. Well, three - thought the third really sowed it’s colours later in the game.
The first is the concept of ‘Bus as a Platform’. The bus provides data of it’s whereabouts and behaviours, traffic and timings, passenger numbers and payments - in real time - to both the controller (i.e us) and to - and this is key - other buses. Smartbuses on a route are like an integrated mesh network - aware of each others status and proximity and able to self-predict their ETAs and passenger demand. This means they can talk to each other - and tell other buses to slow down or speed up depending on the current demand.
The second concept is the bus talks to the user. It shows transparent ETAs, location, other connecting nearby services, other Smartbuses, and even when to get off the bus (more on this later). The bus also talks to the driver. It shows the ETAs of other buses, how long to wait at stops, and it delivers simple information and two way communication to the driver about shift changes and start times.
The third concept is the bus talks to the Citymapper App, and therefore the user via their mobile screen and audible / haptic notifications. But it also responds to user inputs on their device too. It’s a personalised feedback loop, and one that benefits all the other buses in the mesh and therefore all other users of the network.
The first ever Smartbus rolling off the production line and straight into WIRED magazine
Other than the cutting edge tech, the bus needed an exterior and in interior refit. 3 buses in total and a lot of vinyl and signage. Most people know how to use a bus. It’s a lizard brain dynamic. But paint it green, change the payment terminal, add some screens…and it breaks something. The silhouette is changed. The UX shifts, the trust dissipates and new storytelling is required. Not everyone uses tech products, and mass transit caters for everyone - not just transit app nerds. The questions that were naive edge cases in development are no longer edge cases but massive critical issues. Should I get on this bus? Is it safe? Where is it going? Is this replacing my usual bus? How much does it cost? Will it tell me when to get off? How can I pay? Can I bring my dog on?
The integrated Smartbus screens providing live location and ETA data via live Bus APIs and app data
The driver UX is also critical in terms of usability and trust. Can they operate this bus safely? Is the screen a distraction? How do they reboot a Smartbus? How do they answer passenger questions? What does their uniform look like? How do they deal with platform bugs? What happens if the payment system fails? How do they communicate a problem? How do they change shift? Where do they pee?
Smartbus driver control systems delivered via Android tablet
The Smartbus driver control system user view
The bus controller ‘Boss View’ UX isn’t critical, but at scale it’s hugely important. Where are my buses? Are all my drivers on the road working? How can I contact my drivers? Are my buses bunching up? How bad is the traffic? Should I reroute a bus to avoid traffic queues? Who needs to go on a break? Has a driver exceeded their legal driving time? Is this route profitable today? How much am I burning in costs?
The Smartbus Boss View, allowing network controllers visibility over their headways
All of these questions are moot unless someone actually gets on a Smartbus of course. No passengers, no action. This meant using the bus to tell the story externally to potential passengers, making it look accessible, but also making it look trustworthy.
Smartbus rolls out through Southwark, London
Hark, Bigger buses!
Smaller buses are agile, but they also hold less people. Less people means lower demand routes, and lower profits. We spun up a fleet of six large buses with the goal of making the Smartbus scale.
A bigger Smartbus used to test a bigger revenue model
Smartbus interiors on a 5x scale
Smartbus rolls out on it’s new routes in East London
Higher frequency routes and more passengers means communications and payment UX becomes a critical part of the user onboarding flow. If the bus stops to onboard 10 passengers, to maintain the frequency of the service, the payment transaction process and boarding needs to be completed as quickly as possible. If it takes 10 seconds per passenger, each asking questions about how to pay and what to pay - that’s 100 seconds per bus stop, which totally derails the other buses frequency and schedules. It also annoys passengers being onboarded - and also annoys existing passengers with places to be.
Payment UX is crucial in transit, along with payment wayfinding
Transit payment communications and touch points are critical in passenger flow dynamics
Much like the smaller bus we needed the UX and storytelling to extend to the exterior of the bus - making it look accessible, but also making it look trustworthy.
External communications to aid with navigation, trust and passenger payment dynamics and flows
The bigger format of the larger bus allowed us to use large 40” OLED screens to expedite that communication and storytelling. However the time a user has to see these screens is limited - at the bus stop as they board, as it travels by at 50MPH, or if it’s stuck in traffic from the sidewalk.
We chose four in-flux screen states that allowed for a consistent narrative - location, payment, user benefits and at-a-glance plain language destination. The left side of the screen remained static, containing the crucial information relating to cost, route and route number.
Our internal UX also got an upgrade. We were able to improve on our Bus to User feedback loops and allow users to interact with the bus platform. With Busmoji we were able to give users a personalised experience - using the Citymapper App, the user chooses their route as they would normally. On boarding the Smartbus, the app signs them a Busmoji. When it’s their stop, the bus reminds them by showing their emoji on the bus screens. Great for drunk passengers - even better if you’re not sure of when to get off or have forgotten the name of your stop.
There’s so much more to talk about with Smartbus and it’s UX, but context is really key. Context of politics, context of legal limitations, context of public services. Here’s some other articles I’ve contributed to or written relating to the Smartbus universe:
Leading Design in remote and distributed teams isn't rocket science
If you have remote team members in your organisation — whether they’re designers or not — or if you have distributed offices in more than one city — then realistically you’re touching some of the issues associated with asynchronous or remote working.
Even if asynchronous or remote working is completely culturally abstract in your organisation, you’ve never considered it, there’s only four of you in one tiny office who always lunch together — or even if it’s something you personally detest the idea of and have sworn off it for the remainder of your career because reasons — you’ll still encounter some of the issues asynchronous or remote teams deal with.
This is in part because support for remote and distributed work is an inevitable end game for future businesses. The era of the ‘big city’ being essential to success is waning, while the empowerment of the provinces and a cultural drive to embrace a better way of living and working is in the ascendance. The fact is major cities are where they are due to their geographical relation to rivers, line of sight communication, rail lines, harbours and established trade routes.
These things are no longer deciding factors in your global design strategy. We have the internet now.
The good news is - it's a Design problem
In most orgs, regardless of size, design is the core power that binds development, marketing, sales, brand and business stakeholders. Effectively its role is to be the central, lateral communication channel. It defends the user, it actions and commissions research, it discovers trend, it crafts solutions, it communicates — and all of this affects the entirety of your products community, yet also the organisation itself - including the inevitable bottom line. Even if your org as a whole hasn’t realised this superpower design has to effect change, then even getting your design org to — at the very least — communicate effectively with each other, with minimal friction and shared knowledge - can only be a good thing.
I once worked in an org that was proud of it's 'low bus number'. This meant that a small group of employees had a huge amount of knowledge and therefore context - and therefore responsibility - and if those precious few employees were run over by a bus - the company would fail overnight. It was seen as a privilege to be one of those few chosen employees. To me that displayed pointless risk, and it was, as you'd expect, needlessly stressful on those precious few. It meant they couldn't take holiday, work flexibly or easily delegate. It also meant that every communication had to travel through them, every decision validated by them. This created a communication and knowledge fiefdom where knowing basic things to get a job done could often involve something of a knowledge quest for anyone 'normal'. So why did that org try to encourage a culture of 'low bus numbers'? Well, all ego aside, it was easy. It was easier to synchronise a few people than constantly synchronise everybody. It was trickle down communications - and if you're knowledgeable in any way about the realities of economic theory - you know that trickle down doesn't really trickle down. It just creates silos and vacuums.
I’ve seen several orgs struggle with these kind of synchronous / asynchronous communication and transparency problems, and the good news is there is an ever growing industry of cute sounding, pastel coloured products dedicated to solving the majority of these problems from $5 per user per month. In reality though, as you've no doubt deducted from the fact that 'low bus number' organisations actually exist, reliance on tooling is doomed to fail without a large cultural shift towards accepting remote and asynchronous concepts as being a positive and progressive development in the workplace.
One of the many reasons orgs struggle culturally with remote or distributed work is an existing regressive or inert culture of managerial control often founded in a requirement to 'be present' (aka Presentee-ism). This often flows from senior leadership, but it can also creep into teams as cultural regression - through poor hiring, org restructuring, poor cross-org communication or underdeveloped and unadaptive culture. In all these environments, as you'd expect, change is going to be hard. However design orgs are well placed to drive, mitigate and communicate change - it’s a service design problem at heart - and designers are perfectly equipped in solving these knotty human problems with a reasonable level of empathy and an elegantly crafted solution. Let's be honest - isn't every Design leader at some level re-designing the org that they sit within anyway?
I'm not going to list the full benefits of embracing remote and asynchronous work practise - I feel we're all aware of them by now and they're well publicised. Certainly if you've been trying to hire Designers lately you'll know of the talent demand for such environments. There's a reason for that. However it's worth noting that remote and asynchronous work practise can often be misinterpreted - it is not just about people 'working from home' - rather it's a practice that respects peoples choice of environment, cadence and personality. While there are many who work from their home office and shun the two hour commute and higher house prices, there are an equal number who work in co-work spaces, alongside other mixed discipline colleagues, or simply tour between clients and offices. In truth you just don't have to all work from one office to benefit from such crucial things as top global talent sourcing, quick scaleability, simple holiday / sick day logistics, open knowledge share, diverse global culture, hyper flexible working hours, clearly defined goals, roadmaps and documentation - and the most impactful - self-curated focused work environments. Designers are a wonderful mix of introversion and extroversion and need both periods of group discussion and periods of absolute focus. Giving them the power to curate and design these environments on a personal level is very powerful.
If you're ready to take on the challenge of building a distributed, remote or asynchronous-positive Design environment - here’s some hard-won personal opinion on some next steps, pitfalls and quick wins.
Sweat your workflow
Do the level of discovery and critique you’d do on a new product or feature launch — on your current and future workflows. Design has one of the more complicated workflows in an organisation, primarily as the work produced is often incredibly varied in scope and often open to subjective feedback.
Do you currently work face to face and have quick discussions over the desk? Great — but you need to work out how that scales in a remote environment. Sure you can FaceTime someone and have that conversation, but in a remote environment that conversation, those decisions — those actions — are outside of the team, and the rest of that team loose precious context on your decision making. Because of this, any new workflows for design need to be transparent, basic and heavily contextual. This initially seems like a large upfront investment of time — documenting all conversations and workshops, running regular all-hands meetings and recording them, coordinating time-zones for group chats — and it is.
But the benefits you gain from this investment are ten fold. It’s easier to track changes and decisions, it’s easier to onboard new staff and contractors, it’s easier for staff to take holiday, it’s easier to align stakeholders — because it’s all there for everyone to see.
Transparency of information and knowledge is your friend, and creating systems and workflows that encourage transparency and open discussion are critical to success. Making these systems and workflows asynchronous is an additional superpower, allowing offline thinking, reflection and considered commenting possible. Synchronous environments empower the extrovert and the quick-thinker over all others - don't discount slow thought, complex contexts and the power of writing as a way of structured thinking.
In my experience I’ve found a some key areas that aid this.
Firstly you need a solid accessible environment to create centralised documentation. This is playbooks, ‘why we did what we did’ and outcomes. A single source of truth. This environment needs to be easy to use and low friction otherwise it’ll never gain traction in the team if documentation is seen as a chore. You’ll also need to set expectations on the standard of documentation, where it lives, responsibilities for updating it, and who sees what and when.
Secondly you need a clear approach to workflow. I’ve placed Kanban into Product and Marketing teams with equal success — just remember it has to have maximum clarity and minimum friction — and you’ll need to, again, set expectations. Creating workflows like Kanban relies on each designer taking on some project management responsibility to maintain clarity at handover.
Thirdly, communication cadences are crucial. When do you run a crit? How do you run it? What are the timezones in play? What are the skillsets of the attendees? How do you keep your team in sync — especially if they’re cross-discipline?
Fourthly, you’ll need to focus on the design process itself and the resulting taxonomies. How do you create a brief? If no-one is there to crowd round your screen to make quick iterations — how do you do this? When you’ve created something incredible — how does it get signed-off? How do you collate and distribute stakeholder feedback? When it’s signed-off, where does it live and how can others find it?
For me I’ve found solving these problems as a team and getting buy-in on a team level the best approach. I’ve also found that (with one critical eye on tool-creep) that giving designers a choice over the tools they personally use to solve these problems to be beneficial in allowing a constant peer review of new and emerging solutions.
Treat this like a range of design problems. Get your team to work on them as a whole, and be sure to bring in all the skillsets relevant to that discussion. Have a video editing team? Copywriters? If they touch your org creatively, involve them at the kick-off discussion. Retrofitting other workflows is both painful and usually causes a lot of resentment.
Consider your whole design org
And by that I mean — not just the Product Design team. It’s easy to see Product Design, with its proximity to development and agile practise, as the perfect starting point for building a remote playbook. But think about Marketing Design and broader Creative teams, and their unique requirements. Sure they do a lot of print, video or social — but a successful design org is one that is sync, creatively, cross-discipline, and you should consider the same remote needs that a Product Designer would have applying to a graphic designer crafting MPU Advertising. In my experience it’s ‘all or nothing’ — but there are huge benefits. If your Product Designer is building a product onboarding feature, and they can see the Marketing output and message for the product in real time (and vice versa) I defy anyone to say that this level of dual asynchronous context is a bad thing. At their core, Product and Marketing design are 90% about communication of story — so if those two teams aren’t on the same page…what chance does the end user or customer have in understanding the story you’re telling?
Communication, Communication, Communication
You’re not going to be sitting next to each other — and if you are, others who won’t be sitting next to you will need to be looped in. Begin by treating any significant offline conversation as a sort of taboo — ask yourself if any element of that conversation is critical for group understanding. The worst phrase you can hear uttered in remote teams is ‘I wasn’t aware of that’. People being unaware of critical information (even if you don’t consider it critical) is incredibly dis-empowering and quickly causes silos which inevitably devolve into cliques, and before you know it you have low bus numbers. Your role is always to prevent that from happening. To solve for this, choosing your communication cadence is critical — and that cadence can be split into online and offline comms.
Online Comms (Synchronous)
This is primarily video calls. Zoom and GoToMeeting all have good cheap tools for teams and using it effectively means making clear diary touch points in your regular weekly workflows, and remembering to record and archive meetings for those who cannot attend. I’ve found having a general all-hands design meeting mid-week to be a good ‘go round the room’ opportunity to catch up and listen, and another weekly critique-specific session to be pretty much optimum. Any more than that and you begin to get meeting fatigue and attendance will drop — your designers will be having numerous other meetings themselves inside their teams, so optimising the time you have as a group is critical. Slack is also your friend, however others have found tools such as Basecamp to be better for their workflows. Either way a continuous IM channel is critical.
Offline Comms (Asynchronous)
This is likely to be split into documents, workflow and assets. For documentation I’ve had success with Notion as a powerful centralised asynchronous document environment, however Dropbox offers it’s own version which some will prefer. For workflow, Asana has a low impact Kanban and list option for managing jobs to be done. Product Designers may prefer Jira to sync better with their development teams — the best tool here is usually the best tool for the job, and that can mean multiple tools (I run Asana and Jira) but the key is to give everybody access to everything - even if they rarely use it in their day-to-day. I’ve used Trello, Meistertask — there really is no shortage of options — however considering the workflow you apply to those tools is much more important. For asset management I've found the tool selection is usually driven by cost - the taxonomy is critical to how useful that tool is.
Sometimes synchronous can be hard if your timezones are extreme, but even in the worst extremes, there’s usually around two hours crossover during ‘reasonable’ working hours. Of course this puts pressure on those two hours of possible communications — squeezing an entire day of discussion into 2 hours is tough, but it forces focused meetings quite quickly, which is a good habit to build. Having said that, if there’s one thing that extreme timezones do beyond encouraging better meeting hygiene — it’s that they force you to discover the benefits of asynchronous workflows very quickly.
Criticism and Feedback
In remote communications environments, the process of criticism and feedback quickly becomes core to team success. Your weekly crit sessions become very important, and it’s necessary to make sure those meetings are coordinated well to create maximum value for everyone involved. There are a few tools to help with crit and feedback, but I’ve found in running remote crit that it’s important to schedule the work being critiqued in advance so everyone turns up knowing what their involvement is — and they have time to research the context from documentation before they log in. I’ve found that the designers who leverage the best critique are the ones who communicate up front what they want critique on, rather than awaiting a generic Q&A from their peers. I’ve also found making the crit session non-compulsory to be more respectful of people’s time where there is always limited space in the diary - the teams time is reserved in the diary once a week, you just need to bring something to the table.
For critique and feedback there are, again, offline and online elements. For online I’ve found Figma to be a great centralised design tool to coordinate different design disciplines (from Product to Marketing to Brand) under openly shareable transparent URLs. Invision Studio is similar, and both tools offer prototyping, presentation and support screen sharing. For offline, these tools also offer commenting and collaboration at the core of their products. I’ve found commenting and multi-user collaboration to be incredibly useful, and is something of a game changer in distributed teams. How you use commenting and collaboration in these tools however can be a contentious discussion — it’s entirely possible for 5 designers to pile onto one artboard and begin altering someones work, and the danger of ‘design by committee’ naturally increases with such powerful features. Your team needs to work out together where their red lines are in collaboration, and have awareness of how each other work, and prefer to receive feedback.
Coaching and Leadership
Remote teams need more coaching — or they seem like they need more. This is really due to you having to schedule it rather than it happening in typical daily conversation. The benefit of that though is it causes focus, and means the coaching can have more impact. Leadership also needs scheduling, but in reality remote or distributed teams need a slightly more passive lightweight form of leadership — you’re not organising group lunches and meet-ups and seminars, now your role is to make sure everyone is in the loop, concerns are addressed, communications are clear and transparent, and agreed documentation and communication cadences are being adhered to. Does it feel less social and more janitorial? Yes. Yes it does. But it doesn’t mean that it can’t be rewarding. I’ve found distributed and remote teams need more individual attention — coaching individual designers to find their leadership qualities and embrace them. Turning your entire design org into a team of design leaders is a very satisfying proposition — more so than expensing a group lunch or dragging everyone into the office via a two hour commute to attend a meeting.
Ownership
You’re not physically there, so you need to empower your team with ownership over their own work and their own ways of working. As you move towards distributed teams, so the ‘hovering Art Director’ in you has to take a back seat. Trusting that ‘things will get done to the required standard’ now becomes a key component in how you work together. Working with your team to discuss and define ownership — and then getting them to ‘own’ that ownership — is a crucial to them being able to perform remotely and build trust — both with you, and with other designers.
Turning up
You have to be face to face sometimes. Remote is great and everything, but there’s always going to be a need to spend time with those in your org; whether that’s to connect on a personal level, gain skill transference, kick-off a complex project, or just to bond as a group. Depending on your budget, those face to face opportunities might be decided for you.
Onboarding
Any new staff member will have an impact on the teams dynamic, but it’s not realistic to get the whole team together every time you hire someone (especially if your company is scaling quickly). Involving your team in the hiring process is always good practise regardless of work culture, but involving them in the onboarding is more important in environments where hanging out at lunchtime is harder to do. I've found onboarding new people through self-guided asynchronous tasks to be really useful for both manager and new starter; spin up a task board (it might be in Trello) and get your team to contribute to it (ask everyone 'what things did I need answers to when I started?'). I usually add tasks to grouped topics such as 'people to speak to', 'software to sign-up for' and 'links to key documentation'. The benefit of this approach is the new starter gets to keep this asynchronous onboarding for future referral - which reduces stress significantly in the first few weeks on the team. I also feel that turning up to meet them on their first week is hugely important. It shows you care, sure, but it removes fear in any new starter - I've flow 12 hours to mitigate that fear. Starting in any new culture is nerve-racking, so you should do your best to mitigate that worry with quick-to-access processes and be there as a friendly face to ease them in.
Leading
If you are a leader you have to pick a cadence of turning up that is optimal for your team. I’ve found something akin to quarterly useful, especially if your business runs a quarterly OKR process to define the business or team level goals. Get on a plane. Bring people together who need to be together.
Teams
Bring teams together that need to be together. That’s obvious. If you have a remote team that all work together on one product line, find a time for that group to meet in person maybe twice a year organised around what makes sense to their work. Let that team decide that cadence, and do all you can to support their choices. However as a leader, consider who from other teams should also be there — if you’re building a commercial product, is there a benefit in bringing Marketing Design and Product Design together? If Video Production is a large part of your onboarding, shouldn’t they be essential to any face to face meet up?
All Hands
Sometimes you have to bring everyone together to meet up and get to know each other. You’ve likely been working hard to prevent team silos, but even in the best case scenario, it’s likely you’ll have designers and creatives — or key stakeholders and colleagues — that have never met in person. Most companies choose to do this on an annual cadence over a one week retreat, which is great. Do it. But does your broader design team need that opportunity as well? Large retreats can be overwhelming and with so many faces, people can find it tough to connect on the things that matter. Consider the need for a smaller retreat to balance it out with a more focused agenda.
Celebrating Diversity
One of the wonderful prospects of remote and distributed teams is that the culture enables — and promotes — diversity and inclusion. The fact that the highest paying jobs and opportunities are in big cities, and the cost of education, combined with living costs vs renumeration (especially when you’re beginning your career) means that working the best jobs at the best companies in the biggest cities favours those who come from affluent backgrounds, who most likely are white, who most likely are male and who most likely have no complexity in their background. This means that there is a huge talent base internationally that cannot access the opportunities that they might be perfectly aligned to given the chance. If you have a family you care for, elderly parents, children, a non-affluent family history, or are a minority for whom opportunity is less accessible — which let’s face it is a lot of people — you can’t just up and leave to New York, London or San Francisco to throw down $3K on an apartment rental. And why should that sacrifice — or attainment — be the defining factor in your career success? Is it because the role you are qualified for, for whatever reason, requires you to be present in an expensive city, despite the fact that it — if we are all really honest — could be done from anywhere? Is it maybe because the people who run that company could / can afford to be in an expensive city and therefore presume others can?
The greatest benefit of remote and distributed teams is you can tear up the existing rulebook and look to build a different kind of org based on talent, skillsets and experience — regardless of location, background or privilege. In design, diversity is its lifeblood. Finding and solving user problems, communicating to broad ranges of people, communities and cultures — this is what design does. But without diversity in that design team, it’s just endless appropriation. The most exciting thing about the prospect of a remote and distributed future is the basic freedom it gives in team building, and the access it gives to a broader spectrum of great talent — wherever and whoever that talent might be.
Building a Design Culture - a brutally honest primer for non-Design people
So you want to build a culture of Design in your organisation. There are usually two underlying reasons why you would want to do this.
The first reason is entirely selfish - you want to attract (and retain) Design talent. Design talent will probably ask a lot of questions before considering joining your organisation, but their first two questions are usually - 'do I actually have to physically turn up at an office?' and 'what is your Design culture like?'. You want to have an answer to that last question.
The second reason is because everyone knows from Medium, InVision's $135 Million CRM strategy and a growing number of repetitive conferences - that Design thinking and Design culture is 100% the key to success in business these days. So...you know...you want to be the one to bring that magic into your business.
Makes sense. Design culture sounds sexy and exciting. It's going to be complex journey though.
Why Design cultures are hard to build
You can't build a culture, you can only tirelessly enable it.
You can't bullshit culture into existence overnight or as part of your Q1 strategy. It takes time (in fact it can take longer than a year and even longer than any single Designer or Design leaders tenure) and it needs constant gardening.
Gardening is highly rewarding but always more effort than you expect and often more janitorial than you imagine.
You have to implement culture at the absolute top leadership level so that...
...people feel empowered to embrace and personally invest in it so that....
...it doesn't feel like some shitty executive box-ticking exercise - or worse - it's actually going to be a published company OKR.
It has to be led by actual Design practitioners who are active independent contributors. This isn't a human resource thing with an attached metric, it's definitely not an executive-led employee education programme, and it's certainly not defined by the outcomes of 'workshops' and 'off sites'.
Any culture will be unique to your organisation, so you can't carbon copy some abstract Medium post into a team meeting and expect magic Design beans to suddenly start growing all around you.
There is no culture without trust. Trust takes time to build and needs consistency - consistency of people, consistency in the attitude towards Design - and consistency in how Design is communicated across your organisation. If you have high churn, regular departmental overstepping, disempowerment and a lack of Design definition - you'll struggle.
Big changes will happen. If you're fortunate enough to get a Design culture seeded in your organisation - it will change things in every area of your organisation. That's what cultures do and that’s why you wanted to build one - right? So you'll need to be thirsty for that change and all that lovely Design empowerment that's going to happen everywhere outside of your control.
It's likely your Designers have already discussed all of this already amongst themselves and have probably made some decisions. You'll need to find out what those decisions are, why they were made, and why they haven't turned into a culture you recognise.
It's more likely your Designers actually have a Design culture which you're not aware of and - wow - that's a little bit embarrassing.
If you're a Designer then you know the situation, know the blockers to culture, and know what your team needs. It's your job to figure out how to unblock that stuff and through working with other Designers figure out what that Design culture is beyond just your team. Of course, because there are Designers - boom - there is a Design culture. But you'll need to all decide if this is something you want to push and strive for in your organisation - and if it's worth it. Because in all honesty, sometimes it's not.
If you're a non-Designer - all you can do is enable. Listen to Design and use your skills to present the need for Design representation at the top of the business. Without that the culture will remain subservient and wing-clipped. Which would not only be a shame, but it's also not going to inspire others to invest in it.
How to build - and define - a Design Organisation at scale that makes sense to HR
If you’ve moved beyond hiring one or two designers in your org then you’ve begun to add complexity and additional hierarchy. Managing this transition is actually pretty tough - there are a lot of hierarchical job titles one can apply that imply progression, but most instigated design hierarchies fail to address things like skill acquisition or long term career development. Most importantly they fail to address that in creative roles there is a clear difference between leadership and management - and in creative roles, there is usually a healthy mix of natural contributors and natural managers. Design is one profession where some of the greatest talent will actively avoid people management to preserve their contributory ability, and because of this there is a very clear need to define leadership not in terms of management, but in terms of expertise and mastery.
I’ve come to remove traditional hierarchies based around management from my teams, preferring instead to create defined skills to master. Mastering these defined skills allows progression, and those skills can be gained through broader personal management or through personal contribution.
I’ve reduced these core skills down into 9 definitions, within which there are some layers (such as leadership), and it maybe that your org may have multiple layers in some core skills and not in others depending on the kind of design you execute.
These skills are learned in order (for example an inexperienced designer would begin by mastering ‘discovery’ and ‘execution’ before moving on to ‘strategy’) and can be used to define incoming candidates, but also to track career performance and progression of existing staff and even allow you to align this progression to renumeration.
For example you can apply it like this:
Product Designer - Level One - $80K
Discovery + Execution
Product Designer - Level Two - $85K
Discovery + Execution + Strategy
Additionally I’ve found using these skills as benchmarks replaces ‘time in role’ as a defining factor in renumeration or progression. This has been largely positive, allowing teams to promote high performing talent at the correct speed to prevent talent turnover - we should be progressing and pushing someone with the skills and talent rather than blindly progressing purely through time on the clock. For those who use headhunters or recruiters, I’ve found these skill definitions to be a quick and easy way of defining the standard of candidate needed by a hiring manager - especially when it’s used consistently.
Here, in order or progression are those skills and their associated definitions. They’re still a work in progress, but do feel free to give feedback on them.
The Core Skills in a Design Org
1. Discovery
The ability to use discovery tools and frameworks to understand and define the problems which have been identified.
2. Execution
The ability to create and build suitable flows, visuals, behaviours and interfaces that are the solution to the problems defined in Discovery.
3. Strategy
The ability to abstract from the defined problem, define the validity of said problem, and validate hypotheticals against relevant user research and the broader global business requirement.
4. Communication
The ability to build stories and brands beyond the user flows, maintaining consistent and trustworthy environments that are both digital and non-digital in their Execution.
5. Operations
The ability to build, create and manage service design aspects which create solutions beyond product level problems, functions that change team or company dynamics, ways of working, or ways of scaling.
6a. Leadership (I)
The ability to mentor, train or lead teams, squads, cross-team groups and thought processes.
6b. Leadership (II)
The ability to mentor, train or lead teams, squads, cross-team groups and thought processes and transfer this to other teams in the wider org. This may also involve People Management.
6c. Leadership (III)
The ability to mentor, train or lead teams, squads, cross-team groups and thought processes and transfer this to the global org changing and improving behaviours, processes and the understanding of design. This may also involve People Management.
6d. Leadership (IV)
The ability to mentor, train or lead teams, squads, cross-team groups and thought processes and transfer this to the global org changing and improving behaviours, processes and the understanding of design, including technical systems, information architecture and service layers. This may also involve People Management.
6e. Leadership (V)
The ability to mentor, train and lead teams, squads, cross-team groups and thought processes and transfer this to the global org changing and improving behaviours, processes and the understanding of design, including technical systems, information architecture and service layers beyond executional teams and squads, but rather into other departments, such as Sales, Operations, Development, and Growth. This may also involve People Management.
7. Guardianship
The ability to own experientially - and tonally - a range of product verticals with the ability to defend and communicate said experiential and tone to the broader business, partners and external agencies. The ability to become the ‘guardian’ of the product architecture / multiple brand architectures.
8. Authorship
The ability to speak, write, create and curate across all experiential and UX touch points, accurately on behalf of multiple brands and their stakeholders. The ability to become the ‘voice’ of the user and to use this voice to speak freely to develop future conversations, flows, experiences and stories, - all while gaining the trust of owners, partners and stakeholders to do so.
9. Governance
The ability to govern, protect, project and continually reassess both the Guardianship and Authorship employed across a range of product verticals and to ‘steer’ products, brands and stories using this knowledge to maintain relevance, competitive advantage, alignment to trend, alignment to research and alignment to best-in-class execution. Deep level research and the resulting working knowledge into demographic, alignment and distribution is something which is essential to governance and allows for complete ownership of stories and experiences whatever the product vertical or business requirement.
Because Design principles are important and so is communicating them
I’ve created Design Principles for many of the projects and orgs I’ve worked with, and implemented them often in different ways. Implementation often depends on how the org communicates design internally, or where design sits in the orgs DNA. Here are the Design Principles I recently created for Verve and it’s associated product lines. It was designed to be broadly applicable, from conceptual through to customer experience - and designed to be adopted by the entire org. These principles are pretty typical in terms of solid principles - they cover experiences, tone, inclusivity, detail and end-to-end expectation - and also maintain relevancy beyond the design department.
Most important they’re also understandable by non-creatives - and because of this (and the millennial nature of our org) I distilled them into GIFs and images.
Often designers create rules and silos to empower themselves in an org, to make themselves appear important or to ‘land grab’. That’s usually understandable - it’s nice to define your own patch and defend it, especially if your experience of design within orgs has been largely negative; design as an add-on, design as a framing device, design as ‘polish’. The problem with this however is it comes across to others in the org as a defensive, if not uncommunicative position to take.
Designers can - and should - empower their orgs by giving away their skills freely, be transparent and de-mystify their processes. By doing this design becomes an aspirational skill to be adopted, mastered and therefore appreciated by all within an org, and from that understanding a professional respect is formed. Sometimes it takes someone being empowered by a skill to realise how tricky mastering that skill is - and by proxy appreciate and gain empathy for the complexity of wearing that skill professionally.
By empowering everyone in your org to understand and believe in design and it’s principles, you bring design into the org completely - without the need for trojan horses, battle cries and those endless whinging emails no-one reads.
Our Design Principles at Verve
Cooperative AF.
Everything we design is designed with others in mind.
What we design should work in cooperation with our diverse range of products, brands, clients, users and user networks. We never design in silo and we prioritise company wide integration of the solutions we create.
Inclusive AF.
We design for everyone.
We design for users internally and externally who are global, diverse and have different objectives, expectations and needs.
Keep it simple M8.
We don’t make people think.
We design for known behaviours, default reactions and real emotions. We never get in the way of our users actions or make it difficult for them to discover or navigate anything we create.
Always Transparent. Always Trustworthy. Always.
We are clear and open about our intent.
We don’t hide behind dark patterns or create unexpected behaviours. We are always clear about the intent of what we create, and strive to represent a source of truth to our users and gain their trust.
Where the wild things are.
We design experiences in places where our users choose to spend their time.
We’re mobile first and socially focused. We work with distribution in mind and consider how and why things are shared. We make sure we have first hand experience of living in these places.
A tiny part of a big experience.
We enable people to create great experiences, but we recognise we are a small part of that.
We are a small part of our users bigger experience with their network - we recognise that and remain humble. We celebrate offline experiences not in-app experiences.
Beginning, Middle and End.
We tell well defined stories.
From our user flows to our content, we make sure our narratives are clear, structured and functional. We avoid cliffhangers and unhappy endings.
Sweat the Comms.
We are focused on the clarity, consistency, frequency and tone of our communication.
We are honest and candid in our communications and communicate to maintain expected rhythms and maintain trust - both internally and externally. Oh, and tl;dr.
Usability with all the feels.
Accessible and usable doesn’t mean boring.
Simple and easy to use design can still communicate emotion. Being ‘Accessible’ and ‘Usable’ isn’t doing someone a favour - it’s our job.
Excite. Delight. Inspiration. Aspiration.
We curate and create unique ‘wow’ experiences no matter the medium, subject, audience or vertical.
From video to CRM , from social to stage, we always strive to create ‘wow moments’ within the useable environments we design.
Why Tho.
We question constantly.
We always question the way things are done and the existing ways of doing things. Our users move at the speed of light and it’s our job to keep up.
How to give creative feedback to creatives if you're not a creative
Giving feedback can be a tough thing to do - especially within creative teams. It’s also likely that you’ll be in a situation when the person giving the feedback isn’t creative themselves, which is both intimidating for the creative and the non-creative as they try to find shared language and approaches to move things forward. Here is a simple guide to structuring that feedback and how to both prepare for - and to give it.
Things to consider when giving or planning feedback
Should I actually be giving feedback?
You should only really give feedback when your feedback or expertise is relevant
Sometimes we can find ourselves giving unsolicited opinion on things that either aren’t in our skillset or perhaps we just don’t have the right context. When this happens, our feedback becomes ‘opinion’ and unless you have been asked for an opinion (or you have asked if you may contribute an opinion) the risk of other expert feedback being confused or overlooked increases.
This is especially a problem if the feedback of an expert is overlooked or an expertise based critique gets disrupted due to a well-intended opinion.
How should I set myself up for feedback?
You should choose and create a feedback group you trust - with each member of that group having the specific expertise you need to get the job done
A Designer wanting feedback on a campaign should create a feedback group containing all the experts their campaign will touch. This may include: Sales, Marketing, and Product Line experts. They’re also likely to include another Designer to that feedback group to check their own bias and quality of output.
It’s important to balance the feedback group carefully to make sure it contains all the voices and expertise required for success - including someone from your own expertise.
Try to stay in your lane.
You should only give feedback related to your specific role in the project
This doesn’t mean that someone in Sales can’t feedback to a Designer, it’s just that the feedback should be relative. In this example, Sales have an expertise in the marketplace and with the customer or partner. Feedback should therefore be given through that lens, rather than a direct critique of the design itself - a critique which another designer would be better suited to provide.
Giving context of your role and expertise in the feedback process can open up better discussions, and allow people to learn from you and you from them.
Subjective is bad.
Without your expertise or role focus, feedback just becomes opinion
Saying ‘I don’t like’ something doesn’t forward the discussion or improve the end result - you have to show, via your expertise, why your feedback is relevant. Otherwise the person receiving feedback has to de-code your feedback - or worse - will just ignore it.
Instead of saying ‘I don’t like this’, consider reframing your feedback to reference reasoning such as “in my experience in ‘x’ market’” or “here is a relevant example of something I know works in this market”. Use this as a reference point in moving the conversation forward.
Check your bias.
Everyone has a bias
Maybe it’s personal bias like - ‘I love the colour red!’ Maybe it’s a professional bias - something you want to personally achieve, do or be involved in. All this is fine, but you should consider these biases when giving feedback. It can prevent new ideas, approaches and solutions being formed.
If everyone in the feedback group has a bias (which they will) it can cause personal opinion to cloud actionable feedback. Check your bias and challenge it - is this relevant? How did I develop this bias? Should I apply this to my feedback?
Everyone is aiming for the same outcome.
Feedback can feel like a battle of wills sometimes
Always remember - and the group should articulate this clearly - that everyone is giving feedback to make sure the end result is the best it can be. Sometimes reminding ourselves at the beginning of a feedback session of what this agreed end result / success looks like can encourage more aligned feedback.
Sometimes this can mean constructing your feedback to make sure that it is angled towards everyone finding a consensus or shared result, and sometimes this can mean compromise towards a bigger goal - it’s not about personal ‘winning’ or scoring points.
Feedback can be painful.
Often the person who has produced the work requiring feedback has invested significant time and emotional energy into doing their best work possible
It’s worth always remembering this. Accept that the person receiving feedback is likely ‘exposed’ and may take things personally or become defensive. But if they are remember it’s because they care deeply about the outcome.
Give them time to explain their thinking and how they got to where they are before you jump in with critique. Defensiveness is usually caused because someone is worried about being misinterpreted or not being able to communicate their process.
It’s not personal.
When we receive feedback it can feel personal
It’s tough - when we’re invested - to abstract ourselves from what can sometimes feel like a personal attack (especially if that feedback has been worded poorly).
Ask questions and see the feedback process as a conversation - why is this feedback phrased as it is? Can it be rephrased? What do you mean when you say ‘x’? Dig deeper and do some discovery - it’s a great opportunity to learn, but also to improve others feedback ability.
Have you considered?
If we accept that someone receiving feedback is doing their best and is working for the best result - we should be also be considerate in our phrasing
It’s very possible that many of the options you’ll suggest were considered before the feedback session, so feedback should recognise this possibility. An example of bad feedback is “This isn’t right, it should be red because that’s our brand colour”.
An example of good feedback is “Have you considered using red? It’s our brand colour”.
Asking this question allows the person receiving feedback to respond rather than defend - it maybe that they HAD considered it, and this will give you a clear reasoning as to why they then did what they did.
Be respectful.
Remember the person asking for feedback is an expert also
We should always respect each others expertise. Because of that we should never use words like ‘Bad’, ‘Weak’ or any form of negative phrasing where possible as everyone has strengths where others have weaknesses. Use the feedback process to ask questions and discover why an expert has decided on a course of action.
Feedback sessions go both ways - it’s not just a show and tell. It’s an opportunity for mindshare towards a common goal, and a way of understanding each others expertise and reasoning around topics.
Give Praise.
It’s ok to say nice things
People respond well to praise (who doesn’t like to be told they’re doing a great job?), and in exposed situations like feedback sessions, praise can be a trust building part of the feedback process. Rather than say ‘this is good’, however, say ‘this is good because ‘x’. This allows the person to understand what - to that expert - good looks like.
Explaining why something works or is good allows that person to understand this for the future and apply it to other projects - it’s a great learning tool.
Agree Actions.
Feedback without actionable results is just discussion
Make sure your feedback discussions result in tangible ‘to-dos’. Agree on those and make sure everyone in the group agrees on those next steps to ‘align’ the current presentation before the next feedback round.
Feedback gets derailed and people get frustrated when agreed feedback is ignored, or feedback is opaque and unactionable. Make sure you have consensus as a group and accountability and set a date for the next session - before ending the feedback session.
An easy to use 1/2/3 feedback framework
Ask > Discuss > Agree Action.
1. Ask (“Have you considered ‘x’? Followed by your expert context and knowledge)
“Have you considered making this red? The research we’ve done on brand suggests this colour is the best choice for maintaining consistency across this product vertical”
2. Discuss
Allow the subject of the feedback session to respond to this question and listen carefully to their reasoning. Respond to this reasoning with follow up questions if required and use these questions to frame the discussion.
3. Agree Action
Decide the best way to move forward - what will be done, when and by whom.
Ruinous Knowledge is a thing and it's dangerous
Ruinous Empathy can kill team critique, but Ruinous Knowledge can kill entire products
If you’ve researched or adopted ‘Radical Candor’ as a technique to provide high performing teams with high performing communication and feedback, you’ll know about ‘Ruinous Empathy’. ‘Radical Candor’ can be a weird fit for creative teams in my opinion, but Ruinous Empathy is one of the things I find always annoyingly prevalent. Ruinous Empathy is what happens when you care but don’t challenge — when your praise is just not specific enough to be either relevant to the person it was intended for, or it fails to allow that person to understand why the praise was given in the first place. Or equally it could be criticism that you’ve sugar coated to such an extent that it’s unclear — or worse —it’s even unrecognisable as criticism.
In reality Ruinous Empathy is something which is personally protective and ultimately selfish. ‘I’m comfortable being nice, so I won’t go beyond that comfort — even if this means both my praise and criticism becomes unclear or insincere thus devaluing my actions’. It’s a default, which is a comfortable happy place where everything is nice and, well, why change nice?
Good criticism is hard. Good praise is hard. Being constructive is hard. Not relying on ‘how things used to work’ is hard.
‘Ruinous Knowledge’ is equally personally protective and selfish. It’s reading all the research, adopting user focused emotional intelligence, absorbing personas, analysing brand impact studies; it’s talking to users, feeling their pain, building the playbook. All this is stuff you should be doing of course, but Ruinous Knowledge takes this knowledge and makes it comfortable by sitting on it and devaluing it. When the research supports the personas we’ve created — do we challenge it? When the team ‘knows the user so well on core issues’ that they make deep behavioural decisions based on past knowledge — do we question that? Do we question those who inhabit our users voices or the voices of our brands? Do we use phrases like ‘we know from past experience’ and ‘usually we’d expect’? Do we personally avoid discussing new ideas or new ways of working because we don’t have the research on hand to back it up? Do we dare to suggest we know enough about something?
I’ve been guilty of both Ruinous Empathy and Ruinous Knowledge before and they’re both good things to watch out for and attempt to professional eradicate as much as possible in your personal output — but it’s Ruinous Knowledge that makes me the most self-aware. Ruinous Empathy can make a design leader frustrating to decode, but Ruinous Knowledge can destroy whole products.