When first planning a business or service, "Where do I start?" is a problem everyone faces.
Among the various types of planning, web planning is the most common these days, so I'll focus on that.
Web planning requires thorough preparation at each stage.
Market Research and Target Setting#
You need a subject to plan for. It's best to start from a problem or inconvenience you've experienced.
If you can find the scale of people who experience this inconvenience, you can define your target market.
Selecting Core Targets:
- Identify the age group, spending patterns, and interests that will drive revenue to clearly define your target customers
- Target setting determines your UI/UX strategy and design direction, so it's extremely important
Surveys and User Feedback Collection:
- Survey actual or potential customers about feature requirements, improvement suggestions, usage environments, etc.
- Use the collected data to firmly establish the service's direction
Service Decision:
- Based on research results, finalize the core features and concept of the service to be built
Planning Execution -- 'How Do We Build It?'#
Once the service to be built is decided, you need to figure out how to build it.
To determine what it will look like, you need to define its appearance and the behaviors based on that appearance.
Then you can identify what kind of people you'll need.
Defining UX/UI:
- Carefully plan the user experience (UX) and interface (UI) to create an intuitive and convenient usage environment
Personas and User Scenarios:
- Set up specific user personas and write scenarios inferring what actions they'll take
- This process lets you predict and prepare for real use cases in advance
Project Risk Management:
- If the planning direction and detailed execution plan are insufficient from the beginning, the project can go off the rails, so thorough planning from this point is essential
Writing Requirements Documents#
If you're an outsourcing company building a service for a client, you might need these deliverables.
If that's not the case, they might not be necessary. But if it's your first time, it's worth trying, whether for record-keeping or otherwise.
Client and Internal RFP:
- Accurately reflect and document the client's requirements (RFP, Request For Proposal)
Securing Evidence:
- Meticulously record revision history in preparation for potential disputes or changes down the road
Writing Functional Specifications#
Developers need descriptions of features to build them. Skeleton UIs are used to create rough screens with detailed feature descriptions attached.
These days, Figma seems sufficient to handle this part.
Detailed Feature Organization:
- Specify the details of each feature and prepare them as deliverables for outsourcing purposes
Verification and Review:
- Continuous review and verification among team members is needed to ensure features derived from the planning stage align with actual development
Wireframes and IA Structure#
It's great for seeing the flow of steps a user takes to solve a problem using certain features.
Wireframes:
- Visualize screen structure and basic flows before the UI design is fully finalized and share them within and outside the team
- Make it clear that this is a "draft," not "finalized" content, while using it as a tool to aid understanding
Information Architecture (IA):
- Organize features per page, responsible parties, schedules, and actual page counts in Excel or similar tools
- Later convert the IA into a WBS (Work Breakdown Structure) to reflect it in schedule management
A planning document isn't just a document -- it's a communication tool between the team and the client. The service doesn't end once it's built -- it needs to be managed like a development project.
It's good to maintain transparency by keeping thorough version control and revision history. A version control system like Git is needed.
From the early stages, reducing unnecessary revisions and time through smooth review processes between planning, design, and development teams is crucial. If only planners are involved and other teams can't participate, there will likely be lots of minor revisions during the execution phase.
Our greatness lies not so much in being able to remake the world as being able to remake ourselves.
— Mahatma Gandhi