As a freelance Experience Designer, I frequently have to introduce working concepts and frameworks as I go. Put simply, the ground is not always prepared, and so the first thing to do is always to make sure we are all talking about the same problems, the same processes, and the same problems.
Over the years, I have developed a number of Document Templates, diagrams and Frameworks which allow teams to start to speak the same language, and focus efforts on defining what it is we're doing.
Product lifecycle diagrams
In the early stages of any project, we need to look at the entire life cycle from the user's perspective in order to make sure there's no major issues. Rather than jump in and build, we take a look at what kinds of needs users of existing services have, and try and plan for those needs in our own service.
This means breaking down the product's relationship with the user into stages, which are shown in some of the slices of diagrams below.
These types of diagrams are high level, and allow teams to discuss their customers in detail in the initial planning stages. Running these diagrams with loose purchasing scenarios early on in the discussion can avoid all sorts of misunderstandings and mistakes as I work with a team to develop the product.
The user and why we think they want our product
Once we get through the high level stuff, and agree which actions we are targeting in the user, I then start refining the information we have, and diagramming the application itself in order to be sure everyone is on the same page.
Documenting existing applications page by page
In early stages of planning I will also take crucial pages of the service and create a set of use cases for them, in order to ask questions / make rules about how to proceed. The document below was written about an account statement page for an iOS app.
Surveys and feedback forms
While these initial meetings are ongoing, I will also be writing sets of questionnaires for stakeholders and sample users of the service. These are designed to be covered in 20 minute interviews and provide the basis for the initial report on the service, along with documents such as the page treatment above.
Persona templates and matrices
As I gather information about the product, its users, and how the organisation deals with day to day business, I can then start to create personas, and fail scenarios, and all sorts of documents which draw out how the application operates and communicates with its users and the company.
Once all of the personas, use cases and functional matrices are complete, and the team are sure we have a full picture of the product over its first year of operation, then we have the basis of an application map, from which we can start to make wireframes.
