Animated gif of the MemorySparx reusable components in Sketch.
Life edit album screen with annotations.
MemorySparx system flow
Samples of the MemorySparx design system.
I conducted a design review in “MemorySparx — Design System Research (Part 1)”, and determined it was time to establish a design system because:
► We have a proof of concept, and the product’s core features and tools are stabilizing.
► There was funding and justification to set this ground work and start scaling.
► There were UI patterns forming in the information architecture and user flows, but they were not always coherent.
► There was a need for better communication and design habits for everyone on the team
Building a design system can be a big undertaking, and persuading stakeholders to invest effort in this work can be challenging. A compelling way to convince the boss and develop this body of work was to implement the system piece-by-piece. Each piece should have a concise purpose, and can tag along with a current task, or should be justified as necessary foundation to follow the product roadmap (e.g. meeting accessibility standards for the health industry). Moreover, bite-size pieces made it simpler for the product team to consume and train at their own pace, and form good design habits.
Over the course of a year, the current design system accumulated into these tools:
► Device compatibility guide and service level agreements.
► Proprietary design system — guides for the component library, page layouts, typography, and displaying images online.
► Curated quick references to domain knowledge of web and mobile standards and practices. (I.e. a wiki.)
► Implemented a set of accessibility HTML and CSS components and templates based on the guides.
Source: Cowboy silhouette, 2020
Wanted:
Set boundaries to focus on quality work
Being a very small product team, we all recognized the limitations and the accumulating challenges to customer support as more users are active in the application. It became imperative to set boundaries on issues that we can support, so we can focus clearly on developing and improving features that mattered most to our users.
Fortunately, the tech industry has a culture of scoping support with standard policies such as service level agreements, device/software compatibility terms and conditions, and accessibility standards. It was easy to obtain resources, and straight-forward to start making decisions quickly.
Found:
Caution tape — Set device support guidelines
Service Level Agreements
Written service level agreements (SLAs) were set and published by the IT team. It detailed the technical support services Emmetros will provide for the MemorySparx product. It included commitments on reliability, specific response times, resolution times, and directions for issue reporting. Since these agreements are standard procedures in IT, the design team’s input was limited to determining resolution times and internal response procedures from past history.
Device Compatibility Recommendations — Mobile First
Immediately after reviewing the failed release candidate app (see Part 1), I advocated for a “mobile first” mentality and the product team agreed to build a strategy around it. The MemorySparx app needed to be portable (on tablets and/or smartphones) in order to be useful for our customers and users. Being “mobile first” meant we adopt a habit of thinking about, and managing, the lowest common denominators that required our support.
First action was to specify a list of compatible devices and technologies, which was appended to the SLA. The objective of this document was to set working parameters that are inclusive of our customer’s technologies by:
► Evaluating the oldest devices our users may be using, and the popular low-feature devices that made sense to support.
► Confirming the network capabilities of our current and potential customers, as well as defining offline features of the app
As I was technically proficient on current hardware and technologies, I collaborated with the dev team and product manager on defining supported devices and technologies. In summary, we concluded that:
► Network capabilities: Our customers were long-term care homes with limited IT infrastructure, we discovered that wifi was slow but most has access to North American cellular networks. Thus, we expected to support 3G mobile broadband and higher speeds.
► Offline content: Due to the basic network capabilities, business team called for the app and user’s contents to be available off-line. A syncing strategy became priority for the development team.
► Tablet/Desktop Hardware: Must support mobile devices as the app should be an easy-to-reach memory aid. Tablets were the primary devices for users to access MemorySparx, so it required the full feature set and priority support. I identified the following stats on popular tablets, and we set the requirement to fully support 10” tablets and desktops with a minimum of 1024x768 resolution (and limited support on devices like Amazon Fire).
► IDC noted that Apple, Samsung and Amazon formed majority of the tablet market.
► From StatCounter Global Stats and Apple’s and Samsung’s estimated sales numbers, 10” tablets with standard VGA 1024px × 768px resolution were the most popular in North America. These stats also showed about 80% of tablet and desktop users used a minimum of 1024px × 768px, where majority of users had 1080p devices.
► Smartphone Hardware: There was business growth towards using the app on smartphones. Smartphones then became the lowest common denominator for hardware and software requirements, due to its limited screen real estate and processing power. Research data for smartphones was gathered and noted:
► Customer success tallied that our customer and user demographics were on older iPhones or cheaper androids.
► I compared the tally to actual market data of best selling devices, its popular screen resolutions, and vendor market share.
► From the data at the time (2017/2018), I made an educated guess to set requirement for minimum phone screen size at 4.5” with minimum 300 ppi, and 720p resolution. iPhone 6 and Samsung Galaxy S4 were the base device samples.
► Software: The company pivoted to developing web app during this research, so both iOS and Android systems was considered.
► OS: We were able to support iOS10+ with confidence but limited support for iOS9 (still had a significant 10% of Apple device distribution at the time). For Android, the backward compatibility was better, but updates were not mandated/automated. We needed to support API 19 KitKat and higher, which covered 86%+ of the Android distribution.
► Browsers: Leadership decided on fully supporting Chrome (and its latest 2 versions) and limited support on Safari (as Chrome on Apple products was a skin of Safari). This was a point of contention because development team wanted Chrome-only as it had the technologies needed for implementing video/audio features, but customer feedback and research data showed users tend to stay with default browsers such as Safari and IE/Edge.
Wanted:
Consistent and inclusive visuals
From the design review, I brought to light some missing conventions and execution details that resulted in UI and usability issues on the MemorySparx app. Inconsistent UI is not uncommon in software development, especially when multiple contractors have added features to the app at different times. Nevertheless, to scale properly, the entire product team needed to be able to visualize and talk about the product and its interactions as one coherent whole system.
Found:
Developer’s toolbox — Component guides and Library of assets
User's Workflow Schematic
Mapping the app’s workflows (e.g. product discovery, onboarding, creating content, etc.) as one connected system was a great visualization for:
► Discovering conventional UI patterns to standardize in our system
► Progressive disclosure: where a user can skim a page with a list of items, and then can select an item to go to a page with full details. Making this consistent across all read-only content flows sets the expectation that if they’re looking at a summarized list, they can always dive deeper for more details.
► Click to edit: customers wanted control read/modify permissions on the personal content because some users had cognitive disabilities and had difficulties keeping track of their content. This pattern was used on forms to allow users to view the content and recall their memory, without accidentally changing content such as medical information.
► Exposing and removing inefficient information architecture. We improved the rate of product downloads from 4 downloads a day to 10-12 downloads a day (100%+ increase) by removing the step from the facebook ad to the product website, and instead directly linked to the Apple App Store product page, which already had the same details. It got potential users to try the product faster.
Fig. Prototype for MemorySparx care provider section showing progressive disclosure and click-to-edit.
Even better, I recognized a service design flowchart was taking shape, which is a well known concept with great resources. This next step will help identify improvements for our product and supporting services.
Centralized Assets like Low-fidelity Wireframes
Low fidelity wireframes are great for quick rough prototyping and showing basic users interactions. The design team relied heavily on these visuals to kick off new features and used it later as a reference to the basic core functions of the feature. However, these diagrams were hard to find because only half were available online, and the other half was on different designers’ local computers. The dev team mostly had scattered printed copies from past meetings. There were viewing issues given the diverse formats of these diagrams and other graphical assets from Balsamiq, PhotoShop, Sketch, draw.io, etc. We needed to consolidate these resources so it is easy to reference for the product team.
I looked for feedback from the product team on where they frequent online for proprietary information, as well as the software and formats they usually used to view information. We constantly (but not optimally) used Atlassian’s EMS products (JIRA, Confluence, etc.) to communicate across teams. Thus, our design team came up with an organizational structure for our internal wiki (Atlassian Confluence), and arranged design assets in terms of feature set and chronological updates. Moreover, we uploaded the assets in PDF formats along with the original formats so the product team can annotate/comment, and also make use of the wiki’s version control.
This change was validated when QA started referencing these artifacts as part of their root cause analysis from bugs being tracked in JIRA.
Creation of High Fidelity Artifacts
The MemorySparx product was growing, and growth came with complexity. As features were created, evolved, and extended, gaps were exposed in our integrations. The app was missing user interactions and professional visual finishings.
From reviewing and consolidating design assets, I noticed that low fidelity assets, such as wireframes, missed out on layout information like paragraph styles, look-and-feel, etc. The dev team did not have enough information to accurately implement features, and had to make assumptions and infer a professional solution. Since the dev team was mainly comprised of junior developers, we lacked some technical conventional wisdoms such as UI patterns, typography principles, and experience with different design systems and libraries. Having a knowledge-base of these common conventions can really help fill in the gaps between customer’s ideas, to drawing concepts, and then to production.
Hence, it seemed appropriate to bring in design conventions and add a suite of detailed visual guidelines.
Reference Conventions —
iOS HIG, Material design and WCAG 2.0
iOS HIG
MemorySparx was originally an iOS app, so I compared the app to Apple’s Human Interface Guidelines (HIG). I logged unconventional patterns and components, like buttons with modifying/destructive actions outside of navigation bar, confirmation alerts were missing for destructive actions, popovers being used for complex image editing (not responsive), and typography was inconsistent where one page title was 21pt and another was 24pt, etc. Even so, it was beneficial to employ the HIG to:
► Make informed directions for the dev team to refactor the app with a mobile(phone) first approach in order to ensure responsiveness.
► Standardize typography and add meaning to paragraph styles. E.g. Titles are brief descriptors of a page, titles are located in the navigation bar, and size is 36pt.
(Angular) Material Design
Since the company pivoted MemorySparx as a web application, leadership and the product team agreed that while they like the iOS look-and-feel, it was worthwhile to move towards a popular web UI library with the anticipation that we’ll have 3rd-party support, and simpler responsive and accessible implementations. Upon this change, I conducted research on several UI libraries to set a new foundation — Bootstrap, Semantic UI, and (Angular) Material Design.
The product team decided to base our UI on Material Design because it was gaining popularity, its flat design look was on brand, it had specs for generating accessible components, it was well integrated with Angular (both by Google), and it had the associated big 3rd party teams behind it to give us technical support.
Angular Material library established our front-end foundation for
► Layout: I regimented the 8pt spacing system to keep margins and content heights aligned. CSS Flexbox and Angular Flex Layout provided responsiveness to grid layout. Spacing were also set rem units to follow user’s accessibility web settings.
► Fonts: Applied Angular Material’s typography to set character styles to our brand’s font (Avenir). This allows for flexible theming and a single-reference point for fonts in the system. We settled on points(pt) and rem as the units for typography in order to be consistent and responsive at handling pixel density on different devices.
► Components: I refactored our existing components by re-skinning onto Material’s components, which matched our branding and WCAG 2.0 AA level of accessibility. The component were mostly responsive out-of-the-box, and it shaped our concepts and ideas on how it can be used. E.g. Setting character and line height limits in a form field. We also integrated Angular Material’s icon registry, giving our system a single point of reference to our icon set and scales the SVG icons accordingly depending on the context.
I re-skinned Material components to match our brand and WCAG compliance. The components are accessible and focused while maintaining the flat design feel.
WCAG 2.0 AA Level Compliance
Accessibility had been a priority for the company considering that the MemorySparx is a healthcare app, and our customers are AODA-compliant (Accessibility for Ontarians with Disabilities Act). For us to also be compliant, it was crucial to follow the Web Content Accessibility Guidelines (WCAG 2.0), an initiative set out by the World Wide Web Consortium (W3C).
WCAG 2.0 laid out requirements and tips that informed our design:
► Typography: To meet Level A, our minimum font size needs to be approximately 16pt (dependent on pixel density), and our column widths should be no longer than 80 characters.
Images: Captioning are mandated, and diagrams are recommended to have high contrast for the visually-impaired.
► Color guidance: Our brand’s primary and secondary colours needed slight adjustments to be higher contrast to meet at least Level AA(i.e. approximately 4.5:1 ratio)
► Gestures: touch targets should be a minimum of 44px by 44px, and employ single-point gestures only (i.e. single tap, double tap, and tap-and-hold)
► Content sequencing: User must be able to interact with our app using only a keyboard.
Constituting and sharing these guidelines was one of the most effective improvements to our work processes. The dev team was able to extend these concepts to build our app’s error handling with Material’s alerts and error components. By the end of the year, the product team made regular references to WCAG and Material design concepts, and the dev team was more proficient at filling in the gaps between customer needs and implementation.
Typography Guide
In the past, our UI was uncoordinated from work being passed around different contractors, and consequently leaving us with discrepancies in our typography. There were different font sizes and styles for titles on different pages causing a loss of context. Similarly, some text appeared bold but was not meant to draw attention. The biggest problem was that the fonts were not responsive leading to labels being too large on mobile phones, or body text too small and blurry to read on desktops with cheap monitors.
Different font sizes and styles can draw the eye to different parts of the page, not necessarily from top-to-bottom. Source: designershumor, 2020.
MemorySparx is a digital memory aid, and it was essential to have an organized field of view in the pursuance of recalling content quickly. We did this by managing layout and typography for a consistent and coherent look. Angular Flex Layout API and CSS Flexbox were adapted to straighten out content visually, while our customized typography lifted the app with an on-brand feel.
Avenir was chosen early on in the company's history, and we decided to continue its use on our App as well as our marketing because:
► It is a sans-serif font with a clean and modern look that is readable on digital devices at the sizes recommended by HIG and Material.
► There were flexible style options available in the market making it readily responsive and accessible.
► It is a web safe font that was easily integrated into the app with Angular theming.
Custom Typography by Extending Conventions
WCAG 2.0 provided the baseline minimums for font size and styling, but I discovered the fonts was still too small sometimes to be legible on mobile phones due to high pixel density. With extra research, I extrapolated from the print standard 16pt at 72ppi to an absolute minimum of character line height of ~5.5mm for body text, with consistent tracking and kerning at least 0.5mm. (See RGD’s “AccessAbility 2: A Practical Handbook on Accessible Graphic Design”.)
With this baseline, I correlated our Avenir font to Apple’s HIG (i.e. dynamic type sizes), then to Android’s Material Design defaults, as well as converting to match HTML text formatting such as headings, paragraph, comments, etc. To account for responsiveness, I distinguished different sets of fonts for mobile vs. tablet and desktop, and converted pt to rem to allow for user’s individual accessibility settings.
Angular Material Typography —
Code Once and Forget It
Once I had the typography guide it was straightforward to set up Angular Material typography utility via their open-source SCSS mixins and functions. This development work rooted a single-reference point for fonts in the system, so changes can be made quickly and scales consistently across the application.
SCSS for Angular Typography configuration.
CSS for Memorysparx typography and paragraph styles.
CSS for Memorysparx typography and paragraph styles.
SCSS samples for Angular Material typography configuration, and CSS for Memorysparx typography and paragraph styles.
Image Display Guide
MemorySparx app and various ways of image display.
Our users relied heavily on imagery to recall memory, and our product needed to present their captures in a visually meaningful way. We previously had technical challenges displaying the images because we permitted too much editing freedoms for their photos, like oddly thin crops and too much enlargement/scaling of photos, which affected the quality of the images displayed and unpredictable page layouts.
We did some research on popular social networks and image apps like Instagram, Twitter, Flickr, Google/Apple photos to look for any conventional strategy we can piggyback. I discerned that they did set images limits on file sizes and dimensions. Mobile apps like Instagram permit only a few aspect ratios (3:4, 4:3, 1:1, 9:16), restricted minimum width and height, and limited file sizes so they can load the content quickly for their user experience. Photo-centric applications like Flikr did allow for massive photo uploads, but have additional prompts and loading experience before display photos at full integrity.
In the same fashion as the SLAs, we needed to set some limits. I came up with a guide to image display and management for our system (i.e. MemorySparx app and associated infrastructure). The guide defined:
► Supported formats of images/media (e.g. jpeg, png, mp4, etc).
► Minimum and maximum file sizes for upload
► Download file sizes for display depending on type of device (responsive) and use (e.g. thumbnails are extra small versions of the image and should be loaded quickly).
► The types and ranges of image dimensions and aspect ratios throughout the different pages of the system, and a description of its context (i.e. Why we use a specific dimension and scaling for the image on each page/component).
I also coded up the responsive CSS and SCSS properties to handle image display on the system.
Sample SCSS for general images.
Sample SCSS for care provider images.
Sample SCSS snippets for handling images.
Page Layout Templates
While wireframes described user interaction and each page’s purpose at a bird’s eye view, the dev team wanted more explicit directions on the details of the interface and micro-interactions on each page — the user experience at the atomic level. From investigating the workflow schematic, there were only a few types of pages in the application. So, I drew up some high-fidelity page templates to describe each page’s purpose, components, and user interactions. The templates were linked to Atlassian Confluence, and shared through Zeplin for better collaboration by page context.
We were able to extend features quickly and consistently by reusing these templates. For example, the app called for more user input on configurations as the system increased in complexity. We recognized these are administrative settings, and reused the same theme as our administration pages: The grey colour palette, multiple sections with headings and subheadings, same spacing, etc.
The catalog also gave us some language around talking about the system. QA was able to describe bugs briefly and concisely like, “The medications details page in edit view on mobile does not display character limit in the comments field.”
Components guide and symbols library
I gradually built up a component library in Sketch and shared it with descriptions on Zeplin. The library was necessary groundwork for:
► The design team to produce high-fidelity prototypes efficiently by reusing the components.
► The dev team to trust that they had implemented the correct components and consistent layouts.
► The product manager and leadership to test out ideas quickly in the app’s context.
When I was designing the app’s navigation, I was able to pinpoint technical challenges early like character limits on tab bar titles, and solved the issue by specifying the appropriate responsive behaviour for using ellipsis.
I was also responsible to code and style these components on the front-end from the standard material components to our brand and theme via SCSS.
A component library is a must-have in a design system so the product team can create prototypes and implement features quickly and consistently. A sample for MemorySparx created in Sketch.
Found:
A Common Language
By supplying these tools and sharing them to a popular collaboration spot, we reaped the benefits of:
► Design advocacy: Our team have now experienced design in action, and have the know-how to find and discuss resources on good design conventions
► Reusability: We now have pre-fab, responsive, accessible, high-fidelity components for prototyping and copying directly into production code.
► Coherent communication: The product team have proprietary resources and terms to talk about the system throughout our work process
► Technical proficiency: We can create and extend features swiftly and consistently with confidence
The proof is in the pudding. Source: Giphy,2020
Validation: Notifications
We implemented notifications in MemorySparx when our customers asked for social features that allowed care providers to add content for our users with dementia.
The workflow schematic informed us about a common use pattern of a page with a list of notifications and clicking a link item will jump to the appropriate read-only details page or message thread. The page templates illustrated the basic responsive looks to a listing page. Additionally, there were also coded components and related CSS properties readily available for reuse from the health contacts list.
Notifications list on iPad.
Compare with care provider list on iPad.
Validation:
Tracking changes
Since the page templates gets updated in Zeplin when features are added or change, QA was able to track down when the changes were made and the visual discrepancies between the original and new look of the feature.
Validation:
Language to talk about MemorySparx
The product team can now describe features and issues concisely — a key to effective feature management.
QA would now summarize bugs like, “The medications details page in edit view on mobile does not display character limit in the comments field.”, or PM would describe a feature change like, “We need to add a thumbnail to a message notification if it has an attachment”.
Next Steps
Given the positive feedback and usage of these tools amongst the product team, we can continue to improve our design system by:
► Refining the system workflow schematic to a service design flow blueprint, so we can have a holistic view of the system to solve business problems.
► Adding version control for the (vector) component library in Sketch, maybe also moving it to Figma which also has a cloud service for better access.
► Advancing our education in design principles and patterns by supplementing new feature specifications with design terminologies and case studies.
3 Take-aways
1. Know your customer’s needs and their current infrastructure. Ensure we can support them with our capabilities.
2. Be a design advocate for consistency and convention. Improve the wheel don’t reinvent it.
3. Build the design system bit-by-bit. Have an execution plan with bite-size projects that can be attached valuably to existing work.
Are you scaling your software application? Do you think you need a design system? Hit me up at me@jnetix.com!