UX acceptance criteria (AC)

[syndesis-bot]

@dongniwang	2017-08-22	project management

Need to identify the UX acceptance criteria. Dongni to follow up with Roland & UI team and share a proposal for acceptance criteria on the PM list.

[syndesis-bot]

@dongniwang	2017-08-22

Basic Description:

• Requesting UX Research or UX Design?
• If UX Design,
  • Requesting brand new design?
  • Requesting enhancement based on an existing design? If yes, include information about the existing design.
• What problem does the research or design solve?
• What's the use case? Any specific requirements?
  • What goal user needs to accomplish?
  • Any specific functions?
  • Expected interactions?
• MVP and future iterations?
  • What should MVP version support?
  • Anything nice to have for future iterations?
• Any references?
  • Associated GitHub issues

Verification Conditions:

• Who are the stakeholders?
  • Vet specific use case and requirements
• Design review: Any design review meetings? Or GitHub PR?
• Final design needs to be reviewed and signed off by?
• Final design with design decisions documented, PR merged and posted on UX repo

Examples:
syndesisio/syndesis-project#2

[syndesis-bot]

@dongniwang	2017-08-22

@sjcox-rh @rhuss I put together a template for acceptance criteria, is this what we're looking for?

[amysueg]

https://docs.google.com/presentation/d/1hO_tyKbWyCPXk5CFRz5Ecl3zaE21WTex4i69ME3zfzo/edit#slide=id.g2873998495_0_7

Slide deck contains process phases and steps, and a general approach that is meant to outline the way we work.

@sjcox-rh @dongniwang @seanforyou23 - comments and more details appreciated

[rhuss]

First of all, sorry for the late reply.

I wonder how much we need to formalize this. In my simple view, the acceptance happens when the PR for a UX design has been merged to master.

So what are the criteria for such a merge? One or more stakeholder have to approve the design. The first question for me is, who are those stakeholders. IMO its @kcbabo for the business perspective and one from the @syndesisio/ui-api team and one from @syndesisio/backend for the technical aspects.

Next, there are the criteria @dongniwang listed in #319 (comment) :

Who are the stakeholders?

see above (1 PM, 1 UI, 1 Backend)

Design review: Any design review meetings? Or GitHub PR?

I'd like to keep is async, but with the premise that the PR review is done in a timely manner. We have the same challenge for other PRs and try to tackle them already (with less or more success). The best IMO is still to ping people directly (easy for @kcbabo , for the other negotiate with the feature owner of that feature). A stakeholder can delegate of course, and if this turns out that this is not really practicable and causes too long delays, then we should try synchronous review meetings (but I'm pretty sure that there will action items after an initial meeting, so we need multiple rounds to come to an approval then).

Final design needs to be reviewed and signed off by?

Mering the PR is the act of signing off

Final design with design decisions documented, PR merged and posted on UX repo

That's then the end result.

---

For the "Basic Description" you mentioned, I'm not 100% clear whether this should be used in a kind of template (should be possible with ZenHub I think) or it is more like a reminder what pre-requisites are required for the UX Design to start ? Tbh, not all points are really clear to me, but happy to discuss them.

---

@syndesisio/uxd Is this kind of agile approach sufficient for your process or do we need a more formalized approach (like a sign-off document)?

[deeleman]

Final design with design decisions documented, PR merged and posted on UX repo

We at the UI team had also a discussion about process enhancements and there is a consensus amongst us that we can start works on the UI at an earlier stage, just by leveraging the final wireframes previous to the ultimate UI design. In that sense, once there's an agreement between the main business stakeholders and UXD on the best way forward in regards of user journeys and user interaction, we can begin producing non-styled components and other related services based on such wireframes, no matter the cosmetic varnish that will be applied to the UI later on. Or at least we can define the spec for the data that the UI will have to pull in from the API. This might allow us to prevent waterfalling and sped up the production process.

For the "Basic Description" you mentioned, I'm not 100% clear whether this should be used in a kind of template (should be possible with ZenHub I think) or it is more like a reminder what pre-requisites are required for the UX Design to start ?

GitHub's built-in support for Issue and PR templates might be an excellent way to formalize this too.

[kcbabo]

I agree on async review and the list of stakeholders that @rhuss provided. We should implement a time limit for final review and timeout of review period = auto-approval from people that don't respond.

[amysueg]

@rhuss @deeleman @kcbabo @jimmidyson @aileenc - The UX team updated the deck https://docs.google.com/presentation/d/1hO_tyKbWyCPXk5CFRz5Ecl3zaE21WTex4i69ME3zfzo/edit#slide=id.g2873998495_0_7 with additional details from the discussions contained in this issue.

We added a workflow for managing "implementation reviews" - this process is not well defined and so the deck includes a few questions.

I'll leave this open through the first of the year but by around mid-Jan I'm hoping to mark this "done" and agreed. We can always revisit and fine-tune the process as we continue to learn how to work most efficiently and effectively as a team. Thanks for your thoughts.

[gashcrumb]

Apparently we agree :-)