등록 및 로그인 기능의 모든 논리를 어떻게 고려합니까?

등록과 로그인은 본질적으로 권한 부여 기능입니다. 사용자가 허가되면 제품의 일부 기능을 사용하거나 제품의 일부를 볼 수 있습니다. 이론적으로 제품의 각 기능이나 내용에는 관리자가 조작할 수 있는 권한 설정, 유료 사용자가 볼 수 있는 권한 설정, 쿠키가 작동할 수 있는 권한 설정 등이 있습니다. 따라서 이러한 기본 기능은 등록이 이렇게 간단한 경우는 거의 없지만, 제품 유형, 장면, 사용자 조작 등 여러 가지 요인에 의해 서로 다른 장면에서 상당히 다양한 기능이 얽혀 있습니다. 직장에서, 나는 종종 이 질문을 사용하여 제품 매니저의 집행 차원의 능력을 조사한다. 그래서 나는 가능한 간단하게 대답할 것이다.

첫째, 제품 유형에 따라 제품에 사용자 등록 로그인이 필요한지 여부, 덮어써야 할 기능 포인트, 사용자에게 제공할 옵션 등이 결정됩니다.

두 번째는 장면입니다. 어떤 기능이 제공되는지 결정합니다.

마지막으로, 기능적인 관점에서 기존의 주류 등록 로그인 방식을 간단히 말해 뇌도 형식으로 표현한다.

첫째, 제품 유형

로그인 기능을 등록해야 합니까?

계산기, 나침반, 녹음기 등과 같은 일부 도구 제품은 필요하지 않을 수 있습니다. 그러나 대부분의 제품은 사용자가 등록하여 사용자 정보를 남길 수 있기를 원합니다.

사용자에게 어떤 선택권을 줍니까?

등록 방식만을 예로 들면, 몇 가지 옵션이 있다: 휴대폰 번호? 사서함? 사용자 이름? (지금은 이 형식이 비교적 적습니까) 아니면 제 3 자 등록입니까? 제 3 자 등록이 사실인가 거짓인가?

이러한 질문에 답하려면 제품 유형의 관점에서 출발해야 하며, 표준 답은 없다.

예를 들어, 휴대 전화 번호로 휴대 전화 앱을 등록하는 것이 많은 사람들의 우선 순위가 될 수 있지만, 일부 비즈니스 도구는 메일을 통해 등록하는 사용자를 추천하는 경향이 있습니다. 왜냐하면 많은 거래 자료와 계약 첨부 파일이 메일을 통해 밑바닥으로 보내야 하기 때문입니다. 많은 사용자가 메일을 보지 못할 수도 있지만, 협력 과정에서 없어서는 안 될 부분일 수 있습니다.

또 다른 예를 들어 설명하자면, 콘텐츠를 제공하는 제품으로서 사용자가 더 널리 퍼뜨리기를 원하기 때문에 먼저 트위터 등록을 추천한다.

등록 방법 외에도 로그인 비밀번호 외에 제스처 비밀번호가 필요한지 여부 등 여러 가지 옵션이 있습니다.

어떤 기능점을 덮어써야 합니까?

제품 형태는 사용자가 제품에 들어가는 문턱을 결정합니다. 이 문턱은 높든 낮든 상당히 신경을 쓴다. 예를 들어 등록할 때 얼마나 많은 정보를 기입해야 합니까? 등록 시 보안 정보를 동시에 보완할 필요가 있습니까? 휴대전화를 등록하면 로그인할 때마다 인증코드로 증명해야 하나요?

예를 들어, 상대적으로 강력한 개인 소셜 제품은 사용자가 비교적 완전한 이미지로 들어가기를 원할 수 있습니다. 그런 다음 등록 자체의 기능 외에도 개인 정보 (아바타, 성별 등) 를 보완할 것을 사용자에게 요청합니다. ) 또는 휴대폰을 등록하지 않은 사용자는 사용 가능한 휴대폰 번호를 바인딩해야 합니다.

순전히 도구적인 네트워크 디스크로서 등록 시 로그인 ID 를 입력하여 로그인 비밀번호를 확인할 수 있습니다.

위의 두 가지 서로 다른 등록 기능은 서로 다른 제품 형태의 결과이다.

둘째, 장면

사용자는 처음 방문하거나 이미 경험이 많은 사용자일 수 있으며, 다른 시나리오에서 등록 로그인 기능이 발생할 수 있습니다. 따라서 등록 로그인 기능을 확인한 후 하나 이상의 등록/로그인 구성 요소를 제공하면 각 모듈이 자체적으로 호출됩니다.

전자 상거래 사이트를 예로 들어 보겠습니다. 현재 일부 전자 상거래 또는 발권 사이트는 등록되지 않은 사용자의 구매를 제공하지만 사용자는 거래 및 주문 정보를 받기 위해 휴대폰 번호나 이메일 주소를 제공해야 합니다. 이것은 사실 매우 낮은 등록 문턱이다.

전자상거래 사이트를 예로 들면, 로그인하지 않으면 카트에 갈 수 있지만 장바구니에 들어가거나 주문 절차를 밟은 후에는 반드시 로그인해야 한다. 이때 사용자의 거래 프로세스를 방해하지 않도록 사용자에게 매우 간단한 로그인 방법을 제공할 수 있습니다. 예를 들어 읽을 수 있는 쿠키 정보를 표시하는 경우 로그인 비밀번호만 입력하면 됩니다.

셋째, 제품 기능

점심 식사 후, 나는 비교적 많이 쓰이는 등록과 로그인 기능을 보여 주는 뇌도를 만들었는데, 드롭다운 보면 볼 수 있다. 하지만 이 뇌지도는 완벽하지 않습니다. 아직 많은 세부 사항이 직접 쓰여지지 않았습니다. >. & lt

또한, 기존의 대답을 보고, 내가 지적하고 싶은 몇 가지 질문이 있다. 많은 응답자들이 등록, 개인 정보 및 보안 조치를 등록 범주로 분류했습니다. 물론, 우리는 종종 특정 작업에서 이러한 기능 모듈이 동시에 나타나는 것을 볼 수 있지만, 제품 관리자는 추상적인 업무를 할 수 있는 능력이 필요합니다. 이 세 가지 점은 서로 다른 업무 범주이다.

같은 장면에서 등록, 개인 정보 및 안전 조치의 관계를 파악하려면 제품 형태와 시나리오를 충분히 고려해야 한다.