Shafeen AlamThree contractors to a global design team of twelve
When I joined BlackBerry I was asked to rebuild the design function. After the Good Technology acquisition the team had left, and what remained were three design contractors in Poland. Over the next six years I built it into a global product design team with its own toolchain, its own design system, its own research function, and a formal place in how the company shipped software.
With no team, tools, or process, design had no way to shape what BlackBerry shipped.
60-second read
After the Good Technology acquisition the design team had left. What remained were three contractors in Poland, no shared tools, no process, and designers reporting into engineering and product managers.
Centralize the function before improving the craft. One team, one reporting line, one toolchain, one design system, and a formal place in the delivery process.
Rebuilt it over six years. Won the reporting-line argument, standardized tools, pitched the design system to engineering, got design into Jira as a tracked dependency, and hired the first researcher.
A global team of twelve, renamed from UX to Product Design with its own HR leveling, and design present from the start of the process rather than the end.
Jump to
01 · Shipped
A design function that did not exist when I arrived: one team, one reporting line, one toolchain, a design system engineering helped build, and design tracked as a dependency in every sprint.
02 · What I inherited
Five problems, and only one of them was about design quality. The rest were structural, which is why the first year was mostly organizational work.
03 · The first three months
I started with tools, because a shared toolchain is the cheapest way to make a scattered group behave like a team, and because it produced a visible win fast.
Sketch
Migrated the team off Axure, so everyone was drawing in the same place for the first time. Unglamorous, and the precondition for everything below.
InVision
Two features did the heavy lifting: Inspect ended the practice of producing redlines and specs as a design deliverable, and comments gave the three functions one place to argue.
Principle
Licenses for prototyping the micro-interactions InVision could not express.
Trello
Visual documentation and project tracking, including a place to park the initiatives we wanted to tackle later.
04 · One team
The argument I had to win
The designers reported into engineering managers and product managers who did not want to lose direct control over what got designed and how it would look. Those were genuinely difficult conversations, and for BlackBerry it was a significant mindset change.
I grew the team from three to six, later to twelve, with every designer reporting directly to me. Then I broke the product silos, so designers could work across the portfolio using their specialties instead of being confined to one product.
What replaced the silos
A weekly team meeting we loosely called the UX Huddle: a visual standup where designers shared what they were working on and got feedback in front of each other. Twice-weekly working sessions followed, and later a standing meeting dedicated to maintaining the design system.
The point was not the meeting. It was that designers who had not known each other existed now had a room where their work was seen.
05 · Mentorship
A weekly thirty to sixty minute one-on-one with every designer. I treated it as their time and never forced the topic onto project work, which is exactly why it became the place we could talk about growth and their five and ten year plans.
They present their own work
I encouraged every designer to present in meetings themselves, with me there for support rather than speaking for them. It gave them transparency into the organization and let stakeholders know each designer and what they contributed.
A promotion ten years overdue
A senior designer who had been at the company ten years was promoted to Principal, through coaching and by making sure the right people could see the work.
Open door
On a team spread across five countries and several time zones, being reachable was not a nicety. It was the only way problems surfaced early.
06 · Getting on planes
Six trips in my first seven months: San Diego, Toronto twice, Waterloo, London, and Poland. The purpose was meeting the product and engineering stakeholders whose cooperation everything else depended on.
You cannot ask someone to hand over control of design over a video call with someone they have never met.
Wroclaw
Using Poland as a central point, I gathered the designers local to Europe and flew the two from Ukraine in. Six of us ran a three day workshop planning the high level initiatives and the roadmap for the year.
We also shared some very good meals, saw the city, and took a lot of coffee breaks. That part mattered as much as the roadmap.
07 · Pitching the design system
A design system is not a design deliverable. It only works if engineering contributes to it, so I went to the engineering stakeholders first, most of whom were in Poland, and made the case in their terms: a shared codebase and shared components, one design language, and the efficiency that comes with both.
I deliberately scoped it to one location and one key project rather than announcing it company-wide. If I could make it succeed once, I could replicate it everywhere else with evidence instead of a pitch.
08 · A seat in the process
Being invited early is a favor. Being a tracked dependency is a default. So I took a plan to the JIRA Council, who were very resistant, and argued for design to exist inside the delivery system rather than alongside it.
What we put in place
- Process workflows, so a ticket's status reflected where the design actually was and who was moving it.
- A dedicated UX project, a pseudo ticketing system where a designer picks up a ticket from a product manager and it becomes a mapped dependency on the engineering epic.
- A UX Kanban board, so designers could see their own tickets and move them through the stages of design.
- The InVision plugin, later for Sketch, giving live design state as a single source of truth.
- A UX Designer field on every ticket, so a designer could be assigned and progress tracked.
- A formal design backlog, grouped into larger UX initiatives, which let me argue for a percentage of every sprint.
- A Design Review Needed flag, so a ticket could not close until the designer had reviewed the built implementation.
- Formal go and no-go criteria, and a post mortem.
09 · Facing customers
Enterprise security customers are hard to reach and slow to trust. Three standing channels made feedback routine rather than exceptional.
UX Cabs
A quarterly session, virtual and in person, previewing what was coming to get feedback early. At the annual Security Summit we ran it over a meal at a local restaurant.
Beta programs
TestFlight builds of the apps we were actively working on, in the hands of key customers.
Feature enhancement requests
Customers filed tickets we tracked and reported progress against, which also fed release prioritization.
10 · Moving off opinion
I wanted the team arguing from evidence rather than taste. That meant establishing metrics for design, and a roadmap where each product release carried measurable UX improvements traceable back to end-user feedback.
The team ran heuristic evaluations and user testing, formally where we could and guerrilla style where we could not. We built personas, journey maps, and a jobs-to-be-done framework into the process, and evaluated analytics tooling we could integrate.
One metric I dismissed quickly was time on screen. In security software, a person spending longer on a screen is usually a symptom rather than a success.
Hiring research
I brought in an outside agency first, partly for the work and partly to make the case for research to people who needed to hear it from someone other than me.
Once that landed, I pushed to hire the function internally, so we had a dedicated user researcher the whole team could draw on rather than a budget line we spent per project.
11 · From UX team to Product Design team
The title work
I worked with HR business partners to establish the Product Designer role and its leveling, deliberately not inheriting the engineering template already in place. Every designer got that title instead of UX, UI, or Design Specialist.
It sounds cosmetic. It was not. We went from being the UX team to the Product Design team, and the respect and visibility the function got inside the company changed with it.
Absorbing an acquisition
With the Cylance acquisition I inherited four designers in Irvine, California, and the job of making one team out of two that had never worked together.
I also consolidated vendors. We were running three across Poland, Ukraine and Russia. I invested in one and expanded into South America, into Colombia and Brazil.
Where the team ended up
12 · What changed
contractors to a global function 3 12
every designer reporting to me, from three separate structures 1
consolidated, then expanded into South America 3 1
a senior designer of ten years, coached and made visible 1
The number I would defend is the reporting line. Everything else, the tools, the system, the research function, the seat in Jira, was only possible once design was one team answering to one place. A talented designer inside a broken structure still cannot do good work.
Delivery velocity and engagement figures from this period are not in my possession, so none are claimed here. The product case study covers what the team went on to build.
13 · Takeaways
You cannot raise the quality of the work without first fixing the structure it is made in.
