With a new chapter in my career beginning, I've reflected on my time at Cluey Learning. Grateful for the opportunity to help school-going students across Australia and New Zealand with their learning—and learning much myself—over the past 4 years.
I am particularly proud of the Product Design function that I leave behind. Adamant about formalising principles and practices to steer experience direction, I resisted relying on individuals to "just do the right thing" or pick things up via osmosis as the team grew. While this can happen, leaving it to chance is risky, won't scale, and doesn't provide continuity when team members change.
Laying a path for how "the right things" get done is the role of design leadership, and this should happen before the team grows. I started the process when I was Cluey's sole Product Designer by considering what good looks like when designers:
- Facilitate workshops and discussions
- Interrogate ideas and opportunities
- Provide tool-kits and frameworks
- Echo the voice of the customer
- Deliver assets and artefacts efficiently and effectively
Then defining a product design methodology accordingly, setting standards I could hold myself to, as well as other designers once they were on-boarded.
The following are my tips for creating an in-house design function, ensuring long-term consistency, capacity and continuity:
1) Define product design for the organisation
Offer a definition of what product design is, and what it intends for the specific organisation. Designers often assume everyone's understanding of, or care for design is universal. Different people in different organisations however, will have unique perspectives about the role designers play. As functional leaders, it's up to us to provide that clarity.
To do this, answer the following questions:
- What is product design?
- What is product design at [organisation]?
- What does product designer consider?
- How do product designers do what they do?
- Who do product designer work with?
The answers should have the goals and values of the organisation in mind, and will form the basis for a product design methodology. This process begins to outline the obligations of designers when facilitating the design process.
2) Define responsibilities
Clarity around the role of design continues with stating the differing responsibilities between design leadership and designers. This is not just about who is in charge, but to be clear about the roles and expectations.
Design leaders are responsible for ensuring Product Design remains a consistent, considered and effective factor across varying initiatives. For that to scale, design leadership must establish:
- Method (philosophy or approach)
- Systems (tools, formats and channels)
- Processes (starting points and steps)
Designers can then be held accountable for how they work in accordance to them, with there effectiveness measured through:
- Rationales (justification of decision making)
- Consistency (application of steps)
- Efficiency (ability to prioritise and leverage tools)
3) Be specific about what's being designed, and think whole-of-service
We aren't always designing stand-alone smartphone apps or SaaS platforms. Be shape when explaining the scope and format of the product and service designers will be contributing to. This includes detailing the customer need, and how the product or service (seeks to) fulfil it.
Providing clarity regarding what the service is, intends to be, who it serves and how it's delivered ensures these concepts are omnipresent throughout discussions and workshops.
4) Setup practices and example them
Design teams are successful when they provide for both the business and the customers and must therefore consider:
- The business: Why a product exists for customers and the impact it can have on business objectives.
- The market: Who the customer is and what their “jobs” are.
- The experience: What conditions, including signals, features and flows, fulfil the customer “jobs” while supporting business objectives.
- The interface: How best to enable successful product use.
Construct a product design process which aligns to project or initiatives stages and outlines specific expectations regarding the role of design, and designers across those different stages, for example:
- Discovery (observe, stimulate, synthesise insight)
- Definition (experience design and rationale)
- Delivery (solution refinement and design ops)
For each, provide examples of what exactly these should look like so that designers have something to aim for and can development.
5) Define design principles
Having detailed the product, its market segment, customers, the brand and business objectives, leverage this clarity to determine the principles which will anchor experience design decision-making.
Design principles are unique, and sharp guidelines for anchoring design decisions and ensure:
- Solutions are unique and genuine to the product
- There are tools to interrogate decisions with
- Teams aren't reliant on subjectivity or gate-keepers
I've discussed this topic more in Making it yours | Developing product design principles.
6) Build teams with complementary skills
Product design is multidisciplinary field and a design function must be built with this in mind. When hiring new team members, consider the type of muscle they will bring to the broader group. That doesn't mean dividing work up by stage, but rather to ensure there are team members who can support or mentor their team-mates across the different stages of a project or initiative.
It's true Product Designers need to be cross-skilled and adaptable to the various aspects involved in designing products end-to-end, however, it doesn't mean all designers excel at all aspects of design from research to visual finesse. Considering complementary skill creates development opportunities because team members can take on teaching roles (in areas they excel), while learning from others in areas where they need support.
7) Set specific development plans for team members
To ensure individual growth for Product Designers, set a clear development plan which ladders up to business objectives within their sphere of influence. Highlight precisely how each facet of the plan aligns with the design team way-of-working and contributes to the outcomes being sought.
Break this down by articulating the differences between the types of tasks applicable to areas of development for designers, for example:
- Design operations: This pertains to when we know the problem, and the solution. Applicable skills include:
- Design system development
- User interface design best practices
- Visual design
- Software mapping
- Solution testing
- Monitoring and reporting
- Experience design: This pertains when we understand a problem but need to define a solution. Applicable skills include:
- User flows and wire-framing
- Journey mapping
- Storyboarding
- Concept testing
- Design thinking or discovery: This pertains to when we are still identifying problems. Applicable skills include:
- Research
- Storytelling
- Opportunity identification
- Root cause analysis
With this breakdown, it becomes easier to identify areas a designer will "own" more, and those they will need to "grow" more.
Together you can determine specific focus areas tasks to develop ownership, skill and further experience. These might be very closely tide to the domain a designer works in, or has a specific interest in.
To finalise the plan, you should answer the following:
- What are the specific areas of development?
- What will be the specific focus within that area?
- How does it contribute to specific goals?
- What is the designer expected to do?
- What skills will be developed?
- What specific tasks (or examples) should be done?
The development plan is not meant to be a separate list of tasks or side-projects aside from the designer's actual work but rather prompts on how best approach their work, and become better designers. This approach can also be used in conjunction with whatever framework your company uses for yearly goal setting, such as OKR.
8) Document, document, document
Document everything applicable to the design function in something like Confluence. It can evolve and change as necessary but it's important that there is a shared source of truth. For the same reason we need design principles, documentation ensures we don't rely on memory, or gate-keepers.
These are some example confluences pages which introduce and explain the concepts above to product designers and stakeholders at Cluey Learning.
Documenting should extend to the design system, a UX writing guide and of course functional features too. Below is a sample of how the "Cluey Bricks" design system is documented, with rationale on how the design principles apply to each element.
UX writing guidelines which cover everything from addressing users, to displaying time and alternative text rules and form micro-copy are also documented.
Aside from looking nice, documentation gives credibility to function by demonstrating the craft and care which goes into the working mechanics of design, and manifest themselves in Sketch, Storybook, and ultimately working software.
The documentation will also play a pivotal role when onboarding new designers or when circuit-breaking decisions are necessary.
9) Use the right tool for the job
Sketch or Figma? Miro or Mural? Teams or Slack? These debates waste a lot of time and energy. Use the right tool for the job, and consider tooling beyond the design function so the organisation gets what it needs too.
This is not to downplay the software we use, because it facilitates everything above, however everything above seeks to make designers more deliberate and purposeful. Tooling can only make designers more or less efficient, not better. Selecting the right format and forum for communicating ideas, collaborating with peers, or preparing assets should be where the decision making effort goes, for example:
- Finish UI in something like Sketch
- Prototype in something like Axure
- Collaborate in something like Miro
- Document in something like Confluence
- Present in something like PowerPoint
- Hand over to developers in something like Zeplin
- Meet and chat in something like Teams
Don't get caught up in whether Google Slides is better than Microsoft PowerPoint, focus on using tools that help the organisation share information, and ensure that there are integrations between software. Keeping information and assets synchronised while allowing access to whoever needs it is as important as what the tool is.
Conclusion
As a leader and manager, the concepts above helped ensure every designer in the team, myself included, was held to certain standards. Specificity is key—being deliberate and purposeful—so team members can be sure about the expected outputs and outcomes of the design process.
I understand that not every designer may want to lead, or set up a design function, yet I'm sure all designers have something to gain by working within a structured one.
0 Responses
