Screen maps, Sitemaps, Contentograms, … Usage and User Flow Diagrams

on
Mapping out of dependencies, screens, site’s content and pages, features, functions, components and finally backend and code is one of the most helpful deliverables in UX and digital design. Listing, Visualizing and Mapping these things is useful far beyond the design process and makes for a valuable asset throughout the planning, development, and maintaining.
 


Such maps and diagrams can shows the structure of a website or an app together with interactions between content modules - similar to a flowchart. Because of its simplicity, it helps uncover problems that would drown in more complex visualizations. But this is one of the most important points at the beginning and while you work´, share, and communicate your map the level of details you want, must and can show.


I see 4 primary models.
1st Level - The system context – such a model, map and diagram can provide a starting point, showing how the app, service in scope fits into the ‘world’ around it. The world are users, stakeholders, other systems, and technical backbone.

2nd Level - Screens and containers – These maps showing screens and container show the high-level interfaces, building blocks and the structure on a high-level.

3rd Level – Component, Feature, Functions – such a map zooms into an individual screen or container, showing the components, feature, functions, interactions – most often they will be ‘just’ a wireframe but as map they can explain self-contained and small interaction relationships.

4th Level – Backend and Code – Such a map can be used to zoom into an individual component, showing how that component is implemented.


Why it’s useful
The best design work happens within constraints - It’s not an obstacle to a successful project although it doesn’t or all too often it doesn’t always feel that way. Or may I say that I often have the impression that it is quite the opposite, constraints are what makes good design good, unique and positively surprising.

These kind of mapping are a way to create constraints in the design process to discover gaps in experience and expectation of users, needs, business, social and financial or even technology constraints - and we from user experience, information architecture, interaction design, developer and project leaders can discover and work on it in an early stage.


How it works
Each of these maps (Screen maps, Sitemaps, and Contentograms) consist of only three building blocks
  • Module (depending on the model and level of details – a module can be stakeholders, other systems, screens, containers, components, features or another kind piece of data)
  • Forward path (from one module to the next or others)
  • Backward path (return to a former module or redo a path)



The result looks a lot like a sitemap but ads a navigational aspect to it. For every module, there is a path to it and a path away from it.


Or if you want you can use UML diagram shapes ...


In a more realistic example, a module might contain of several sub modules. Those modules could be broken out into their own modules if they become more complex - it depends on your project.
In addition to the 4 models / levels of details – it will make sense to turning business and task flows and user stories into a user journey map. Creating user journey maps allow you to adjust and optimize user’s work through the app and avoid flaws in interaction between the user and the application. You will be able to identify the pitfalls and pain points of the app and improve the process well ahead of development.

I already wrote about other kind of user journey maps before.




















Comments

Post a Comment