Workshop #2 Insights
— — — — — — — — —
General summary:
- Learning how to use is a platform doesn’t happen as soon as someone registers.
- Users who did not self identify as “low tech” would not be willing to sit through long, tool-tipped onboarding processes.
- Participants “do not know what they don’t know” so did not read closely or retain information. Commented they would need a place to replay onboarding help features.
- Participants most often looked for help as they encountered problems, making onboarding of limited value.
- Previous workshop participants wanted to see more of the “design thinking” elements into the onboarding process.
Overall help features users wanted:
- Common and recurring codes
- Q&A user generated help (like stackoverflow)
- FAQs
- Examples of working features (by other Chorus users)
Limitations:
- We didn’t have anyone who would have identified as “low skill” — however I believe we did see the problem of, just because someone has used a smart phone that doesn’t mean they “know” about how to build an app. I saw evidence of overconfidence when presented with more technical information.
- We did not have a UI or updated flow to show to participants as we discussed onboarding ideas. We were reliant on the processes shown on similar platforms.
Suggestions:
- Instead of highly generalized tool tips, anticipate where users “don’t know what they don’t know” ie parts of the process that are confusing with help they won’t need to search for. Make these a part of the platform that are always apparent, not just at the beginning.
- Keep initial onboarding walk through very simple and high level. Present information that is helpful but would not be a detriment if someone who overestimated their skill level didn’t read it and couldn’t find it again.
- Have the first section of questionnaire, purpose, visible in the building UI. Make it editable and have resources to other documentation/activites that may mimic the first workshop.
- Additionally have questionnaire linked into sections, make sections visible and give option to skip one or all. Have place in the UI where (some) answers would be seen with option to retake.
- Do not call questionnaire a “questionnaire” or a “quiz.”
- I think it would be good to think in terms of “template” and “component.” “Text/SMS” and “Survey” might be a component — “Patient Management” more like a template. Unsure how they might be represented in a visual hierarchy. Example: it’s unlikely “survey” would not need additional things (reminders, etc) and instead of guessing best fits all would provide more user customization. However I am not sure if “templates” would be a combination of several “components” or something different?
Ideas such as:
- Schedule a survey
- Send a Text reminder
- Style your content
- Write a survey people will finish
- Ect
What might be most important as final deliverables:
- How questionnaire would be represented as part of the UI. If someone takes it, and if someone does not.
- Where tutorials/components will be represented in the platform.
- An example of a template, with “help” features at predicted points.
- Examples of bite sized component additions.
— — — — — — — — — — — — -
What we did:
Activity 1:
We asked participants to take the following survey — https://mycreativetype.com/the-creative-types/ the purpose was to get them thinking about unique and fun ways to pose basic questions.
For example the quiz asks:
“Are you a ruler or a scribble?”
Which correlates to the general personality type question of whether you prefer order or chaos but is framed in a — for lack of a better word — “fun” way.
I’m not sure if the activity was entirely successful, when we had two participants taking the quiz at the same time I felt like there was more of the reaction we were seeking, whereas when only one person was taking the quiz it lacked the spirit that might have been necessary. After all, the people we interviewed are not “designers” and the concept might have felt too not serious abstract to grasp.
Activity 2:
For the second activity we presented a serious of questions designed to elicit responses from participants that would determine which template would be a good starting point.
The templates are, text/SMS, study management, patient scheduling, and survey.
We asked our participants to answer a serious of questions (1 based on assigned situation, 2 based on the their own app they were building in Chorus)
Here are the questions as ended on the third interview
- How many people will be using this when it launches?
- Ideally, how many people will be using this a year from now?
- How many responses will you require from participants during each interaction?
- Where have you considered potential roadblocks this might encounter? (prioritizing features, development, finding participants, retaining participants)
- Who are you designing for? (Families, Children, Youth, Adults, Elderly)
- What characteristics are most important to your target audience (Fun, Professional , Fast, Easy, Interactive)
- What app features are you interested in using? (Survey, Reminders, Conversational content, Sharing (Images / text), Scheduling, Text/ SMS communication, Informational content)
- (If more than two) What are the two most important features?
- What kind of impact do you want this to have? (Change behavior, Share knowledge, Make a task easier , Positive reinforcement , Accountability)
- Is this your first time building a digital service? (yes / no)
- What excites you about making this? (Having a digital service for people to use, Learning about technology, Learning about my patients, Making a task easier, Simplifying a process)
- What worries you about making this? (Lack of technical skill, Lack of design skill, Amount of time needed, Reaching participants, Focusing on most important features)
We received some general feedback
- participants who had also been in our previous workshop thought the “design thinking” aspect was missing from our quiz”
- Some wanted more assessment of technical skills
If I were to rethink the quiz I would change it in the following ways:
I would start by asking the intent and audience of the app
- Who are you designing for?
- What is the purpose of this app?
- I want to change a behavior
- I want to share my knowledge of a subject with an audience
- I want to make a common task easier
- I want to reinforce positive behavior
- I want to gather information for a study
- I want accountability for my participants
- I have something else in mind - Second question A /b determined by answer ie (What behavior are you changing, and how)
- What characteristics best represent the feel you want this to have?
Interlude:
You are creating a [characteristic] app for [audience] that [purpose of app] by [second question]
So if I had answered that the following four questions
- Children & Youth
- Reinforce positive behavior
- a. Getting enough sleep b. Giving points for nights sleeping 7+ hours
- Fun & Interactive
You are creating a fun and interactive app for children and youth that encourages them to get enough sleep by giving points for nights they sleep more than seven hours
[sounds right → move on] [input different answers→retake] [I’m not sure→ information on how to draft problem statement]
The following would be questioned asked to gauge the size of the app’s intended audience. (perhaps will in “contributors” initially with how many answered?)
{Visualization of timeline of creating app that shows steps}
- How many collaborators will be working with you on this app? (#1)
- Every new app needs a small team of testers to refine and find bugs — how many people will be in your test group (initial launch)? [ information about testing, iterative design] (#2)
- When your app launches how many participants do you predict having?(#3)
- After sixth months, ideally, how many participants would be using your app?(back to #3 after a circle)
These are questions to determine what “blocks” of content would be in the initial app interface.
- What app features are you interested in using? [what features would work best for my problem?]
- (if more than two) You might not be able to launch all the features for your app at the same time — you can always add more — what do you feel are the two most important features?
These questions determine what additional information to display as they are working on their app. The information could be displayed near the UI element or template that would use such information.
- What can we do to help you build this app?
- Information about visual design
- Help with technical skills
- Reaching participants
- Retaining participants
- Anticipating where I may find roadblocks along the way - Is this your first time building a digital service?
I’m also anticipating that by breaking the questions into blocks people might be more likely to complete the questionnaire.
Other ideas to increase completion:
- Animation of answers
- Animations / figure after each group
- Something like “building app template?”
Activity 3
Reviews of the onboarding process of Honeycode (x1) Webflow (x3) and Scratch (x2)
Although we did not have a self-identified “low tech” participant, all participants agreed they would likely “x” out of the tool tips overview. One participant said she would complete the walk through is the platform was vital to what she was doing for work.
Most participants commented that they would most likely “dive-in” and start playing with the platform and not seek help into they ran into a problem area.
Webflow
It was an assumption that a long “tool tip” type onboarding process would be most beneficial to “low tech” users, however, after going through Webflow I am inclined to believe under certain circumstances a full pointed walkthrough might be harmful if going above the basics.
Both participant groups who went through the process with webflow said they understood both the “box model,” basic concepts of CSS styling, and breakpoints — concepts which need more than a paragraph of information. The information was both unlikely to be read and not helpful when read. Also one participant group said they thought they got it but wouldn’t read more.
After spending some time on the webflow template myself I wasn’t sure there was much of a benefit of both talking about these concepts.
participants remarked that webflow loaded with an overwhelming amount of features, but participants liked the idea that they could play with a lot of features. Just did not want to see them all at once. (accordions could be folded up)
Chorus might benefit more from being barebones as possible in this approach — even so far as saying people with technical ability might not need this walk through (whether true or not)
There is also the reality that participants will likely overestimate their technical proficiency — unless they have worked as developers previously.
Participants liked the fact that Webflow’s templates started with a a fleshed out version of what the webpage would look like. All wanted flexibility but liked that they could more or less envision what the page would look like.
Scratch
Participants liked the “bite sized” tutorials of Scratch — but commented it was too reliant on user imagination to imagine a full app or animation. Chorus might benefit from the “bite sized” approach to explaining content blocks but begin with a fuller template.
They were particularly positive about the fact that the video tutorials could be followed in the workspace so they could play and pause along with the video.
They also liked the community functions of scratch. Although they said they would be hesitant to share their apps with other users, they liked the idea of getting help and feedback from other users.
