Who are or will be our users?

[pylapp]

Context

We, as a team of iOS developers for Orange Unified Design System, should know who are our users, their profiles, their needs.
Here are some ideas.

Important

We do it talk here about customers nor stakeholders, but users, i.e people with who we'll discuss more, e.g. developers. Keep in mind that some customers (countries, business units) may have other needs (custom themes, specific tools, laws), and stake holders may be focused on ROI and budget.

Tip

Order of comments / suggested answers below or numbers in there titles do not lean anything

Do not forget

Important

There is a lot of diversity of resources, tools and skills within our users, we must take into account as many constraints as we can.

1. Users can be skilled, senior profile, expert profile, or junior without experience
2. Users whatever the profile is may need documentation with several level of details
3. Users may need time and resources to integrate the library, so they may need help to make it faster
4. Users can come from France but also other countries in Europe (Belgium, Luxembourg, Romania, Slovakia, Moldova...) or Africa (Ivory Coast, Tunisian, Egypt, ...) or middle-east (Jordan) or Asia (China). So we must take into account cultural aspects and delays in exchanges, and also diversity of ways to work and discuss.
5. Users can work with designers or not, aware of RGAA or not
6. Users may need to have kind of custom theme using Orange branding but with some adjustments

[pylapp]

1 - Developer of an iOS / iPadOS app with SwiftUI from 0

This profile is particular as the user is a developer working on a new project, starting from 0.
The user may need ready to be used components and theme so as to implement its app quickly with high quality standards.
The new project can be a research project, a massive refactoring of an existing one or a new flagship app for example.

Note

The killer features for this type of side is the set of components and theme themes provided by the library.

[pylapp]

2 - Developer on existing SwiftUI iOS / iPadOS app

This user is different to the 1st one as it has already an existing codebase with maybe legacy code.

The user may need help to integrate the components because it is possible that clean code method and principles like SOLID have not been applied resulting to have components of views to much related to business objects or domain. So there will be an effort to integrate the components and making them less strongly related to all objects and layers of the app.

Note

The killer feature here can be the components and the theme, or maybe only the theme with the tokens: in that last case maybe the user does not have enough time or resources to make migrations and needs overall the tokens for the colors or fonts for example.

[pylapp]

3 - Developer on existing UIKit iOS / iPadOS app

This user is different to the 2nd one as it uses kind of legacy framework for the views.

Note

The killer feature can be the same as user n°2, however if the refactoring to do is too much heavy only the theme object with the tokens may be used.

Caution

However there is a pain point: the library should or must provide helpers or wrappers to allow users to add SwiftUI views inside their UIKit views.

[pylapp]

4 - Developer of iOS / iPadOs app not using SwiftUI or UIKit

Users can be also developers of iOS apps but not using Apple frameworks like SwiftUI or UIKit.
They can use for example Kotlin Multiplatform, Flutter, React Native or Xamarin.
If so, we can redirect them to the Android and Flutter projects, but we must be sure all the iOS requirements and specifications are respected.

Note

No killer feature for them as our codebase may not be integrated in theirs.

Caution

But there is a pain point: are we sure (and how) these users will be able to integrate OUDS?

[pylapp]

5 - Developers on non-iOS / iPadOS SwiftUI app

Some developers can work on apps with SwiftUI but not for iOS and iPadOS like apps for visionOS, watchOS or tvOS.

Note

The killer feature can be the same as those for the developers of iOS SwiftUI apps

Caution

But this pain point must be solved before: the OUDS iOS library does not manage yet anything else than iOS / iPadOS (i.e. never tested on watchOS, tvOS, visionOS).

[pylapp]

6 - Developers without Figma or design team

Some developers can work on prooves of concepts, prototypes or projects without designers or Figma specifications. Thus the complexity of the API must be reduced or not scarying for them. They must be able to use the library and components easily and quickly.

Note

Killer feature can be components and theme ready, easy and quickly usable.

Caution

If API is too much complex, too strongly related to Figma, the API won't be that mich aliogned to OEM native API, thus users may be lost

[pylapp]

7 - Developers wanting Orange design with Liquid Glass

Liquid Glass is coming. Developers will need to move it. If OUDS provides Liquid Glass ready components we may catch these users in our nets.

Note

Killer feature can ne components and theme ready, easy and quickly usable.

Caution

If we do not support Liquid Glass we may loose users