UX Design Memo

Photo by AbsolutVision on Unsplash

There is a case that before I went off a project which I’ve been supported for about a year, I prepared a UX design memo documentation for hand over.

Though the hand-over period would last about 2 months and I would have enough time to orally tell the designer in charge of taking over with details listed below

• what is the project background
• who are the stakeholders and how we communicate them
• what we have done in the past
• what is our design process
• how we collaborate with other members (e.g. Business Analyst and Engineers) in the delivery team
• what design tools we use and what are deliverables
• how we organise design deliverables
• what are references resources from the client side
• any tips and items require out attention during work
• etc.

I am afraid the information would be fragmented that neither I could remember to tell everything nor she would be able to catch up.

Hence, I wrapped up everything I could think of by answering above listed questions into a “UX Design Memo” before the new designer joined. It would be more convenient if the organisation supports Google Docs or similar collaboration tools for easier sharing. So that on the new joiner orientation session, I was able to share the doc with the new designer and go through items one by one.

Thus, I don’t need to be afraid of I missed anything when walking through the project and the new joiner would be able to take time digest the information by referring to the memo.

The UX Design memo is more than for design hand over, it is also a useful reference for any member in the team to find information about UX designer’s work.

Example of a UX Design Memo:

— BEGIN —

[Project Name] - UX Design Memo

Working notes and references resources

Timeline

• DD/MM/YYYY - DD/MM/YYYY: Phase One XXXXX
• DD/MM/YYYY - DD/MM/YYYY: Phase Two XXXXX

Phase I (DD/MM/YYYY - DD/MM/YYYY)

[list out job responsibilities for Phase I]

• Plan and facilitate workshops to understand business problems and client’s expectations
• Align with stakeholders on the project goals and schedule
• Review existing work and product

• Conduct stakeholder interviews, under product vision and constraints
• Conduct user interviews and observation to understand user needs and behaviour
• Create persona and empathise on pain points, craft AS-IS User Journey
• Run workshop to prioritise pain points and propose To-be User Journey with initiated solution
• Create wireframe and concept prototype and mockups target solving the key problems
• Collaborate with delivery team to estimate efforts and create delivery plan

References

[list relevant documents for references]

• Reference doc name

Phase II (DD/MM/YYYY - DD/MM/YYYY)

[list out job responsibilities for Phase II]

• Participate in requirement sessions, collaborate with Product Manager to define requirements
• Design framework to fulfil requirements including manifestations of information and functionality, overall structure of user experience, key path and validation scenarios, etc.
• Create UI mockup and interactive prototype
• Refine and specify design details
• Run usability testing to validate design and conduct design modification as feedback
• Test implemented design and make sure delivery quality

References

[list relevant documents for references]

• Reference doc name

Stakeholder

[A summary or list of stakeholder names and role. Usually, it includes product owner, sponsors, user representatives, etc. ]

UI Design

Style Guidelines

[If the project has a style guidelines, UI library or design system for references, list out hyperlinks of the websites or documents]

• XXX Brand Guideline.pdf
• XXX component UI library
• XXX Design System - annotation here if any

Design Tools

[List design tools and purposes for the project. You can list the source files and notes per tool here]

• Figma - to create static UI Mockup_
• Overflow - to create user flow
• HTML/CSS Prototype - to create interactive and closed to real experience for client communication

Output Delivery

[List out delivery files formats and who and where to send the files to]

UI Review/Testing

[List specific items or details need attention for UI implementation review and test]

Others

[List any other items for memo]

— END —

Hope the above idea helps. And of course it is never enough to note down design process and practices at the ending of a project or only when preparing for the hand over. It is always good to keep a wiki page and keep it up to date so that there is always a complete note for seamless knowledge transfer and to achieve better design collaboration and operation outcome.

Further Learning: DesignOps

The Design Memo practices reminds me of the design term “DesignOps” which is about Design Operations.

As what NNgroup ”DesignOps 101” describes:

Definition: DesignOps refers to the orchestration and optimization of people, processes, and craft in order to amplify design’s value and impact at scale.

The practice of Design Operations focuses on processes and measures that support designers in creating consistent, quality designs.

Similar to DevOps which now has becoming a role in digital project. I believe in the future, the DesignOps concept could be more and more popular as part of Design Management. If you are interested in DesignOps, the NNgroup ”DesignOps 101” could be a good starting point.