Differences
This shows you the differences between two versions of the page.
| Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
| human_interface_design [2026/09/14 09:28] – [Design discovery] sarah | human_interface_design [2026/09/14 23:41] (current) – [Design discovery] sarah | ||
|---|---|---|---|
| Line 1: | Line 1: | ||
| - | ====== Design | + | ====== Design |
| - | + | | |
| - | | + | * **Users & key journeys** |
| - | * **Users & key journeys** Main user types and core tasks | + | |
| * Sarah' | * Sarah' | ||
| * Node steward: setting up the node; onboarding when node is operational; | * Node steward: setting up the node; onboarding when node is operational; | ||
| Line 10: | Line 9: | ||
| * Member of the public or community group: encountering nodes in community spaces; learning about the network project; reporting issues; getting help; becoming a contributor; | * Member of the public or community group: encountering nodes in community spaces; learning about the network project; reporting issues; getting help; becoming a contributor; | ||
| - | * **Design principles** | + | * **Design principles** |
| - | * **Identity directions** | + | * **Identity directions** |
| * Initial ideas from August 2026 Solarpunks meetup: | * Initial ideas from August 2026 Solarpunks meetup: | ||
| * Colours: green to signify renewables / resilience. | * Colours: green to signify renewables / resilience. | ||
| Line 19: | Line 18: | ||
| ====== Design creation ====== | ====== Design creation ====== | ||
| - | * **Identity design** Output: Logo, colour palette, typography, icons / illustrations, | + | * **Identity design** |
| - | * **Sketches & wireframes** Output: Wireframes for key screens and flows | + | * **Sketches & wireframes** |
| - | * **Copy & microcopy** Output: Onboarding text, labels, buttons, messages | + | * **Copy & microcopy** |
| - | * **Visual design** Output: High-fidelity screens and simple style guide | + | * **Visual design** |
| - | * **Usability and accessibility review** Output: Prioritised issues, required design changes | + | * **Usability and accessibility review** |
| ====== Design evolution ====== | ====== Design evolution ====== | ||
| - | * **User testing & feedback** Output: Prioritised issues and improvements | + | * **User testing & feedback** |
| - | * **Design backlog & governance** Output: Ongoing list of UX/UI decisions and future work | + | * **Design backlog & governance** |
| + | |||
| + | ====== Jade's Thoughts (not gospel) ====== | ||
| + | |||
| + | ===== Users & Key journeys ===== | ||
| + | |||
| + | **Node steward** is a key initial user persona. Sarah' | ||
| + | |||
| + | * Stewarding a node is a key technical on-ramp to the project. The first experience of a Steward (either setting up a node, or onboarding to an existing node) might be their first experience with the project and is key to a good impression. | ||
| + | * We do not assume existing technical knowledge for node stewards. It's a learning journey. | ||
| + | * The current thinking (open for discussion) is that it's hard to protect a node from it's stewards. This is not a corporate platform with detailed authorization rules. As such, our approach is probably " | ||
| + | |||
| + | **Neighbourhood user** feels like the second priority to me. Some notes: | ||
| + | |||
| + | * Our key theory of change is that we can reduce the carbon emissions compared to big tech, but moving compute from an infinite " | ||
| + | * Some neighbourhood users are potential volunteers (as node stewards or other). There should be pathways to learn more about how things are working, get more interested, and then get involved. | ||
| + | * Users should also develop a sense that the system is maintained by real local people, and that doing so is labour. This might be made most clear if they need technical support or training. It might also be conveyed through a small cost and clear explanation of where that goes (all not-for-profit obviously). | ||
| + | * Users will sometimes have an experience of using the system in an outage, and will have journeys that don't involve the internet. | ||
| + | |||
| + | **Member of the Public** | ||
| + | |||
| + | * A potential user who stumbles across us, and may wish to learn about what we do. This is an important category for us in the near term to support adoption. | ||
| + | |||
| + | **Site partner** | ||
| + | |||
| + | * Our nodes are all likely to go in locations not run by us. The people running those locations are key partners. There is some similarity to member of the public, in that both might want to learn about how the system is going, but it seems like site partners in particular will benefit from learning about the value they are creating by hosting a node. | ||
| + | |||
| + | **Other volunteers** | ||
| + | |||
| + | * This should probably be broken up. However, if we look in the moderately near term, at the first two milestones on [[https:// | ||
| + | |||
| + | **Unknown Region governance roles** | ||
| + | |||
| + | * Region governance is an unknown space. A LoRes region is a set of nodes across a geography like Merri-bek. There may be decisions to make at that scale. It should neither be top-down, nor should it be a process of autonomous nodes doing whatever they like. Services like training, customer support, and content moderation happen at the region level. | ||
| + | * Additionally, | ||
| + | |||
| + | ===== Design constraints ===== | ||
| + | |||
| + | * Essentially every flow will need to work on both phone and desktop | ||
| + | * Most user-interactions will need to consider eventual consistency (the data may take time to move between nodes, creating a need for displaying incomplete states). | ||
| + | * There may be need to separate "LoRes Mesh" branding from white-label branding for the regions. It's fine to have the LoRes Mesh branding used for all technical volunteers (particularly node stewards). Region-specific branding should be shown to users, particularly in landing at the region home and discovering what services exist. It's undecided whether this is just "pick a few custom colours" | ||
| + | * Web apps installed on nodes are often not written by us, and will all look different. Although we will unify some things (eg: single sign-on), we can't unify visuals. As such, our visual design should work well with a patchwork of different tools. It should not convey slick, unified perfectionism. | ||
| + | * Different regions should have some clearly distinct visual elements. It should be clear if you're using " | ||
| + | |||
| + | ===== LoRes Branding ===== | ||
| + | |||
| + | The public branding at [[https:// | ||
| + | |||
| + | The audience for this branding is potential technical collaborators, | ||
| + | |||
| + | Given these goals, we have stayed well clear of the colour green. Green is overused, and so has been watered-down. Progressives see it in corporate green-washing. Conservatives see it and see "the enemy", | ||
| + | |||
| + | Instead, we hope to unify across the political divide. The colours chosen for the lores.tech website are: | ||
| + | |||
| + | * sky blue: conveys reliable, engineering (we use a blueprint pattern in some cases), conservative, | ||
| + | * bright-orange/ | ||
| + | * burned-orange/ | ||
| + | |||
| + | This colouring works well for the engineering project. It *may* work well for aspects of the user-facing experience, but maybe not. For facing the community in-general, the following concepts feel important: | ||
| + | |||
| + | * Not screaming " | ||
| + | * Emergency resilient, but the good kind (like the way we feel about the country firefighters) | ||
| + | * Community, local, ours (not really present in the LoRes branding) | ||
| + | * Playful, hack-able, participatory - Like the internet that we used to love, back when we built geocities pages and everyone could have a go. Not slick, not corporate. | ||
| + | * Hope. We can do this. It isn't insurmountable, | ||
| + | * Not screaming " | ||
| + | |||