Summary
This case study outlines how I created a design management and communication process in a startup environment while following User Experience Design principles.
Problem space
I joined the startup as its first permanent and full-time Product Designer. However, there were already two UI design contractors, and not long after joined, we hired an additional permanent product designer. I was given the responsibility to manage the whole team.
The startup already had a product on the market, which has been designed by contractors and subcontractors. Unfortunately, most of the design work done had been focused on delivering proof of concepts: no real user research and testing work that been done. This meant that our design team inherited:
A product riddled with user experience issues.
A lack of design decision and process documentation, which resulted in a lot of iterations and review meetings as we figured out how to design new features while fixing issues in existing ones.
No design system and component library. In fact, design files weren't even on a Cloud.
Communication loopholes between design, engineering and quality analysis, which resulted in badly scoped projects.
The process
Discovery
Before finding solutions, I needed to understand why things were the way they were, in order to back my assumptions with information and feedback from the stakeholders to the design team. Part of this information was collected during my onboarding process, and the rest during project planning and review sessions. I gathered information about:
Pain points in the product development process,
The tools used to plan and track product development work,
What the rest of the product development team expected from the design team,
What the design team expected from the rest of the product development team,
How engineering and QA interpreted and used wireframes and prototypes,...
Defining
I then divided all the information gathered in themes and clusters, noting characteristics like:
Roles in the product development process,
Contributions to and expectations from the design process,
Needs, goals and frustrations,
Communication tools and styles, etc.
This categorisation allowed me to create personas representing the product development team/the stakeholders of the design process.
The personas
|
The visionary
Role: provides the company and product vision.
Goal: to deliver a product that meets customers' needs, is competitive on the market and earns revenue for the business and investors.
Expressed frustrations: designers don’t clearly understand the product vision and too much time is being wasted in design review meetings.
Needs: meetings booked and scoped in advance; sufficient time to review anything that needs to be reviewed, before meetings; to sign off designs and prototypes before development starts.
Preferred communication and management tools: Monday and email.
The project manager
Role: plans and manages the whole product development process (design, development, QA and deployment)
Goal: all product development teams operate effectively and efficiently to meet set delivery timelines.
Frustrations: not being kept in the loop about changes in the design direction, as well as the design team shipping solutions that were not scoped to match available development, QA and deployment resources.
Needs: to be involved in project scoping activities before any wireframing starts; a centralised place to keep track of design activities, decisions and progress.
Preferred communication and management tools: Jira, Confluence and Slack.
The design lead
Role: plans design work and manages the design team.
Goal: to ship well researched, designed and tested projects within set timelines.
Frustrations: insufficient time to take projects through the full UXD process, too much time wasted in meetings, constantly changing priorities and being asked to scale down projects that have already taken up a lot or resources (and love).
Needs: involvement in the product strategy process; the visionary to review and sign off designs and prototypes.
Preferred communication and management tools: Monday, Slack, Figma comments and Google Suite.
The designer
Role: delivers projects assigned by the design lead.
Goal: same as the design lead.
Frustrations: same as the design lead.
Needs: the design lead to plan design work better and foster a less stressful work environment; product vision from the visionary; project scoping that involves the project manager and the tech lead; more design research, thinking and testing time.
Preferred communication and management tools: Figma comments, Slack and Google Suite.
The tech lead
Role: leads engineering scrum teams, QA and/or deployment
Goal: to deliver products and features efficiently and within set timelines.
Expressed frustrations: same as the project manager.
Needs: involvement in the product strategy process; the visionary to review and sign-off designs and prototypes; detailed user stories and design specs.
Preferred tools: Jira, Confluence and Slack.
Development and delivery
Like Rome, the solution was not built in a day. The selection of tools to use to make and communicate design activities and decisions was a gradual and collaborative process that was sometimes met with resistance and went through multiple iterations, as priorities shifted and the company grew. That being said, design wasn’t the only team that needed to make improvements: all the product development teams had to review their processes to make sure that everybody was working in synch and efficiently. Positive results of this work included:
Less and shorter meetings
Better project scoping
More design research, thinking and testing time
Adopting a cloud-based wireframing and prototyping tool
The creation of a design system and a scalable component library
The creation of research data and design process libraries
A happier work environment!
Closing remarks
The delivery of a good user experience depends on the quality of the product development team experience!