Confirm
630
edits
Changes
→Use cases
This part intent to answer the question: What do we want to do with compatibility data? This will help us defining which data we need to have.
=== Targeted audience ===
In order to better understand want we want to do with compatibility data, wa identified a few profiles that need to be kept in mind as they well as their possible motives. Those profile will be refine while moving to a more formal UX step in the project.
==== web developers ====
Web developers always have a hard time while working in a cross browser environment. To avoid that, they need to be able to found detailed information regarding the feature they are working on and it's availability among browser as well as information to bypass a possible lack of implementation.
==== App developers ====
App developers are a bit different from web developers as they wish to focus on a smaller number of platform (if not just one). To that end, they needs detailed information about implementation of feature on a specific browser or version of a browser.
==== web architects/lead dev ====
Those are people building the technical strategy beneath a project. They need fully detailed information about browser compatibility in order to take rational and accurate technical decision that can ease or jeopardize their project in the long run.
==== project leaders ====
Those are people who must take decision regarding their project. For that reason they needs decision tools able to provide them with accurate but not overwhelming information regarding browser compatibility.
==== beginners/learners ====
As they are learning things about the web, beginners are one of our key audience. The complexity of the web interoperability is one of the pitfall of web development. In order to ease their learning experience, we must be able to provide simple understandable overviews of feature support among browsers.
=== Display data ===
