<Project planning/roadmap - Scope features or tools which are to implemented by quarter - done by PO>
<Scope user research; often it will be scoped on the same ticket as the ensuing designs - done by PO & product designer>
Secondary research
Conduct secondary research (comparative analysis, ecosystem mapping), to get an idea of what similar products are out there. This helps us avoid re-inventing the wheel, allows us to improve upon our competitors' offerings, and to offer users something familiar and in-line with their expectations and experience.
Secondary research helps us develop better, and more to-the-point questions for users; this results in more efficient primary research and a better experience for our participants.
Primary research
If it’s a new feature or tool, conduct semi-structured generative interviews [LINK TO MURKB] with users, asking them detailed questions about wha their goals and challenges are in this space. The idea is to get them talking as much as possible, to help us understand as deeply as possible their experience and expectations.
If we’re making improvements to an existing feature or tool, conduct think-aloud usability tests with users in order to understand their current journey using the feature, in order to understand their pains/gains using it, how these are shared across the user group and various personas, to help us decide which adjustments to make to the design. Begin with a basic set of discovery questions [LINK TO MURKB] to give us some context - what their organisation/role is, how often they use the feature, and on what device/browser, for example. Next, have them screen share and use the feature, speaking aloud their impressions and feedback as they go (prompt with questions) [LINK TO MURKB].
Summary, analysis, and recommendations based on user research
The more users who provide the same feedback/requests, the higher the impact of addressing that feedback will be. To help you decide on design recommendations, analyse the user feedback along an impact-effort axis. The higher the impact, and the lower the effort to implement (i.e. “low-hanging fruit”), the better the idea.
<Scope design tickets, if they were not combined with the research tickets - done by PO & product designer>
Low-fidelity designs (wireframes)
In some cases, wireframes can be made to further the discussion with various technical teams, without having to wait for high-fidelity mockups to be made. A variety of tools can be used for this; usually Figma/FigJam, but also Lucidchart, Miro, etc.
High-fidelity designs (mockups)
Figma mockups are made which illustrate the new feature, according to our brand guidelines [LINK], using existing components from the design system’s component library [LINK] wherever possible. If it’s an entirely new feature, it’s good practice to review the visual design with (the) other designer(s); you can also ask them for help in creating new assets which may be required (such as favicons, illustrations, other images, etc.).
Sometimes the mockups need to include prototyped interactions as well, for example to illustrate hover or transition behaviour, etc.
<Move into acceptance - PO will then put into [dev] implementation backlog>
Dev support and design review
Stay available to the developers as they implement the designs, as they will likely have clarifying questions that may need additional designs.
They will also likely assign the implementation ticket to you to review that it looks and works as expected, before they will continue testing & eventually release it.
General
Content
Integrations
Add Comment