Notes from the UXHel Round Table, June 2018
About Design systems, Value Propositions, Prioritization and Children’s Data Security.
The Round Table took place this month, after a break in May since UXHel was super busy preparing the very first UX Camp Nordic in Helsinki (June 1st-2nd). It was, by the way, a really great event, and incredibly cheap (not one of these 900€ conferences) and will happen again next year, keep your eyes open!
This time we had too many discussion topics for the number we were and had to drop some, but still managed to talk about many things:
- How to define the value proposition in an existing product?
- How to prioritise work when resources are limited?
- Data security when designing for children
- Design Systems
We used slido to figure out faster which topics we would drop out, but then we had three draws out of which we had to drop one. Process improvement in progress!
As usual, we split into groups to discuss a topic each, then present the outcome to the whole group.
How to define the value proposition in an existing product?
The problem brought up this time comes from an existing organisation, with an existing product, with an existing vision, developers who develop, sales who sell, and no value proposition. How do you then define the value proposition, afterwards, when you’re “already on the train”?
The first thing to do is to go back to basics: drive some user research, use user-centred design to test the value of the product; consider not only users but all stakeholders, from all B2B and B2C segments (depending on the product); benchmark the product competitors.
This will raise problems and questions: how do you realign the marketing strategy with the actual value of the product? Are the sales pitches (based on assumptions) still aligned with the real user benefits?
If no value is found, then a value needs to be created (based on the user research from earlier). In any case, it needs to be tested, fine-tuned.
“Selling” it internally is also a great strategy, so that the whole organisation works in the same direction. This can be done showing the ROI and other benefits (commercial and humane). Tests results (when positive of course) will provide arguments as well to install the value within the organisation: they prove that this value is the one to follow.
How to prioritise work when resources are limited?
A tiny group of two discussed this topic in a real-life situation!
What resources are we talking about?
In a project, resources that could be limited are time, people, money, data. Each of these can usually be translated into others: don’t have enough people? Use more time! Don’t have enough data? Research more! Yet it can become difficult when one of these resources is fixed, for example, the time, when there are strict deadlines to deliver.
It is then necessary to prioritise the work, by deciding what brings the most value:
- to the user;
- to the company/client;
- on the short and the long term.
The goal is to deliver a Minimum Lovable Product: instead of prioritising functionality at the cost of everything else (usability, desirability, emotion), the choice can be made to develop only the most necessary functions, but across the whole scope.
Some useful equations to help prioritise:
- Potential impact / estimated effort = effectiveness rating
- The 40% rule: if 40% of the surveyed people say they want/need your product, then go for it!
Some reference readings:
- UX for Lean Startups — Laura Klein
- Lean Analytics, Use Data to build a better startup faster — Alistair Croll & Benjamin Yoskovitz
Data security when designing for children
Some members are involved in the Designing for Children Guide design and are currently organising a workshop for the My Data conference, about data security for children. By children, understand 0–18 years old.
They questioned what are the main issues with data when it comes to children, and how to tackle them (with design).
During the discussion, 6 topics were brought up:
- Data ownership and control: do children own their data or their parents? How long does data live (in the hands of the parents)? As an answer to these questions we thought of designing systems that transfer data to the kids, and allow them to delete it if they want. Remain the question of when that should happen.
- Understanding data and data security: Do children understand data and data security? How to explain them? After all, kids just wanna have fun. And before a certain age, they can’t even read… A solution could be a communication using formats and contents that speak to the different age groups, such as viral videos, using cartoons for example.
- Parents: Most don’t understand data and data security either. Often, they may not even know what services their kids subscribe to, or what they are about. We thought of informing the parent (for example via email) of what a service is when the kid signs up for it. Another solution could be to pair the parent with their kid when onboarding a service.
- Psychosocial issues: they can be a consequence of bad data management. Kids don’t know that there are “bad” people around; and when they get bullied or harassed, it is hard for them to see that they are not the problem (their tormentors are). We would like to create awareness, help the children defend themselves; they could have access to a bully alert, a panic button, to reach support before things get too bad. On the other hand, we also see an opportunity to teach children to behave, so that they don’t become the bad guys.
- Legal issues: Where does the law stand regarding kids and data, and in particular the new GDPR? We don’t have an answer to this, but we believe that training businesses and corporate lawyers would help them understand and interpret the law so that they develop ethical products for children as well, even without legal incentives.
- Consequences: Kids don’t understand the effects of what they put online, they don’t see the extent of the world wide web (I mean, who does? I don’t). Kids can click anything without thinking twice, and why not when they steal a phone from their parent’s hands: who knows what they could tap? As with the “understanding” topic, we imagine that examples, simulations, or even metaphors, presented in adapted content and format, could be a way to help them understand better.
Design Systems (yes, again)
We talked about design systems again this time, but from a — higher point of view.
What are the values of a design system?
- Scalability;
- Reusability;
- Consistency;
- Efficiency;
- Unified visual identity;
- Open source patterns;
- Improved business by saving time, money and energy;
- Onboarding of new team members;
- Sustainability;
- Common language;
- Faster prototyping.
What makes a design system?
- Design libraries
- Shared Styles
- Colours
- Types
- Different States
- Atomic Design
- Design tools (e.g. Sketch, Figma, Studio, XD)
- Hand-off tools(e.g. Zeplin, Inspect, Abstract)
- Web Components (e.g. React, Angular, CSS)
- Mobile Components
- Pattern Declaration
- Existing Frameworks / Tools (Storybook (for both web and mobile), VueDS: VueJS Design System, Ignite for Mobile, Framer X)
- Visual Regression
- Quality Assurance
- Continuous Integration (e.g. Jenkins)
- AI integration
The design system also covers both the design and development tools: the line in between gets more and more blurry.
Please share your thoughts, comments, feedback, on the topics, on the writing, on whatever you want!
UX Hel is a community of UX professionals in Helsinki, Finland. Please get in touch, join our round tables if you are around, bring your questions and discussions!
