ਸਿੱਖੋ ਕਿ ਕਿਵੇਂ ਇੱਕ ਐਪ ਯੋਜਨਾ ਬਣਾਉਣੀ, ਡਿਜ਼ਾਈਨ ਅਤੇ ਤਿਆਰ ਕਰਨੀ ਹੈ ਜੋ ਉਪਭੋਗਤਿਆਂ ਨੂੰ ਫਿਟਨੇਸ ਕਲਾਸਾਂ ਲੱਭਣ, ਸਥਾਨ ਬੁੱਕ ਕਰਨ, ਸ਼ਡਿਊਲ ਟਰੈਕ ਕਰਨ ਅਤੇ ਰੀਮਾਈਂਡਰ ਪ੍ਰਾਪਤ ਕਰਨ ਦੀ ਆਗਿਆ ਦੇਵੇ।

ਸਕ੍ਰੀਨ ਸਕੈਚ ਕਰਨ ਜਾਂ ਟੈਕ ਸਟੈਕ ਚੁਣਨ ਤੋਂ ਪਹਿਲਾਂ, ਇਹ ਦਰੁਸਤ ਕਰੋ ਕਿ ਤੁਸੀਂ ਕਿਹੜੀ ਸਮੱਸਿਆ ਹੱਲ ਕਰ ਰਹੇ ਹੋ। “ਫਿਟਨੇਸ ਕਲਾਸਾਂ ਨੂੰ ਟਰੈਕ ਕਰਨਾ” ਦੋਵੇਂ ਹੀ ਕਿਸੇ ਦੀ ਰਾਤ ਦੀ ਯੋਗਾ ਸੈਸ਼ਨ ਲੱਭਣ ਤੋਂ ਲੈ ਕੇ ਟਰੇਨਰ ਦੀ ਪੇਰੋਲ ਲਈ ਹਾਜ਼ਰੀ ਸਬੂਤ ਤੱਕ ਹੋ ਸਕਦਾ ਹੈ। ਇੱਕ ਸਾਫ਼ ਲਕ਼ਸ਼ ਤੁਹਾਡੀ ਫੀਚਰ ਲਿਸਟ ਨੂੰ ਕੇਂਦਰਿਤ ਰੱਖਦਾ ਹੈ ਅਤੇ ਐਪ ਨੂੰ ਵਰਤਣਾ ਆਸਾਨ ਬਣਾਂਦਾ ਹੈ।
ਅਸਲ-ਦੁਨੀਆ ਦੀਆਂ ਰੁਕਾਵਟਾਂ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ:
ਇੱਕ ਇਕ-ਸਤਰ ਵਾਲਾ ਬਿਆਨ ਲਿਖੋ: “ਮੈਂਬਰਾਂ ਨੂੰ 30 ਸਕਿੰਟ ਤੋਂ ਘੱਟ ਵਿੱਚ ਕਲਾਸਾਂ ਲੱਭਣ ਅਤੇ ਬੁੱਕ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰੋ, ਅਤੇ ਸਮੇਂ-ਸਿਰ ਰੀਮਾਈਂਡਰ ਨਾਲ no-shows ਘਟਾਓ।”
ਵਰਜ਼ਨ 1 ਲਈ ਇੱਕ “ਮੁੱਖ” ਯੂਜ਼ਰ ਚੁਣੋ, ਅਤੇ ਹੋਰਾਂ ਨੂੰ ਜ਼ਰੂਰਤ ਮੁਤਾਬਕ ਸਹਾਰਤ ਕਰੋ:
ਜੇ ਤੁਸੀਂ ਤਿੰਨੋ ਨੂੰ ਨਿਸ਼ਾਨਾ ਬਣਾਉਂਦੇ ਹੋ, ਤਾਂ ਫੈਸਲਾ ਕਰੋ ਕਿ ਕੌਣਦੀ ਵਰਕਫਲੋ ਐਪ ਦੀ ਨੈਵੀਗੇਸ਼ਨ ਅਤੇ ਟਰਮੀਨੋਲੋਜੀ ਚਲਾਉਂਦੀ ਹੈ।
ਟਰੈਕਿੰਗ ਵਿੱਚ ਸ਼ਾਮਲ ਹੋ ਸਕਦਾ ਹੈ:
ਕੁਝ ਮਾਪਯੋਗ ਨਤੀਜੇ ਚੁਣੋ:
ਇਹ ਫੈਸਲੇ ਹਰ ਅੱਗੇ ਆਉਣ ਵਾਲੇ ਭਾਗ ਨੂੰ ਗਾਈਡ ਕਰਨਗੇ — ਓਨਬੋਰਡਿੰਗ ਤੋਂ ਨੋਟੀਫਿਕੇਸ਼ਨ ਤੱਕ — ਬਿਨਾਂ ਤੁਹਾਡੇ MVP ਨੂੰ ਫੁਲਾ-ਪੁਲਾ ਕਰਨ ਦੇ।
ਸਭ ਤੋਂ ਤੇਜ਼ੀ ਨਾਲ ਸਮਾਂ (ਅਤੇ ਬਜਟ) ਗੁਆਉਣ ਦਾ ਤਰੀਕਾ ਹੈ ਸਾਰੇ-ਕੁਝ ਬਣਾਉਣਾ ਪਹਿਲਾਂ, ਬਿਨ੍ਹਾਂ ਇਹ ਪ੍ਰਮਾਣਿਤ ਕੀਤੇ ਕਿ ਮੂਲ ਕੰਮ ਚਲਦਾ ਹੈ: ਕੀ ਲੋਕ ਕਲਾਸ ਲੱਭ ਸਕਦੇ ਹਨ, ਸਥਾਨ ਰੱਖ ਸਕਦੇ ਹਨ, ਅਤੇ ਵਾਸਤਵਿਕta ਪਹੁੰਚਦੇ ਹਨ?
ਦੋ ਗਰੂਪਾਂ ਲਈ ਸਫਲਤਾ ਕਿਵੇਂ ਲੱਗਦੀ, ਇਹ ਲਿਖੋ: ਮੈਂਬਰ ਅਤੇ ਸਟਾਫ.
ਮੁੱਖ ਮੈਂਬਰ ਕਹਾਣੀਆਂ (MVP):
ਮੁੱਖ ਐਡਮਿਨ/ਸਟੂਡੀਓ ਕਹਾਣੀਆਂ (MVP):
ਇੱਕ ਪ੍ਰਯੋਗਯੋਗ MVP ਹੈ:
ਜੇ ਕੋਈ ਫੀਚਰ ਉਹਨਾਂ ਫਲੋਜ਼ ਨੂੰ ਸਹਾਇਕ ਨਹੀਂ ਕਰਦਾ, ਤਾਂ ਵਧੇਰੇ ਸੰਭਾਵਨਾ ਹੈ ਕਿ ਉਹ MVP ਨਹੀਂ ਹੈ।
ਇਹ ਕੀਮਤੀ ਹੋ ਸਕਦੇ ਹਨ, ਪਰ ਜ਼ਿਆਦਾ ਜਟਿਲਤਾ ਅਤੇ ਐਡਜ ਕੇਸ ਲਿਆਉਂਦੇ ਹਨ। ਬੈਕਲੌਗ ਵਿੱਚ ਰੱਖੋ ਅਤੇ ਅਸਲੀ ਵਰਤੋਂ ਦੇ ਡੇਟਾ ਦੇ ਬਾਅਦ ਤਰਜੀਹ ਦਿਓ:
ਸਾਦਾ ਨਿਯਮ: ਸਭ ਤੋਂ ਛੋਟਾ ਸੈੱਟ ਜਾਰੀ ਕਰੋ ਜੋ ਇੱਕ ਸਟੂਡੀਓ ਦਾ ਹਫ਼ਤਾ ਏਂਡ-ਟੂ-ਏਂਡ ਚਲਾ ਸਕੇ, ਫਿਰ ਯੂਜ਼ਰ ਫੀਡਬੈਕ ਦੇ ਆਧਾਰ 'ਤੇ Phase 2 ਫੀਚਰ ਹਰਜਾਈ ਕਰਨ।
ਸਕ੍ਰੀਨ ਡਿਜ਼ਾਈਨ ਜਾਂ ਕੋਡ ਲਿਖਣ ਤੋਂ ਪਹਿਲਾਂ, ਉਸ ਡੇਟਾ ਨੂੰ ਨਕਸ਼ਾ ਬਣਾਓ ਜੋ ਤੁਹਾਡੀ ਐਪ ਨੂੰ ਸੰਭਾਲਨਾ ਹੈ। ਇਹ ਪਹਿਲਾਂ ਠੀਕ ਕਰਨ ਨਾਲ “ਖਾਸ ਕੇਸ” ਆਗੇ ਚੱਲ ਕੇ ਫੈਲਣ ਤੋਂ ਰੋਕਦੇ ਹਨ—ਖਾਸ ਕਰਕੇ ਰਿਕਰਿੰਗ ਸ਼ਡਿਊਲ, ਵੈਟਲਿਸਟ ਅਤੇ ਨੀਤੀਆਂ ਨਾਲ।
ਚਾਰ ਬਕੇਟ ਸੋਚੋ: Classes, Schedules, Bookings, ਅਤੇ Users.
ਇੱਕ Class ਉਹ ਟੈਮਪਲੇਟ ਹੈ ਜੋ ਲੋਕ ਲੱਭਦੇ ਅਤੇ ਬੁੱਕ ਕਰਦੇ ਹਨ:
ਹੈਲਪਫੁਲ ਸੋਚ: ਇੱਕ Class ਇੱਕ ਹੀ ਸੈਸ਼ਨ ਨਹੀਂ ਹੈ (ਜੋ ਕਿ ਮੰਗਲ 7pm 'ਤੇ ਹੁੰਦਾ ਹੈ)—ਉਹ ਇੱਕ ਟੈਮਪਲੇਟ ਹੈ।
ਤੁਹਾਡੇ ਸ਼ਡਿਊਲ ਨੂੰ ਸਮਰਥਨ ਦੀ ਲੋੜ ਹੈ:
ਜੇ ਤੁਸੀਂ ਅਗੇੰਤਰ ਅੰਤਰਰਾਸ਼ਟਰੀ ਵਧੋਗੇ, ਤਾਂ ਟਾਈਮਜ਼ੋਨ ਵਿਕਲਪ ਲਾਜ਼ਮੀ ਹਨ। ਇੱਥੇ ਤੱਕ ਕਿ ਲੋਕ ਸਥਾਨਕ ਤੌਰ 'ਤੇ ਯਾਤਰਾ ਕਰਦੇ ਸਮੇਂ ਵੀ ਇਹ ਸਹਾਇਕ ਹੁੰਦਾ ਹੈ।
ਬੁਕਿੰਗ ਸਟੂਡੀਓ ਦੀ ਨੀਤੀ ਨੂੰ ਦਰਸਾਉਣੀ ਚਾਹੀਦੀ ਹੈ, ਅਨੁਮਾਨ ਨਹੀਂ:
ਇਹ ਨੀਯਮ ਪਹਿਲਾਂ ਸਧਾਰਨ ਭਾਸ਼ਾ ਵਿੱਚ ਦਸਤਾਵੇਜ਼ ਕਰੋ, ਫਿਰ ਕੋਡ ਵਿੱਚ ਐਨਕੋਡ ਕਰੋ।
ਯੂਜ਼ਰ ਰਿਕਾਰਡ ਆਮ ਤੌਰ 'ਤੇ ਸ਼ਾਮਲ ਹੁੰਦੇ ਹਨ: ਪ੍ਰੋਫ਼ਾਈਲ, ਪਸੰਦਾਂ (ਪਸੰਦੀਦਾ ਕਲਾਸ ਟਾਈਪ, ਨੋਟੀਫਿਕੇਸ਼ਨ ਸੈਟਿੰਗ), ਕਨਸੈਂਟ (ਟੈਰਮਜ਼/ਪ੍ਰਾਈਵੇਸੀ, ਮਾਰਕੇਟਿੰਗ opt-in), ਅਤੇ ਕਲਾਸ ਇਤਿਹਾਸ.
ਇਤਿਹਾਸ ਨੂੰ ਘੱਟ ਰੱਖੋ: ਸਿਰਫ਼ ਹਾਜ਼ਰੀ, ਰਸੀਦਾਂ ਅਤੇ ਤਰੱਕੀ ਲਈ ਜ਼ਰੂਰੀ ਦਾਖਲੇ ਰੱਖੋ—ਹੋਰ ਨਹੀਂ।
ਇੱਕ ਫਿਟਨੇਸ ਕਲਾਸ ਐਪ ਉਸ ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ ਕਿ ਕਿਸ ਤਰ੍ਹਾਂ ਤੇਜ਼ੀ ਨਾਲ ਕੋਈ ਦੋ ਸਵਾਲਾਂ ਦਾ ਜਵਾਬ ਲੱਭ ਸਕਦਾ ਹੈ: “ਮੈਂ ਕੀ ਬੁਕ ਕਰ ਸਕਦਾ/ਸਕਦੀ ਹਾਂ?” ਅਤੇ “ਕੀ ਮੈਂ ਬੁਕ ਕੀਤਾ ਹੈ?” ਤੁਹਾਡੀ UX ਉਨ੍ਹਾਂ ਦਾ ਜਵਾਬ ਕੁਝ ਸਕਿੰਟਾਂ ਵਿੱਚ ਸਪਸ਼ਟ ਕਰ ਦੇਵੇ।
Home ਨੂੰ ਅੱਜ ਦੇ ਮੁੱਖ-ਦਰਸ਼ਨ ਦਿਖਾਉਣੇ ਚਾਹੀਦੇ ਹਨ: ਅਗਲੀ ਬੁੱਕ ਕੀਤੀ ਕਲਾਸ (ਜਾਂ “ਪਹਿਲੀ ਕਲਾਸ ਬੁਕ ਕਰੋ” ਪ੍ਰੈਂਪਟ), ਤੇਜ਼ ਫਿਲਟਰ (ਸਮਾਂ, ਟਾਈਪ, ਟਰੇਨਰ), ਅਤੇ ਖੋਜ ਦਾ ਸਾਫ਼ ਰਾਸਤਾ।
Class list ਤੁਹਾਡੀ ਬ੍ਰਾਉਜ਼ਿੰਗ ਇੰਜਣ ਹੈ। ਸਕੈਨ ਕਰਨ ਯੋਗ ਕਾਰਡ ਵਰਤੋ ਜਿਸ 'ਤੇ ਸ਼ੁਰੂਆਤੀ ਸਮਾਂ, ਅਵਧੀ, ਕਲਾਸ ਟਾਈਪ, ਟਰੇਨਰ, ਸਥਾਨ ਅਤੇ ਉਪਲਬਧ ਸਥਾਨ ਦਿਖਾਏ ਜਾਣ। ਹਲਕੇ ਫਿਲਟਰ ਜੋੜੋ ਜਿਨ੍ਹਾਂ ਨਾਲ ਵਰਤੋਂਕਾਰ ਨੂੰ ਬਲਾਕੀ ਖੋਜ ਫਾਰਮ ਵਿੱਚ ਨਹੀਂ ਫਸਾਉਣਾ ਪਏ।
Class details ਭਰੋਸਾ ਬਣਾਉਂਦੇ ਹਨ: ਵੇਰਵਾ, ਲੈਵਲ, ਲੋੜੀਂਦਾ ਉਪਕਾਰਣ, ਸਹੀ ਸਥਾਨ, ਰੱਦ ਨੀਤੀ ਅਤੇ ਉਪਲਬਧਤਾ ਇੰਡਿਕੇਟਰ। ਮੁੱਖ ਕਾਰਵਾਈ (Book / Join waitlist / Cancel) ਨੂੰ ਵਿਜ਼ੂਅਲੀ ਤੌਰ 'ਤੇ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਬਣਾਓ।
Calendar ਲੋਕਾਂ ਨੂੰ ਯੋਜਨਾ ਬਣਾਉਣ ਵਿੱਚ ਮਦਦ ਕਰਦਾ ਹੈ। ਹਫ਼ਤਾ/ਦਿਨ ਦੇ ਦ੍ਰਿਸ਼ ਦਿਓ ਅਤੇ ਬੁੱਕ ਕੀਤੀਆਂ ਸੈਸ਼ਨਾਂ ਨੂੰ ਹਾਈਲਾਈਟ ਕਰੋ। ਜੇ ਤੁਸੀਂ ਬਾਅਦ ਵਿੱਚ ਕੈਲੰਡਰ ਇੰਟਿਗ੍ਰੇਸ਼ਨ ਸਹਾਇਤ ਕਰਦੇ ਹੋ, ਤਾਂ ਇਨ-ਐਪ ਕੈਲੰਡਰ ਫਿਰ ਵੀ ਖੁਦ-ਮੁਕੱਦਮ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ।
Bookings ਨੂੰ ਸਾਰੇ ਤੋਂ ਪਹਿਲਾਂ ਆਉਣ ਵਾਲੀਆਂ ਬੁਕਿੰਗਸ ਨਾਲ ਸਧਾਰਨ ਰੱਖੋ। ਇੱਥੇ ਰੱਦ ਨੀਤੀਆਂ ਅਤੇ ਚੈੱਕ-ਇਨ ਜਾਣਕਾਰੀ ਸ਼ਾਮਲ ਕਰੋ।
Profile ਖਾਤਾ ਸੈਟਿੰਗ, ਰੀਮਾਈਂਡਰ ਪਸੰਦਾਂ, ਅਤੇ ਕਿਸੇ ਮੈਮਬਰਸ਼ਿਪ/ਕ੍ਰੈਡਿਟ ਦੀ ਜਾਣਕਾਰੀ ਨੂੰ ਕਵਰ ਕਰਦਾ ਹੈ।
ਮਾੜਾ ਲਕਸ਼: ਕਲਾਸ ਚੁਣੋ → ਪੁਸ਼ਟੀ ਕਰੋ → ਰੀਮਾਈਂਡਰ ਸੈਟ ਕਰੋ.
ਖਾਤਾ ਬਣਾਉਣ ਤੋਂ ਪਹਿਲਾਂ ਯੂਜ਼ਰ ਨੂੰ ਖੋਜ ਕਰਨ ਤੋਂ ਨਾ ਰੋਕੋ; ਪੁਸ਼ਟੀ 'ਤੇ ਸਾਈਨ-ਅਪ ਪ੍ਰਾਂਪਟ ਕਰੋ।
ਵੱਡੇ ਟੈਪ ਟਾਰਗਟ, ਪੜ੍ਹਨ ਯੋਗ ਟੈਕਸਟ, ਅਤੇ ਸਪਸ਼ਟ ਕਾਂਟਰਾਸਟ ਵਰਤੋ—ਖਾਸ ਕਰਕੇ ਸਮਾਂ, ਉਪਲਬਧਤਾ ਅਤੇ ਮੁੱਖ ਬਟਨਾਂ ਲਈ।
ਖਾਲੀ ਸਟੇਟਸ ਯੋਜਨਾ ਕਰੋ: ਫਿਲਟਰ ਮੇਲ ਨਹੀਂ ਖਾਂਦੇ, ਭਰਿਆ (ਵੈਟਲਿਸਟ ਨਾਲ), ਅਤੇ ਆਫਲਾਈਨ ਮੋਡ (ਆਖ਼ਰੀ ਸਿੰਕ ਕੀਤੇ ਗਿਆਨ)। ਹਰ ਇੱਕ ਨਾਲ ਇੱਕ ਮਦਦਗਾਰ ਅਗਲਾ ਕਦਮ ਯੋਜਿਤ ਕਰੋ।
ਤੇਰਾਂ ਲਈ, ਐਰਰ ਸੁਨੇਹੇ ਸੁਣਵਾਈ ਕਰੋ ਜੋ ਦੱਸਣ ਕਿ ਕੀ ਹੋਇਆ ਅਤੇ ਅਗਲਾ ਕਦਮ ਕੀ ਹੈ (ਮੁੜ ਕੋਸ਼ਿਸ਼ ਕਰੋ, ਤਾਰੀਖ ਬਦਲੋ, ਸਟੂਡੀਓ ਨਾਲ ਸੰਪਰਕ), ਨ ਕਿ ਤਕਨੀਕੀ ਕੋਡ।
ਫਿਟਨੇਸ ਕਲਾਸ ਸ਼ਡਿਊਲਿੰਗ ਐਪ ਦੀ ਜਿੰਦਗੀ ਇਸ ਗੱਲ 'ਤੇ ਨਿਰਭਰ ਹੈ ਕਿ ਲੋਕ ਕਿੰਨੀ ਤੇਜ਼ੀ ਨਾਲ ਪ੍ਰਵੇਸ਼ ਕਰ ਸਕਦੇ ਹਨ, ਆਪਣਾ ਸਟੂਡੀਓ ਲੱਭ ਸਕਦੇ ਹਨ, ਅਤੇ ਕਲਾਸ ਬੁੱਕ ਕਰ ਸਕਦੇ ਹਨ। ਤੁਹਾਡਾ ਖਾਤਾ ਅਤੇ ਓਨਬੋਰਡਿੰਗ ਫਲੋ “ਤੁਰੰਤ” ਮਹਿਸੂਸ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ, ਪਰ ਉਹ ਉਹ ਸਾਰਚ ਢਾਂਚਾ ਦੇਣ ਜੋ ਬਾਅਦ 'ਚ ਪਰਮਿਸ਼ਨਾਂ, ਸੁਰੱਖਿਆ ਅਤੇ ਸਹਾਇਤਾ ਲਈ ਲੋੜੀਂਦਾ ਹੈ।
ਵੱਖ-ਵੱਖ ਸਾਈਨ-ਇਨ ਵਿਕਲਪ ਪੇਸ਼ ਕਰੋ:
ਅਭਿਆਸਕ ਤਰੀਕਾ: MVP ਲਈ Apple/Google + ਈਮੇਲ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ, ਫਿਰ SMS ਸ਼ਾਮਲ ਕਰੋ ਜੇ ਤੁਹਾਡੇ ਦਰਸ਼ਕ ਦੀ ਉਮੀਦ ਹੋਵੇ।
ਛੋਟੀ ਐਪਸ ਵੀ ਸਾਫ਼ ਭੂਮਿਕਾ ਤੋਂ ਲਾਭ ਉਠਾਉਂਦੇ ਹਨ:
ਪਰਮੀਸ਼ਨਾਂ ਤੰਗ ਰੱਖੋ: ਇਕ ਇੰਸਟਰਕਟਰ ਮਨੇਜਰਿੰਗ ਬਿੱਲਿੰਗ ਨਾ ਦੇਖੇ ਬਿਨਾਂ ਖਾਸ ਅਧਿਕਾਰ ਦੇ।
ਦੋ-ਕਦਮੀ ਰੁਟੀਨ ਲਈ ਕੋਸ਼ਿਸ਼ ਕਰੋ:
ਫਿਰ ਸੈਟਿੰਗਜ਼ ਉਹ ਸਮੇਂ ਪੁੱਛੋ ਜਦੋਂ ਇਹ ਆਵਸ਼ਯਕ ਹੋਵੇ।
ਸਧਾਰਨ ਸੈਟਿੰਗ ਸਕ੍ਰੀਨ ਵਿੱਚ ਸ਼ਾਮਲ ਕਰੋ:
ਇਹ ਫਲੋਜ਼ ਪਹਿਲਾਂ ਯੋਜਿਤ ਕਰੋ:
ਇਹ ਵੇਰਵੇ ਸਹਾਇਤਾ ਟਿਕਟ ਘਟਾਉਂਦੇ ਹਨ ਅਤੇ ਪਹਿਲੇ ਦਿਨ ਤੋਂ ਭਰੋਸਾ ਬਣਾਉਂਦੇ ਹਨ।
ਸਭ ਤੋਂ ਵਧੀਆ ਟੈਕ ਸਟੈਕ ਉਹ ਹੈ ਜੋ ਇਕ ਭਰੋਸੇਮੰਦ ਪਹਿਲੀ ਵਰਜ਼ਨ ਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਲਾਂਚ ਕਰੇ—ਅਤੇ ਬਾਅਦ ਵਿੱਚ ਤੁਹਾਨੂੰ ਬਕਸੇ ਵਿੱਚ ਬੰਦ ਨਾ ਕਰੇ। ਆਪਣੀਆਂ ਚੋਣਾਂ ਨੂੰ ਆਪਣੇ ਲਾਂਚ ਸਕੋਪ ਨਾਲ ਮਿਲਾਓ: ਇੱਕ ਸਟੂਡੀਓ ਵਿਰੁੱਧ ਕਈ, ਇੱਕ ਸ਼ਹਿਰ ਵਿਰੁੱਧ ਦੇਸ਼-ਵਿਆਪੀ, ਅਤੇ ਸਧਾਰਨ ਸ਼ਡਿਊਲਿੰਗ ਵਿਰੁੱਧ ਭੁਗਤਾਨ ਅਤੇ ਮੈਮਬਰਸ਼ਿਪ।
ਜੇ ਤੁਹਾਡਾ ਦਰਸ਼ਕ ਇੱਕ ਪਲੇਟਫਾਰਮ ਵੱਲ ਝੁਕਿਆ ਹੋਇਆ ਹੈ (ਉਦਾਹਰਣ ਲਈ ਇੱਕ ਖੇਤਰ ਵਿੱਚ iPhone), ਇੱਕ ਪਲੇਟਫਾਰਮ 'ਤੇ ਲਾਂਚ ਕਰਨ ਨਾਲ ਲਾਗਤ ਅਤੇ ਸਮਾਂ ਘਟ ਸਕਦੇ ਹਨ। ਪਰ ਇਹ ਸਿਰਫ਼ ਉਸ ਵੇਲੇ ਹੀ ਕਰੋ ਜੇ ਇਹ ਸਪਸ਼ਟ ਰਿਸਕ ਘਟਾਉਂਦਾ ਹੋਵੇ।
ਫਿਟਨੇਸ ਕਲਾਸ ਸ਼ਡਿਊਲਿੰਗ ਐਪ ਲਈ, ਕ੍ਰਾਸ-ਪਲੇਟਫਾਰਮ ਅਕਸਰ ਕਾਫ਼ੀ ਹੁੰਦਾ ਹੈ—ਬਹੁਤ ਸਾਰੀ ਜਟਿਲਤਾ ਸ਼ਡਿਊਲਿੰਗ ਨਿਯਮਾਂ ਅਤੇ ਬੁਕਿੰਗ ਵਿਚ ਹੁੰਦੀ ਹੈ, ਗ੍ਰਾਫਿਕ-ਭਾਰੀ ਫੀਚਰਾਂ ਵਿਚ ਨਹੀਂ।
ਇੱਕ ਸਧਾਰਨ ਜਿਮ ਸ਼ਡਿਊਲ ਐਪ ਨੂੰ ਵੀ “ਸੋর্স ਆਫ਼ ਟਰੂਥ” ਦੀ ਲੋੜ ਹੈ:
ਮੁੱਖ ਬੈਕਐਂਡ ਹਿੱਸੇ:
ਜੇ ਤੁਸੀਂ ਪਹਿਲੇ ਦਿਨ ਭਾਰੀ ਇੰਜੀਨੀਅਰਿੰਗ ਪਾਈਪਲਾਈਨ 'ਤੇ ਬੰਨ੍ਹਣਾ ਨਹੀਂ ਚਾਹੁੰਦੇ, ਤਾਂ ਪ੍ਰੋਟੋਟਾਈਪ ਅਤੇ ਇਟਰੇਟ ਲਈ ਇੱਕ vibe-coding ਪਹੁੰਚ ਮਦਦ ਕਰ ਸਕਦੀ ਹੈ। ਉਦਾਹਰਣ ਲਈ, Koder.ai ਤੁਹਾਨੂੰ ਚੈਟ ਇੰਟਰਫੇਸ ਤੋਂ ਵੈਬ, ਸਰਵਰ ਅਤੇ ਮੋਬਾਈਲ ਐਪ ਬਣਾਉਣ ਦੀ ਆਸਾਨੀ ਦਿੰਦਾ ਹੈ (ਪਲੈਨਿੰਗ ਮੋਡ ਨਾਲ ਫਲੋਜ਼ ਪਰਿਭਾਸ਼ਿਤ ਕਰਨ), ਫਿਰ ਜਦੋਂ ਤੁਸੀਂ ਤਿਆਰ ਹੋਵੋ ਤਾਂ ਸਰੋਤ ਕੋਡ ਐਕਸਪੋਰਟ ਅਤੇ ਡਿਪਲੋਇ ਕਰੋ। ਇਹ MVPs ਲਈ ਖਾਸ ਕਰਕੇ ਉਪਯੋਗੀ ਹੈ ਜਿਨ੍ਹਾਂ ਨੂੰ React ਵੈਬ ਐਡਮਿਨ, Go + PostgreSQL ਬੈਕਐਂਡ, ਅਤੇ Flutter ਮੋਬਾਈਲ ਐਪ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ—ਬਹੁਤ ਸਾਰੇ ਸ਼ਡਿਊਲਿੰਗ ਉਤਪਾਦ ਇਸੀ ਵਿਭाजन ਨਾਲ ਖਤਮ ਹੁੰਦੇ ਹਨ।
ਉਹ ਸਰਵਿਸਜ਼ ਚੁਣੋ ਜੋ ਤੁਸੀਂ ਬਾਅਦ ਵਿੱਚ ਬਦਲ ਸਕਦੇ ਹੋ, ਅਤੇ ਕਸਟਮ ਸਿਸਟਮ (ਭੁਗਤਾਨ ਜਾਂ ਮੈਸੇਜਿੰਗ) ਬਿਨਾਂ ਸਪੇਸ਼ਲ ਫਰਕ ਦੇ ਨਾ ਬਣਾਓ।
ਇਹ ਫਿਟਨੇਸ ਕਲਾਸ ਸ਼ਡਿਊਲਿੰਗ ਐਪ ਦਾ “ਕੋਰ ਲੂਪ” ਹੈ: ਯੂਜ਼ਰ ਇੱਕ ਕਲਾਸ ਲੱਭਦੇ ਹਨ, ਉਪਲਬਧਤਾ ਚੈਕ ਕਰਦੇ ਹਨ, ਬੁੱਕ ਕਰਦੇ ਹਨ, ਅਤੇ ਇੱਕ ਸਪਸ਼ਟ ਸ਼ਡਿਊਲ ਵਿੱਚ ਵੇਖਦੇ ਹਨ। ਲਕਸ਼ ਹੈ ਕਿ ਇਹ ਫਲੋ ਤੇਜ਼ ਅਤੇ ਭਰੋਸੇਯੋਗ ਹੋਵੇ, ਭਾਵੇਂ ਕਲਾਸ ਭਰ ਜਾਵੇ।
ਸਰਲ ਖੋਜ ਤੋਂ ਸ਼ੁਰੂ ਕਰੋ, ਫਿਰ ਉਹ ਫਿਲਟਰ ਜੋ ਲੋਕ ਫੈਸਲੇ ਕਰਨ ਲਈ ਵਰਤਦੇ ਹਨ ਸ਼ਾਮਲ ਕਰੋ:
ਨਤੀਜੇ ਇੱਕ ਨਜ਼ਰ 'ਤੇ ਉਪਯੋਗੀ ਬਣਾਓ: ਸ਼ੁਰੂਆਤੀ ਸਮਾਂ, ਅਵਧੀ, ਸਟੂਡੀਓ, ਇੰਸਟਰਕਟਰ, ਕੀਮਤ/ਕ੍ਰੈਡਿਟ ਅਤੇ ਬਚੇ ਹੋਏ ਸਥਾਨ. ਜੇ ਕਈ ਕਲਾਸ ਇਕ-ਸਹੀ ਲੱਗਦੀਆਂ ਹਨ, ਤਫ਼ਸੀਲ ਦਿਖਾਓ (ਉਦਾਹਰਣ: “ਬਿਗਿਨਰ-ਫ੍ਰੈਂਡਲੀ” ਜਾਂ “ਹੀਟਡ”)।
ਦੋ ਮੁੱਖ ਕੈਲੰਡਰ ਦ੍ਰਿਸ਼ ਦਿਓ: ਲਿਸਟ (ਬ੍ਰਾਉਜ਼ਿੰਗ ਲਈ ਵਧੀਆ) ਅਤੇ ਹਫ਼ਤਾ ਦ੍ਰਿਸ਼ (ਯੋਜਨਾ ਬਣਾਉਣ ਲਈ ਵਧੀਆ)। ਫਿਰ ਇੱਕ ਨਿਰਧਾਰਤ My Schedule ਸਕ੍ਰੀਨ ਜੋ ਆਉਣ ਵਾਲੀਆਂ ਬੁਕਿੰਗਸ ਅਤੇ ਵੈਟਲਿਸਟ ਨੂੰ ਕ੍ਰਮੀਂ ਦਿਖਾਏ।
“My Schedule” ਵਿੱਚ ਤੁਰੰਤ ਕਾਰਵਾਈਆਂ ਸ਼ਾਮਲ ਕਰੋ: ਕੈਂਸਲ (ਨੀਤੀ ਯਾਦ) , ਕੈਲੰਡਰ ਵਿੱਚ ਜੋੜੋ, ਅਤੇ ਦਿਸ਼ਾ-ਨਿਰਦੇਸ਼. ਇਹ ਤੁਹਾਡੇ ਵਰਕਆਊਟ ਟ੍ਰੈਕਰ ਨੂੰ ਰੋਜ਼ਾਨਾ ਅਭਿਆਸ ਬਣਾਉਂਦਾ ਹੈ।
ਸਮਰੱਥਾ ਸੰਭਾਲ ਸਹੀ ਹੋਣੀ ਚਾਹੀਦੀ:
ਯੂਜ਼ਰਾਂ ਨੂੰ ਉਨ੍ਹਾਂ ਦੇ ਡਿਵਾਈਸ ਕੈਲੰਡਰ ਵਿੱਚ ਬੁਕਿੰਗ ਐਕਸਪੋਰਟ ਕਰਨ ਦਿਓ ਪਰ ਸਿਰਫ਼ ਜਦੋਂ ਉਹ ਸਹਿਮਤ ਹੋਣ। ਸਪਸ਼ਟ ਟਾਈਟਲ ਵਰਤੋ (“Spin — Studio North”) ਅਤੇ ਰੱਦਗੀ ਅਪਡੇਟ ਸ਼ਾਮਲ ਕਰੋ ਤਾਂ ਕਿ ਉਨ੍ਹਾਂ ਦਾ ਕੈਲੰਡਰ ਸਹੀ ਰਹੇ।
ਐਸਕੋਪ ਕੰਟਰੋਲ ਰੱਖਣ ਲਈ ਇਹ MVP ਵਜੋਂ ਜਾਰੀ ਕਰੋ ਅਤੇ ਨਿਯਮ ਬਾਅਦ ਵਿੱਚ ਵਧਾਓ।
ਰੀਮਾਈਂਡਰ ਇੱਕ ਤੇਜ਼ ਤਰੀਕੇ ਨਾਲ ਐਪ ਨੂੰ ਮਦਦਗਾਰ ਮਹਿਸੂਸ ਕਰਵਾਉਂਦੇ ਹਨ—ਜਦੋਂ ਯੂਜ਼ਰ ਇਹ ਨਿਰਧਾਰਤ ਕਰ ਸਕਦੇ ਹਨ ਕਿ ਉਹ ਕੀ ਪ੍ਰਾਪਤ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹਨ, ਕਦੋਂ ਅਤੇ ਕਿੰਨੀ ਵਾਰ।
ਰੀਮਾਈਂਡਰ ਲਈ ਪੁਸ਼, ਈਮੇਲ, ਅਤੇ (ਇੱਛਾ ਅਨੁਸਾਰ) SMS ਦੀ ਪੇਸ਼ਕਸ਼ ਕਰੋ, ਪਰ ਕਿਸੇ ਇੱਕ ਚੈਨਲ 'ਤੇ ਸਾਰੇ ਨੂੰ ਮਜਬੂਰ ਨਾ ਕਰੋ। ਕੁਝ ਯੂਜ਼ਰ ਸੁਕੂਨਦਾਇਕ ਪੁਸ਼ ਨੋਟੀਫਿਕੇਸ਼ਨ ਚਾਹੁੰਦੇ ਹਨ; ਹੋਰ ਲੋਕ ਯੋਜਨਾ ਲਈ ਈਮੇਲ 'ਤੇ ਨਿਰਭਰ ਹਨ। SMS ਦੀ ਸੂਚਨਾ ਦਿਓ ਕਿ ਇਹ ਕਿਸੇ ਖ਼ਰਚ ਨਾਲ ਜੁੜ ਸਕਦਾ ਹੈ ਤਾਂ ਸਪਸ਼ਟ ਰਹੋ।
ਓਨਬੋਰਡਿੰਗ ਵਿੱਚ ਪੁੱਛੋ ਅਤੇ ਸੈਟਿੰਗਜ਼ ਵਿੱਚ ਕਦੀ ਵੀ ਬਦਲਣ ਦੀ ਆਗਿਆ ਦਿਓ।
ਯੂਜ਼ਰ ਆਮ ਤੌਰ 'ਤੇ ਕੁਝ ਮੁੱਖ ਨੋਟੀਫਿਕੇਸ਼ਨ ਉਮੀਦ ਕਰਦੇ ਹਨ:
ਜੇ ਤੁਸੀਂ ਵੈਟਲਿਸਟ ਸਹਾਇਤਾ ਦਿੰਦੇ ਹੋ, ਤਾਂ ਇੱਕ ਹੋਰ: “ਤੁਸੀਂ ਪ੍ਰੋਮੋਟ ਹੋ — X ਮਿੰਟਾਂ ਵਿੱਚ ਪੁਸ਼ਟੀ ਕਰੋ।” ਸੁਨੇਹਾ ਛੋਟਾ ਅਤੇ ਕਾਰਵਾਈ-ਕੇਂਦਰਿਤ ਰਹੇ।
ਜੇ ਤੁਹਾਡੇ ਕੋਲ ਲੇਟ-ਕੈਂਸਲ ਫੀਸ ਜਾਂ no-show ਨੀਤੀ ਹੈ, ਤਾਂ ਉਹਨਾਂ ਨੂੰ ਬੁਕਿੰਗ ਸਮੇਂ ਅਤੇ ਰੀਮਾਈਂਡਰ ਵਿੱਚ ਦਰਸ਼ਾਓ (“ਮੁਫ਼ਤ ਰੱਦ 6:00 PM ਤੱਕ”). ਮਕਸਦ ਘੱਟ ਹਾਜ਼ਰੀਆਂ ਹੈ, ਨਾ ਕਿ ਨਾਖੁਸ਼ ਉਪਭੋਗਤਾ ਜੋ ਫ਼ਸੇ ਹੋਏ ਮਹਿਸੂਸ ਕਰਨ।
ਭਰੋਸਾ ਬਣਾਉਣ ਲਈ ਮੁਢਲਾ ਸੁਨੇਹਾ:
ਜੇ ਯੂਜ਼ਰ ਨੰਤਰ ਨਿਯੰਤਰਿਤ ਮਹਿਸੂਸ ਕਰਦੇ ਹਨ, ਤਾਂ ਉਹ ਨੋਟੀਫਿਕੇਸ਼ਨ ਚਾਲੂ ਰੱਖਣਗੇ, ਅਤੇ ਤੁਹਾਡਾ ਵਰਕਆਊਟ ਕਲਾਸ ਟ੍ਰੈਕਰ ਉਨ੍ਹਾਂ ਦੀ ਰੁਟੀਨ ਦਾ ਹਿੱਸਾ ਬਣ ਜਾਵੇਗਾ।
ਹਾਜ਼ਰੀ ਅਤੇ ਇਤਿਹਾਸ ਇਕ ਵਰਕਆਊਟ ਕਲਾਸ ਟ੍ਰੈਕਰ ਨੂੰ ਅਸਲੀ ਬਣਾਉਂਦੇ ਹਨ—ਪਰ ਇਹੀ ਜਗ੍ਹਾ ਹੈ ਜ਼ਿਥੇ ਭਰੋਸਾ ਤੇਜ਼ੀ ਨਾਲ ਖੋਣਾ ਹੋ ਸਕਦਾ ਹੈ। ਸਹੀ, ਸਾਦਾ ਅਤੇ ਯੂਜ਼ਰ ਰੀਝ ਨੂੰ ਧਿਆਨ ਵਿੱਚ ਰੱਖੋ।
ਇੱਕ ਪ੍ਰਧਾਨ ਚੈਕ-ਇਨ ਫਲੋ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ ਅਤੇ ਜਰੂਰੀ ਹੋਣ ਤੇ ਹੋਰ ਜੋੜੋ:
ਅੰਕ-ਸੰਗ੍ਰਹਿਤ ਅਤੇ ਪ੍ਰੋਤਸਾਹਕ:
ਸ਼ੁਰੂ ਵਿੱਚ “ਹੈਲਥ ਕਲੇਮ” ਜਾਂ ਵਿਸਥਾਰਤ ਐਨਾਲਿਟਿਕਸ ਤੋਂ ਬਚੋ। ਇੱਕ ਸਾਫ਼ ਇਤਿਹਾਸ ਵੇਖਣਾ retention ਬਢ਼ਾਉਣ ਵਿੱਚ ਚਾਰਟਾਂ ਤੋਂ ਜ਼ਿਆਦਾ ਯੋਗਦਾਨ ਕਰ ਸਕਦਾ ਹੈ।
ਸਿਰਫ਼ ਉਹੀ ਇਕੱਠਾ ਕਰੋ ਜੋ ਬੁਕਿੰਗ ਅਤੇ ਹਾਜ਼ਰੀ ਲਈ ਜ਼ਰੂਰੀ ਹੈ, ਅਤੇ ਇਸਨੂੰ ਸਪਸ਼ਟ ਭਾਸ਼ਾ ਵਿੱਚ ਵੇਖਾਓ ਜਦੋਂ ਤੁਸੀਂ ਪੁੱਛੋ। ਉਦਾਹਰਣ ਲਈ, ਜੇ ਤੁਸੀਂ ਕਦੇ ਸਥਿਤੀ ਚਾਲੂ ਕਰਦੇ ਹੋ, ਤਾਂ ਸਪਸ਼ਟ ਦੱਸੋ ਕਿ ਇਹ ਕਿਸ ਲਈ ਵਰਤੀ ਜਾ ਰਹੀ ਹੈ ਅਤੇ /settings ਵਿੱਚ ਆਸਾਨ ਆਫ-ਸਵਿੱਚ ਦਿਓ।
ਬੁਨਿਆਦੀ ਵਰਕਫਲੋ ਤਿਆਰ ਰੱਖੋ:
ਸ਼ੁਰੂ ਵਿੱਚ ਇਹ ਸਹਾਇਤਾ ਰਾਹੀਂ ਹੈਂਡਲ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ, ਪਰ ਕਦਮ ਦੋ-ਇਤਬਾਰ ਤੈਅ ਕਰੋ ਤਾਂ ਜੋ ਬਾਅਦ ਵਿੱਚ ਪਨਿਕ ਨਾ ਹੋਵੇ।
ਫਿਟਨੇਸ ਕਲਾਸ ਸ਼ਡਿਊਲਿੰਗ ਐਪ ਆਪਣੀ ਐਡਮਿਨ ਟੂਲਜ਼ ਦੀ ਗੁਣਵੱਤਾ 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ। ਟਰੇਨਰਾਂ ਅਤੇ ਮੈਨੇਜਰਾਂ ਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਅਤੇ ਭਰੋਸੇ ਨਾਲ ਸ਼ਡਿਊਲ ਅਪਡੇਟ ਕਰਨ ਦੀ ਲੋੜ ਹੈ—ਬਿਨਾਂ ਮੈਂਬਰਾਂ ਲਈ ਗਲਤ-ਕੰਫ਼ਲਿਕਟ ਬਣਾਏ।
ਰੋਜ਼ਾਨਾ ਦੇ ਕੰਮਾਂ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ:
ਐਡਮਿਨ UI ਨੂੰ ਕੈਲੰਡਰ-ਜੈਸੀ ਦਿੱਖ ਅਤੇ ਇੱਕ "ਕਲਾਸ ਐਡੀਟਰ" ਪੈਨਲ ਤੇ ਕੇਂਦਰਿਤ ਰੱਖੋ। ਜੇ ਤੁਸੀਂ ਕਈ ਸਟੂਡੀਓਜ਼ ਲਈ ਬਣਾਉਂਦੇ ਹੋ, ਤਾਂ ਸਟੂਡੀਓ ਚੁਣਨ ਵਾਲਾ ਵਿਕਲਪ ਅਤੇ ਭੂਮਿਕਾ-ਆਧਾਰਿਤ ਇੱਕਸੇਸ ਜੋੜੋ (ਮੇਨੇਜਰ ਵਿ. ਟਰੇਨਰ)।
ਸਕੈਜੂਲ ਬਦਲਾਅ ਅਟੱਲ ਹਨ: ਸਮਾਂ-ਸ਼ਿਫਟ, ਰੱਦ, ਕਮਰਾ ਬਦਲਣਾ, ਕੋਚ ਸਬਸੀਟਿਊਸ਼ਨ। ਤੁਹਾਡਾ ਡੈਸ਼ਬੋਰਡ ਪਬਲਿਸ਼ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ “ਕੌਣ ਪ੍ਰਭਾਵਿਤ ਹੋਏਗਾ” ਦਿਖਾਉਣਾ ਚਾਹੀਦਾ ਹੈ।
ਉਪਯੋਗੀ ਸੁਰੱਖਿਆ:
ਵੈਨਿਟੀ ਮੈਟ੍ਰਿਕਸ ਨੂੰ ਛੱਡੋ। ਸ਼ੁਰੂ ਵਿੱਚ:
ਭਾਵੇਂ ਭੁਗਤਾਨ MVP ਦਾ ਹਿੱਸਾ ਨਾ ਹੋਵੇ, ਸਪੋਰਟ ਕਾਰਵਾਈਆਂ ਲਈ ਯੋਜਨਾ ਬਣਾਓ:
ਇਹ ਡੈਸ਼ਬੋਰਡ ਤੁਹਾਡੇ ਜਿਮ ਸ਼ਡਿਊਲ ਐਪ ਦਾ ਆਪਰੇਸ਼ਨਲ ਸੈਂਟਰ ਬਣੇਗਾ—ਇਸਨੂੰ ਤੇਜ਼, ਸਪਸ਼ਟ ਅਤੇ ਦਬਾਅ ਹੇਠ ਕੰਮ ਕਰਨ ਯੋਗ ਬਣਾਓ।
ਇੱਕ ਫਿਟਨੇਸ ਕਲਾਸ ਸ਼ਡਿਊਲਿੰਗ ਐਪ ਨੂੰ ਬਿਨਾਂ ਧਿਆਨਪੂਰਵਕ ਟੈਸਟ ਅਤੇ ਮੈਜ਼ਰ ਕਰਨ ਦੇ ਲਾਂਚ ਕਰਨਾ ਛੋਟੀ-ਛੋਟੀ ਗਡਬਡੀਆਂ ਨੂੰ ਰੋਜ਼ਾਨਾ ਦੇ ਫਰਜ਼ ਬਣਾਉ ਸਕਦਾ—ਮਿਸਡ ਬੁਕਿੰਗ, ਗਲਤ ਸਮੇਂ, ਜਾਂ ਡੂਪਲੀਕੇਟ ਚਾਰਜ। ਇਹ ਹਿੱਸਾ ਉਹ ਪਰਿਕ੍ਰਿਆਵਾਂ ਤੇ ਦਿੱਤੀਆਂ ਜਾਂਦੀਆਂ ਚੋਣਾਂ 'ਤੇ ਕੇਂਦਰਿਤ ਹੈ ਜੋ ਯੂਜ਼ਰ ਅਤੇ ਸਪੋਰਟ ਇਨਬਾਕਸ ਨੂੰ ਰੋਕੇਗਾ।
ਲੋਕ ਸਭ ਤੋਂ ਵੱਧ ਵਰਤਦੇ ਫਲੋਜ਼ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ: ਕਲਾਸ ਬ੍ਰਾਉਜ਼, ਬੁਕ, ਕੈਂਸਲ, ਅਤੇ ਚੈੱਕ-ਇਨ। ਫਿਰ ਓਹਨਾਂ ਮੁਸ਼ਕਿਲ ਹਿੱਸਿਆਂ ਨੂੰ ਸਟ੍ਰੈਸ-ਟੈਸਟ ਕਰੋ:
ਜੋ ਕੁਝ ਤੁਸੀਂ ਆਟੋਮੇਟ ਕਰ ਸਕਦੇ ਹੋ (ਯੂਨਿਟ + ਏਂਡ-ਟੂ-ਏਂਡ ਟੈਸਟ), ਉਹ ਕਰੋ, ਪਰ ਫਿਰ ਵੀ ਹੇਠਲੇ-ਨੈਟਵਰਕ শਰਤਾਂ 'ਤੇ ਰੀਅਲ ਡਿਵਾਈਸ ਮੈਨੂਅਲ ਰਨ ਕਰੋ।
ਕਲਾਸ ਲਿਸਟ ਤੇਜ਼ੀ ਨਾਲ ਲੋਡ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ ਕਿਉਂਕਿ ਯੂਜ਼ਰ ਅਕਸਰ ਰਸਤੇ 'ਤੇ ਸ਼ਡਿਊਲ ਚੈੱਕ ਕਰਦੇ ਹਨ।
ਸੁਰੱਖਿਅਤ ਔਥੇੰਟੀਕੇਸ਼ਨ ਵਰਤੋ (OAuth/SSO ਜੇ ਲਾਜ਼ਮੀ), ਟੋਕਨ ਸਿਰਫ਼ ਸੁਰੱਖਿਅਤ ਸਟੋਰੇਜ ਵਿੱਚ ਰੱਖੋ, ਅਤੇ ਦੁਰੁਪਯੋਗ ਘਟਾਉਣ ਲਈ ਰੇਟ ਲਿਮਿਟਿੰਗ ਲਗਾਓ।
ਐਡਮਿਨ ਕਾਰਵਾਈਆਂ (ਸ਼ਡਿਊਲ ਸੋਧਣਾ, ਐਟੈਂਡੀ ਲਿਸਟ ਐਕਸਪੋਰਟ) ਨੂੰ ਉੱਚ-ਖ਼ਤਰੇ ਵਜੋਂ ਦੇਖੋ: ਜਰੂਰਤ ਪੈਣ 'ਤੇ ਦੁਬਾਰਾ ਪ੍ਰਮਾਣੀਕਰਨ ਮੰਗੋ।
ਸਾਦਾ ਫਨਲ ਟਰੈਕ ਕਰੋ: view class → book → attend. ਡ੍ਰੌਪ-ਆਫ਼ ਪੁਆਇੰਟ (ਉਦਾਹਰਣ: ਬੁਕਿੰਗ ਸਕ੍ਰੀਨ'abandon') ਅਤੇ ਮੁੱਖ ਤ੍ਰੁੱਟੀਆਂ (ਭੁਗਤਾਨ ਫੇਲ, ਕਲਾਸ ਭਰਿਆ) ਜੋੜੋ।
ਡੇਟਾ ਘਟ ਕਰੋ: ਸੰਵੇਦਨਸ਼ੀਲ ਸਿਹਤ ਜਾਣਕਾਰੀ ਸਿਰਫ਼ ਜਦੋਂ ਲਾਜ਼ਮੀ ਹੋ ਇਕੱਠੀ ਕਰੋ।
ਜੇ ਤੁਸੀਂ ਰਿਲੀਜ਼ ਦੀ ਤਿਆਰੀ ਕਰ ਰਹੇ ਹੋ, ਤਾਂ ਇਹ /blog/app-store-launch-checklist ਦੇ ਨਾਲ ਜੋੜੋ ਤਾਂ ਕਿ ਟੈਸਟ ਅਤੇ ਐਨਾਲਿਟਿਕਸ ਦਿਨ-ਇੱਕ ਤੋਂ ਪਹਿਲਾਂ ਤਿਆਰ ਹੋਣ।
ਲਾਂਚ ਦਾ ਮਤਲਬ ਸਿਰਫ਼ “ਐਪ ਸ਼ਿਪ ਕਰਨਾ” ਨਹੀਂ, ਸਗੋਂ ਇਹ ਪਰਖਣਾ ਹੈ ਕਿ ਇਹ ਅਸਲ ਸਟੂਡੀਓਜ਼ ਅਤੇ ਮੈਂਬਰਾਂ ਲਈ ਕੰਮ ਕਰਦਾ ਹੈ—ਫਿਰ ਰਿਵਰਸ ਲੂਪ ਨੂੰ ਤਿੱਖਾ ਕਰੋ।
ਸਟੋਰ ਐਸੈਟ ਪਹਿਲਾਂ ਤਿਆਰ ਕਰੋ ਤਾਂ ਜੋ ਜਿਵੇਂ ਹੀ ਰਿਲੀਜ਼ ਉਮੀਦ ਵਾਲੀ ਬਿਲਡ ਸਥਿਰ ਹੋਵੇ ਤੁਸੀਂ ਸੁਬਮਿਟ ਕਰ ਸਕੋ:
ਸਮੀਖਿਆ ਦੇ ਦੇਰੀ ਅਤੇ ਸੰਭਾਵੀ ਰੱਦੀਆਂ ਲਈ ਸਮਾਂ ਰੱਖੋ (ਅਕਸਰ ਗਲਤ ਪ੍ਰਾਈਵੇਸੀ ਟੈਕਸਟ, ਗੁਪਤ ਸਬਸਕ੍ਰਿਪਸ਼ਨ ਸ਼ਬਦਾਵਲੀ, ਜਾਂ ਅਣਚਾਹੀ ਨੋਟੀਫਿਕੇਸ਼ਨ ਇਜਾਜ਼ਤ ਕਾਰਨ ਹੁੰਦੀ ਹਨ)।
ਕੁਝ ਸਟੂਡੀਓਜ਼ ਅਤੇ ਕੁਝ ਦਸਾਂ-ਦਹਾਂ ਸਰਗਰਮ ਯੂਜ਼ਰਾਂ ਨਾਲ ਬੀਟਾ ਚਲਾਓ। ਧਿਆਨ ਦਿਓ:
ਹਫ਼ਤਾਵਾਰ ਛੋਟੀ ਇਟਰੇਸ਼ਨ ਭੇਜੋ। ਇੱਕ ਸੰਕੁਚਿਤ ਬੀਟਾ ਜਨਰਲ ਲਾਂਚ ਨਾਲੋਂ ਬਿਹਤਰ ਹੈ।
ਇੱਕ ਸਪੋਰਟ ਈਮੇਲ, ਹਲਕਾ FAQ, ਅਤੇ ਜਾਣੇ-ਪਛਾਣ ਦੇ ਸਮੱਸਿਆਵਾਂ ਲਈ ਇੱਕ ਸਧਾਰਨ ਸਥਿਤੀ ਸਫ਼ਾ ਜਾਂ /help ਪੇਜ ਤਿਆਰ ਕਰੋ। ਬੱਗ ਟ੍ਰਾਇਅਜ ਨਿਯਮ ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ (ਕਿਹੜਾ 24 ਘੰਟਿਆਂ ਵਿੱਚ ਠੀਕ ਹੋਏਗਾ ਵਿ. ਅਗਲੇ ਸਪ੍ਰਿੰਟ) ਅਤੇ ਰਿਪੋਰਟਾਂ ਨੂੰ ਡਿਵਾਈਸ, OS ਵਰਜ਼ਨ ਅਤੇ ਸਟੂਡੀਓ ਮੁਤਾਬਕ ਟ੍ਰੈਕ ਕਰੋ।
ਉਨ੍ਹਾਂ ਸੁਧਾਰਾਂ ਨੂੰ ਤਰਜੀਹ ਦਿਓ ਜੋ ਰਿਟੇੰਸ਼ਨ ਨੂੰ ਗਹਿਰਾ ਕਰਦੇ ਹਨ: ਮੈਮਬਰਸ਼ਿਪ/ਭੁਗਤਾਨ, ਸਟੂਡੀਓ ਸਿਸਟਮਾਂ ਨਾਲ ਇੰਟਿਗ੍ਰੇਸ਼ਨ, ਰੈਫਰਲ, ਅਤੇ ਹਲਕੀਆਂ ਚੈਲੇਂਜ।
ਇਹ ਸਭ ਉਨ੍ਹਾਂ ਤੋਂ ਬਾਅਦ ਹੀ ਜੋੜੋ ਜਦੋਂ ਤੁਹਾਡਾ ਕੋਰ ਸ਼ਡਿਊਲਿੰਗ ਅਤੇ ਬੁਕਿੰਗ ਫਲੋ ਤੇਜ਼, ਭਰੋਸੇਯੋਗ ਅਤੇ ਸਹੀ ਹੋਵੇ।
ਪਹਿਲਾਂ ਇੱਕ ਇੱਕ-ਸਤਰ ਵਾਲਾ ਲਕ਼ਸ਼ ਬਨਾਓ ਜੋ ਯੂਜ਼ਰ, ਕੰਮ ਅਤੇ ਨਤੀਜੇ ਨੂੰ ਨਾਂਵੇ (ਉਦਾਹਰਣ: “ਸਦੇ ਮੈਂਬਰਾਂ ਨੂੰ 30 ਸਕਿੰਟ ਤੋਂ ਘੱਟ ਸਮੇਂ ਵਿੱਚ ਕਲਾਸ ਲੱਭਣ ਅਤੇ ਬੁੱਕ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰਨੀ ਅਤੇ ਸਮੇਂ-ਸਿਰ ਰੀਮਾਈਂਡਰ ਨਾਲ no-shows ਘਟਾਉਣ”).
ਫਿਰ ਉਹ ਅਸਲ ਰੁਕਾਵਟਾਂ ਲਿਖੋ ਜੋ ਤੁਸੀਂ ਹਟਾ ਰਹੇ ਹੋ: ਕਲਾਸਾਂ ਲੱਭਣਾ, ਬੁਕਿੰਗ, ਰੀਮਾਈਂਡਰ ਅਤੇ ਹਾਜ਼ਰੀ/ਇਤਿਹਾਸ.
ਇੱਕ ਟਿੱਪ: ਇੱਕ ਸਖ਼ਤ ਲਕ਼ਸ਼ MVP ਦੇ ਘੱਟ-ਫੀਚਰ ਸਕੋਪ ਅਤੇ ਇੱਕਸਾਰ ਟਰਮੀਨੋਲੋਜੀ ਨੂੰ ਯਕੀਨੀ ਬਣਾਉਂਦਾ ਹੈ।
v1 ਲਈ ਇੱਕ ਮੁੱਖ ਦਰਸ਼ਕ ਚੁਣੋ ਅਤੇ ਉਨ੍ਹਾਂ ਦੇ ਵਰਕਫਲੋ ਨੂੰ UI ਚਲਾਉਣ ਦਿਓ.
ਉਨ੍ਹਾਂ ਹੋਰ ਭੂਮਿਕਾਂ ਨੂੰ ਸਹਾਰਾ ਦੇ ਸਕਦੇ ਹੋ, ਪਰ ਪਹਿਲੇ ਦਿਨ ਤਿੰਨ ਵੱਖ-ਵੱਖ ਮਨੋਭਾਵਾਂ 'ਤੇ ਪੂਰਾ ਐਪ ਡਿਜ਼ਾਈਨ ਕਰਨ ਤੋਂ ਬਚੋ।
ਆਮ ਤੌਰ 'ਤੇ MVP ਦਾ ਅਰਥ ਹੈ ਕਿ ਤੁਸੀਂ ਇੱਕ ਸਟੂਡੀਓ ਹਫ਼ਤਾ ਆਖਰ-ਤੱਕ ਚਲਾ ਸਕਦੇ ਹੋ:
ਜੇ ਕੋਈ ਫੀਚਰ ਸਿੱਧਾ ਇਹਨਾਂ ਫਲੋਜ਼ ਨੂੰ ਸਹਾਇਕ ਨਹੀਂ ਹੈ (ਜਿਵੇਂ ਚੈਟ, ਗੈਮੀਫਿਕੇਸ਼ਨ, ਰੈਫਰਲ), ਤਾਂ ਉਸ ਨੂੰ ਫੇਜ਼ 2 ਵਿਚ ਰੱਖੋ।
“ਕਲਾਸ ਟੈਮਪਲੇਟ” ਅਤੇ “ਸ਼ਡਿਊਲ ਹੋਈ ਸੈਸ਼ਨ” ਵਿਚਲਾ ਫਰਕ ਮਾਡਲ ਕਰੋ। ਇੱਕ ਕਲਾਸ (ਉਦਾਹਰਣ: “ਮਾਰਨਿੰਗ ਯੋਗਾ”) ਪ੍ਰਦਾਵਾ ਹੈ; ਸੈਸ਼ਨ ਉਹ ਘਟਨਾ ਹੈ (ਮੰਗਲ 7pm ਆਦਿ).
ਘੱਟੋ-ਘੱਟ ਮਾਪ-ਰੂਪ:
ਇਸ ਤਰੀਕੇ ਨਾਲ ਰਿਕਰਿੰਗ ਸ਼ਡਿਊਲ ਅਤੇ ਬਦਲਾਅ ਦੇ ਨਾਲ ਖਾਸ ਕੇਸ ਫੈਲਣ ਤੋਂ ਰੁਕਾਵਟ ਹੁੰਦੀ ਹੈ।
ਹਰ ਸਥਾਨ ਲਈ canonical ਟਾਈਮਜ਼ੋਨ ਸਟੋਰ ਕਰੋ ਅਤੇ ਹਮੇਸ਼ਾਂ ਯੂਜ਼ਰ ਦੇ ਮੌਜੂਦਾ ਟਾਈਮਜ਼ੋਨ ਲਈ ਡਿਸਪਲੇਅ ਸਮਾਂ ਕਨਵਰਟ ਕਰੋ.
ਸਪੋਰਟ ਕਰੋ:
“ਕਲਾਕ-ਚੇਂਜ ਹਫ਼ਤਿਆਂ” ਅਤੇ ਯਾਤਰਾ ਸਨੈਰਿਓਜ਼ ਦੀ ਟੈਸਟਿੰਗ ਕਰੋ ਤਾਂ ਜੋ ਗਲਤ ਸ਼ੁਰੂਆਤੀ ਸਮਿਆਂ ਤੋਂ ਬਚ ਸਕੋ।
ਸਧਾਰਣ ਫਲੋ ਬਣਾਓ: ਚੁਣੋ ਕਲਾਸ → ਪੁਸ਼ਟੀ ਕਰੋ → ਰੀਮਾਈਂਡਰ ਸੈਟ ਕਰੋ (ਇੱਛਾ ਅਨੁਸਾਰ).
ਖੋਜ ਕੀਤੇ ਬਿਨਾਂ ਯੂਜ਼ਰ ਨੂੰ ਖਾਤਾ ਬਣਾਉਣ 'ਤੇ ਮਜ਼ਬੂਰ ਨਾ ਕਰੋ; ਰਿਕਾਰਡਾਤਮਕ ਤੌਰ 'ਤੇ ਸਮਾਂ ਤੇ ਪੁਸ਼ਟੀ ਤੇ ਸਾਈਨ-ਅਪ ਮੰਗੋ.
“ਕਲਾਸ ਡੀਟੇਲਸ” ਵਿੱਚ ਆਪਣੇ ਉਪਭੋਗਤਾ ਦਾ ਭਰੋਸਾ ਬਣਾਉਣ ਵਾਲੇ ਅੰਸ਼ ਸ਼ਾਮਲ ਹੋਣ: ਸਥਾਨ, ਸਤਰ, ਜਰੂਰੀ ਸਾਜ-ਸਮਾਨ, ਰੱਦ ਨੀਤੀ, ਅਤੇ ਪ੍ਰਮੁੱਖ ਕਾਰਵਾਈ (Book / Join waitlist / Cancel) ਨੂੰ ਦਿੱਖ ਵਿੱਚ ਉੱਪਰ ਰੱਖੋ।
ਸਮਰੱਥਾ ਨੂੰ ਇੱਕ ਟ੍ਰਾਂਜ਼ੈਕਸ਼ਨ-ਸੁਰੱਖਿਅਤ ਸਿਸਟਮ ਬਣਾਓ:
ਅਤੇ ਕੈਂਸਲੇਸ਼ਨ ਵਿੰਡੋ ਅਤੇ ਕਟਆਫ਼ ਸਮਾਂ ਸਪਸ਼ਟ ਰੱਖੋ ਤਾਂ ਯੂਜ਼ਰ ਸਮਝ ਸਕਣ ਕਿ ਦੇਰੀ ਨਾਲ ਕੈਂਸਲ ਕਰਨ 'ਤੇ ਕੀ ਹੁੰਦਾ ਹੈ।
ਉਪਭੋਗਤਾਵਾਂ ਨੂੰ ਚੈਨਲ ਚੁਣਨ ਦੀ ਆਜ਼ਾਦੀ ਦਿਓ: ਪੁਸ਼, ਈਮੇਲ, ਅਤੇ (ਚਾਹੇ ਤਾਂ) SMS, ਪਰ ਕਿਸੇ ਇੱਕ ਤਰੀਕੇ ਨੂੰ ਹਰ ਕਿਸੇ 'ਤੇ ਜਬਰ ਨਾ ਕਰੋ.
ਰੀਮਾਈਂਡਰ ਜੋ ਲੋਕ ਅਕਸਰ ਉਮੀਦ ਕਰਦੇ ਹਨ:
ਵੈਟਲਿਸਟ ਹੋਣ 'ਤੇ: “ਤੁਸੀਂ in—confirm within X minutes.” ਵਰਗੀ ਸੰਦੇਸ਼ ਸਾਫ਼ ਅਤੇ ਕਾਰਵਾਈ-ਕੇਂਦਰਿਤ ਰੱਖੋ.
ਸ਼ਾਂਤੀ ਨੀਤੀ: ਕਵਾਇਅਟ ਘੰਟਿਆਂ ਅਤੇ ਟਾਈਮਜ਼ੋਨ ਦਾ ਆਦਰ ਕਰੋ; opt-out ਆਸਾਨ ਰੱਖੋ।
ਇੱਕ ਭਰੋਸੇਮੰਦ ਚੈੱਕ-ਇਨ ਫਲੋ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ:
ਇਤਿਹਾਸ ਸੰਖੇਪ ਅਤੇ ਮੋਟੀਵੇਟਿੰਗ ਲਈ:
ਉੱਚ-ਖ਼ਤਰੇ ਵਾਲੇ ਸੈਨੇਰਿਓਜ਼ ਨੂੰ ਪਹਿਲਾਂ ਕਵਰ ਕਰੋ:
ਸੁਰੱਖਿਆ ਮੁਢਲੀ ਸ਼ਰਤਾਂ: ਸੁਰੱਖਿਅਤ ਔਥੇੰਟੀਕੇਸ਼ਨ, ਟੋਕਨ ਸੁਰੱਖਿਆ, ਰੇਟ-ਲਿਮਿਟਿੰਗ, ਅਤੇ ਐਡਮਿਨ ਕਾਰਵਾਈਆਂ ਲਈ ਵਧੇਰੇ ਪ੍ਰੋਟੇਕਸ਼ਨ (ਜਿਵੇਂ re-auth)।
ਬੇਸਿਕ ఫనਲ ਮੈਟਰਿਕ: view class → book → attend; ਵੱਡੀਆਂ ਡ੍ਰੌਪ-ਆਫ਼ ਪੁਆਇੰਟਾਂ ਨੂੰ ਠੀਕ ਕਰੋ।
ਪਹਿਲੇ ਦਿਨੋਂ ਹੀ ਪ੍ਰਾਈਵੇਸੀ-ਬਾਈ-ਡਿਜ਼ਾਈਨ ਫਰਮੇਵਰਕ ਰੱਖੋ: ਸਿਰਫ਼ ਲੋੜੀਦਾ ਡੇਟਾ ਇਕੱਠਾ ਕਰੋ ਅਤੇ ਵਰਣਨ ਸਪਸ਼ਟ ਰੱਖੋ।