Welcome

I’m Richard Lee, a designer, commerical drone pilot, podcast host, voiceover actor, musician and artist – ie. a learner for life.

Helping teams and individuals learn and grown is a constent passion – whether I’m leading teams or acting as an individual contributor. 

I’m interested in applying insights and craft from my time in  design, development and leadership roles to solving new challenges in exciting spaces. Healthcare, AI, Automotive, and HR (helping humans do better work in the right roles) are domains that I’m passionate about. 

I focus on understanding user needs first.  Within technical constraints, I balance them with business needs – and then the win/win path becomes evident.  

Ask me how.

Review: How To Start A New Country

My thoughts on “How To Start A New Country” by Balaji S. Srinivasan

Balaji S. Srinivasan is a prolific writer, founder and entrepreneur. His article from April 9, 2021 proposes starting new countries as digital communities:

The network state is built cloud first, land last. Rather than starting with the physical territory, we begin with a digital community.

Generally he can be depended on to expound at length on widespread topics in what some might call informed forward thinking, and others derisively label as science fiction, wishful thinking or technopositive propaganda. What is propaganda though?

“communication that is primarily used to influence an audience and further an agenda, which may not be objective and may be selectively presenting facts in order to encourage a particular synthesis or perception, or using loaded language in order to produce an emotional rather than a rational response.”

https://en.wikipedia.org/wiki/Propaganda

I would argue that this piece on a rather bold topic IS in fact communication being used to influence an audience, and to FURTHER AN AGENDA. I would not agree that it fits the definition beyond that, as it takes great pains to present facts clearly, perhaps anticipating such accusations and heading them off at the pass.

The article encourages both an emotional AND rational response, and in fact encourages rational thinking as it lays out the thinking behind the initially eyebrow-raising premise – starting a new country.

What case is it trying to make?

The author works to point out and get consensus on the concept of ‘a fresh start’. Why “new” is attractive, beneficial and feasible, comparing the rationale of a new country to that of a new company, new canvas or an empty page. This comparison escalates quickly, to buying vacant land with the idea of development, to new cryptocurrencies being created despite hundreds of perfectly sound ones already being in use.

Why Start a New Country?

Spanning ancient history and modern day events, Balaji quickly and compellingly lays out the “Why”, and moves on to “How”, detailing the specific ways new countries have come into being historically: Elections, revolutions and war. Next up are several modern additions to that toolbox: Micronations, Seasteading and Space. While these are interesting and worth keeping an eye on, his focus is on the concept of Cloud Countries.

Our idea is to proceed cloud first, land last… we start with the digital community… people interested in founding a new virtual social network, a new city, and eventually a new country… we organize our internal economy around remote work, we cultivate in-person levels of civility, we simulate architecture in VR, and we create art and literature that reflects our values.

https://1729.com/how-to-start-a-new-country/

Again, the language implies that every objection to this premise has been captured and countered, including “but, but countries have physical land, and measurable imports and exports, and quantifiable populations!”

Physical land need not be contiguous, and country-scale leaderboards already exist that track the population, solvency and outputs/inputs of countries across the world – so what’s the big obstacle again? Balaji feels path towards building a country lies in a reverse diaspora: a voice into a trickle into a chat room, then a recognized few enclaves in the physical world that correlate to digital communities – call them neighborhoods or call them what you will, the progression seems feasible.

Shared belief as a concept is identified as the fundamental mechanism in how currency works in general, with cryptocurrency specifically as an example of consensus belief, and that other measures of belief include voting with one’s feet, wallet, or even one’s mind via editorial content creation. Beyond simple belief though, the case is made that all the ingredients for this shift are already in place.

… the cloud country concept takes the most robust existing tech stack we have – namely the suite of technologies built around the internet – to route around political roadblocks, without waiting for future physical innovation.

Defining what a country truly is boils down to both quantifiable and societal elements. A country must have numbers, from how many citizens live there and contribute/benefit from statehood, and what it consumes and produces – these things define the impact it has on the global stage. A country must have recognition and representation on that stage, and be able to govern itself effectively.

Comparisons are made between Bitcoin and a new cloud country’s formation – the slow onramp, the gradual building of legitimacy and stored value, and the eventual societal acceptance and financial institution buy-in of Bitcoin we’re seeing in recent times. Another comparison case is made between digital networks like Facebook and Twitter, their longevity and robustness, and the size and robustness of actual nation states:

20% of existing countries have a population of less than 1M and ~55% have a population of less than 10M. This includes many countries people typically think of as “real”, like Luxembourg (615k), Cyprus (1.18M), Estonia (1.3M), New Zealand (4.7M), Ireland (4.8M), Singapore (5.8M)…

https://1729.com/how-to-start-a-new-country/

Wrapping Up

Everything that has been laid out here makes sense, on the surface, but the question of scale and timeframe seem the most pertinent. How large will these cloud nations be, and how long will they take to manifest effectively in the world we’re living in now?

If you don’t believe they’ll manifest at all, the question is really of no concern. However if you see the promise, the potential in this concept – the question is vital, as are the implications.

What can you do to prepare for this? How can you contribute to its inception and guide its evolution? I believe it’s by learning everything you can, keeping an open mind, sharing your insights, hopes, and doubts. Participating rather than standing by, pointing out flaws and looking for solutions, and choosing to have hope for the future rather than assuming things will only get worse.

Read the article, and post your thoughts online. Let’s talk.

It’s Users All The Way Down

Sometimes in the process of defining your users, you’ll discover that, much like turtles, there are layers upon layers of them just waiting for their stories to be told.

Background

Joining a company late in 2014 as their new UX professional (and founding member of a growing team) has been an eye opening experience. Not only have I been able to finally practice what I’ve been preaching and learning the last few years, but I’ve been exposed to the healthcare industry – which is entirely new to me. Tons to learn = tons of fun.

Anyone in experience design must carefully consider their users’ goals, circumstances, capabilities and habits. This is one way for us to get out of our own heads and as far into our users’ heads as possible – avoiding the trap of designing for the users we’re most familiar with: ourselves.

Identify the users we’re serving is a great place to start. This sounds simple and it can be – but it can also be a complex puzzle (with all the edge pieces hiding and the corner pieces eaten by your dog.)

What my company does

At a high level, we provide a secure and efficient communication platform for the healthcare industry. The platform helps patients, practice staff and hospital staff efficiently contact physicians.

The problems we solve:

  1. handling the bazillion ways that physicians within a hospital or practice setting need to be contacted depending on situational context.
  2. sending information to a physician in a way that is secure and does not violate laws around the privacy of protected healthcare information (PHI).
  3. maintaining a fine balance between the needs for privacy and accessibility on the part of the physician.

Who are our users?

User (Turtle) #1: Our external users

This group includes doctors, nurses, acute care staff and hospital / practice management. They’re the obvious answer to the ‘who is our user’ question – the system was designed to meet their needs and everything revolves around maintaining and enhancing the capabilities that our platform extends to them.

If we push out a buggy feature or misjudge the utility of an enhancement and sacrifice something more vital, these are the people who feel it the most. We should be in close contact with representative members of this group, testing things out and gathering feedback constantly. This group will (and should!) receive the highest prioritization when it comes to evaluating features, to doing user research and to planning and executing usability testing. That said, don’t stop here!

User (Turtle) #2: Patients

Our healthcare professionals are themselves serving another group of users: their patients at member hospitals and practices across the country. These are the folks that our external users are under oath to care for, and who they went to school for a dozen years to serve.

This is the group who pays the price for inefficient communication practices. It’s the folks who have seen their premiums and deductibles climb year after year and who in too many cases don’t have insurance at all. They pay dearly for any healthcare they receive. This is you and me, when we visit our family doctor or when we land in the emergency room after falling off the roof in an ill-advised attempt to save money on chimney repair.

While we can’t prioritize designing for this group over the others, we should always consider the impact of our decisions on these people.

User (Turtle)#3: Internal Users

We have another group of users not immediately obvious to the naked eye: our internal users. These are the folks that use a suite of applications to onboard new external users and that support their needs on a 24/7 basis, 365 days a year.

They don’t use the exact same set of tools as our external customers, but they’re touching the same data and hitting the same systems. Their needs are also much more diverse since they service every type of external user and must become experts in the task flows for those users. This is no small feat, as the training required for these folks to become proficient runs from a full week to a staggering 3 months.

When considering the needs of this user group, striving to avoid introducing further complexity is a big priority. Beyond that, a large part of your backlog might revolve around taking steps to reduce that complexity even further (and therefore lighten the cognitive load of using the system).

If you’re in this situation, your company’s bottom line could be affected nearly as much by internal facing changes as it is by changes that affect your external users.

User (Turtle) #4: Executive Team

You’d think we had all the bases covered, but there’s actually one more group of users to touch on. Let’s call it the owner/executive team, made up of company ownership and senior leadership in both your external users’ companies and your own organization.

The goals and tasks of this group tend to be pretty straightforward, and sometimes seem pretty far removed from what the other three groups of users are concerned with. That said, while I don’t recommend placing too much weight on designing for this group, I do believe it’s a mistake not to consider their needs. Pulling off a win-win effort that enables this group to hit their goals tends to be a self-reinforcing success for a company.

Wrap Up

If you only take one thing from this article, know that accommodating anything less than every group of users in your designs is a Bad Thing.

Imagine that your executive team has seen the effect that your team’s UX design and development work has had on the bottom line – and so they foster a culture that values and encourages such efforts on an ongoing basis. This belief is folded into the company’s core values, and soon the sales, support and product development teams are all on the same page.

Your external users consistently see improvements, enjoy using your product and feel that their feedback is valued and acted upon. Inevitably these happy professionals pass those benefits on to their own customers . For our patients user group that manifested through cost savings, less time in the waiting room or waiting on a surgery date, and better quality of care.

Your internal users don’t have to jump through hoops to support the customers since the support tools they have been given are performant, intuitive and easy to use.

Wouldn’t that be a beautiful place to work? Are you ready to make it happen?

Thoughts On Proprioceptive Feedback

The literature:
Spatial Updating Of Self-Position And Orientation During Real, Imagined, And Virtual Locomotion (1998)

For efficient navigational search humans require full physical movement but not a rich visual scene.

The research done by Klatzky, Loomis, et al. as well as that of Ruddle and Lessels both indicate that proprioceptive feedback is a crucial factor in our ability to accurately gauge distance, size, heading and rate of movement. While my own experience echoes their findings, the reading left me with a couple questions.

First, what are the differentiating factors that separate those of us with what appears to be a more developed innate sense of direction (or perhaps a more advanced and accurate sense of place) from those who have difficulty with even the most rudimentary way finding operations when removed from familiar environments? Are there biological factors at play, or are the differences primarily acquired through life experience? Can we train to be more receptive to proprioceptive feedback, learn to interpret it more accurately, or are we consigned to our genetically disposed navigational fates, as it were?

Second, what are the implications of this kind of research on purely digital mediums, in which physical feedback is minimal or nonexistent? Are there natural corollaries between physical locomotion or visual perception and our navigation of pages on the web or through various states of an application? Could connections between these modes of ‘navigation’ be yoked more efficiently, enhancing a user’s innate ability to find their way about within a complex application?

What do you think?

Design Constraints Are Awesome

While reading some material recently I was particularly struck by a correlation between the sentiment of “designing for monochrome first” (for color deficient users) and the design movement termed “Mobile First”.

In both cases, the designer aims to build their interface elements such that the largest % possible of users will have accessibility to the data, based on the real and perceived limitations of the environmental factors imposed. After baseline accessibility and usability you can worry about nuances and aesthetics.

Monochromatic vision strips the designer of color-based tools and techniques, forcing you to fallback to the use of shape, contour, contrast and pattern. The Mobile First design sensibility forces the designer to carefully prioritize what elements of the design are truly needed to accomplish the goal(s) of the product, framed within the limits imposed by a smaller display. You also have to consider the contextual differences in usage between a mobile device and a desktop computer, and within the vastly different feature sets of modern devices.

I often hear about project constraints in terms of drawbacks, of obstacles to building the perfect widget. It’s much more helpful to think of constraints as helpful wayfinding elements on the road to successful project definition. If you know what they are, you won’t waste time in rabbit holes and you’ll be able to focus your time and attention on crafting the best product possible – one that will meet the unique needs of your users, whether or not they can see colors and regardless of what they’re using to access your offerings.

Thoughts On Medical Decision Making

Original article by Jerome Groopman

We all fall victim to habitual behaviors, and more so when we are unable to focus sufficient attention on tasks at hand, believing (consciously or unconsciously) that we can accomplish some process or task without conscious thought, instead thinking about ‘more pressing’ matters.

What is more difficult to detect are those biases not based on habit, but instead on other factors. Groopman’s article on medical decision making explored this issue in the light of decisions made every day by physicians in practices and hospitals across the world.

Several types of errors were explored, including Representativeness error (thinking that is overly influenced by what is typically true), Availability error (the tendency to judge likelihood of an event by how easy relevant examples come to mind), confirmation bias error (cognitive cherry picking – confirming what you expect to find by selectively accepting or ignoring information) and affective error (making decisions based on what you wish to be true).

The stories he shared demonstrate how a very skilled and educated doctor can make incredibly dangerous mistakes, due in some cases to the fast-paced world of medicine but in other in reaction to common human urges such as the desire to be merciful and spare a patient embarrassment or further fatiguing tests.

At my workplace we are tasked with making medical industry communication more secure and much more efficient – resulting in better patient care and increased physician and clinician satisfaction. After reading this article and having learned a great deal about how complex the communication needs of a hospital or practice have become, I have to wonder how many mistakes are made due to the very real problems of workflow dissolution and workplace communication breakdowns. How many errors of the classes described by Groopman could be avoided or reduced in severity through more frequent and higher quality peer-to-peer interactions in the medical industry?

GapMinder Data Analysis

In my HCI cognitive science class we’ve been studying visualization and how a given interface can enhance our mental processing power, bringing more of our wits to bear on a challenge. Here’s a look at comparing a few layers of data as reported by two very different nations.

Denmark vs. USA – Charitable giving related to income & life expectancy

I chose to compare the nations of Denmark and the United States, examining their respective records of charitable giving and comparing that to each nations’ income per person and their life expectancy. The data available ran from 1960 to 2008, and so it’s worth noting that the period studied spanned several wars with worldwide impact, numerous financial recessions and a gradual but accelerating trend of climate change.

The United States
The United States in 1960 was quite a charitable one, donating 0.54% of the gross national income (GNI) while only reporting $18,175 in income per person. We had a change of heart it would seem, as the % of GNI given to charity fell steadily for 37 years before finally ending at 0.18% of GNI in 2008.

During this period, while our incomes rose by $24k and our life expectancy by 8 years we gave 0.54% less to charities.

Denmark
Denmark in 1960 was a hard place, donating only 0.09% of their GNI while reporting only $11,569 in income per person. They seem to have buckled down and gotten industrious, as the % of GNI given to charity rose for 21 years to 1.03%, with a high of 1.06% before finally ending at 0.82% of GNI in 2008.

During this period, their incomes rose by $20k and their life expectancy by 6 years. In the end Danes increased their charitable giving by a staggering 0.97% over the period.

Reflections
An interesting measure to add to this comparison would be an index of reported happiness & contentment – does charity or income have a greater effect on happiness?

I would also have enjoyed seeing an overlay of world events across political, economic and climate scopes, relating those factors into the changes in life expectancy, income and charitable giving.

The animation was quite helpful, and illustrated the rate of change between compared parameters over the lengthy collection of data ranging over 48 years, clearly calling out the rapid rise of Denmark’s charity while the USA gave away less and less each year.

It’s purely correlative, but it appears that given the much larger percentage they gave to charity (from their noticeably lower income) the Danish were not overly burdened and lived to nearly the same age. Many factors could have been at play, but I’m given to lean towards the old adage that money CAN bring happiness as long as you spend it on others.

Using Vision To Think (a nod to Stuart Card)

In an HCI class I’m taking currently, we’re studying the cognitive science behind the long human history of visual-spatial displays. We’re talking caveman drawings up to the latest in Minority Report-style virtual interactive displays – fun stuff!!

Here’s an article to soak up if you’re interested in this kind of stuff: The Cognitive Science of Visual-Spatial Displays: Implications for Design

And here’s some thoughts of my own about that article:

More than anything else, this week’s reading of Mary Hegarty’s paper on the science of visual displays made me realize why it’s much easier for visually-minded folks like myself to understand something best when we’re able to interact with a subject on a visual level.

“Representations that are informationally equivalent (contain the same information) are not necessarily computationally equivalent”…
“task performance can be dramatically different with different visual displays of the same information”…

These are dead on. Whenever I’ve encountered a complex problem, whether facing it alone or in a small group (or mentorship, etc.) I often kick off the process or discussion with something along the lines of “Are there other ways I/we can look at the issue?” This is helpful in many cases because in representing the object or process with an iconic, relational or complex display allows us to augment our thinking, to enhance our understanding and to bring additional inferences or insights to bear.

Displays allow us to externalize both the storage and the organization of a massive amount of data, freeing up our fragile and limited minds to process that data in different ways. It also lets us explore the relationships between groupings of related elements, i.e. chunking – freeing us to a degree from the limitations of short term memory by compressing these complex associations or concepts into a fewer number comprehensible objects.

I understand the world through my visualizations of it, both in reality and in my internalized efforts to understand the world around me, so my favorite blurb by far was the author’s reference to Stuart Card’s sentiment “Using vision to think”.

Notes from CodeStock 2014′s “Regular Expressions” presentation

Brian Friesen’s talk on Regular Expressions was probably my favorite of the conference. You gotta admire a guy who builds a regular expression engine to properly demo and train folks up on the ‘devil’s language’ (as I and others I’ve known have called it)… Folks that hate regex and those that live and breathe the stuff all got something from the session. Good stuff.

Regular Expressions – now you have two problems

Brian Friesen
@brianfriesen

Works at Quicken Loans (side note, I used QL last year – hands down the best UX I’ve ever seen in a mortgage product/service)

github.com/QuickenLoans/RegExpose

Regexper.com

Regular-expressions.info

The Bible:
Mastering Regular Expressions by Jeffery Friedl
– can read the first 2/5 of the book and you have enough
———————————————————————–

1. RegEx are hierarchical

Root node = the whole expression

ABC would tree out like this:

ABC – root
A – character literal
B – character literal
C – character literal

2. RegEx do their thing sequentially

A RegEx will match if each of its child nodes matches in sequence
After a match, the RegEx engine will continue trying to find further matches until it has covered the entire string.

RegEx are by default case-sensitive

Character classes are surrounded by square brackets
– for a range, use a dash.
– if you need a dash in the match, put it at the beginning of your set within square brackets
– you can also include specific characters or numbers to match against
– can include a-z and A-Z, or you can pass an additional param to ignore case
– a negated character class = add a “^” carat character before a match. ie [^a-f0-9] would ignore a-f

Shorthand matches
– \d is the same as [0-9]
– \D is the same as [^0-9]
– \s matches whitespace chars
– \w is the same as any word character, meaning [A-Za-z0-9_]
– . matches any character, depending on options (ie except for new line character)

Alternation
(it’s a pipe dream)

| character means “or”
– linos|tigers|bears ‘lions’ would match, but regExp doesn’t know if its the BEST match, so it saves state (a breadcrumb) and moves to check the other choices.
– if a match hits on the last option in a set of choices, no state will be saved, no breadcrumbs etc.

Quantifiers (quantifiers are always AFTER)
(Because sometimes, quantity trumps quality)

Greedy Quantifiers (greedy means quantifier always wants more, ie. will keep going)
——————
– ? = optional
– * = will match zero, will match many
– PO*P would match “PP” as well as “POOP”
– + = must match at least once to succeed
– NO+! would match “NO!” as well as “NOOOOOOOOOOO!”
– {} = match a specific number of things
– \d{3} = this means match exactly 3 digits
– \d{3,15} = this means match at least 3, but up to 15
– \d{3,} = this means match at least 3 with no high end limit

Ultimate lazy quantifier: .*

Causion against using “*.” – can lead to a match failing since the greedy ‘any character as many as possible’ matching could lead to skipping more specific matches after the *.

Lazy Quantifiers – will only match as much as is needed, without going overboard
Once a match is made it will pass control to the next match paramater until it’s needed again…
—————-
.*? = Lazy
{3,5}? = also Lazy (in this case, once 3 digits were matched, the next node in regexp would be matched)

– ab.*?cd would match “abc12345cd” with the lazy quantifier returning to the ‘c’ character repeatedly before going back to the next number character

More alternation
—————-
(?:white|dog|brick) house
– match against “dog house”

Quantifers + grouping
———————
(?:NaN)+
– match against “NaNNaNNaNNaNNaN”

Notes from CodeStock 2014′s “Angular Is Awesome” presentation

Josh walked us through building a simple Angular app, using the lessons learned from Wintellect’s recent dev and launch of a global enterprise software app.

Angular is for AWESOME!
Josh Carroll
@jwcarroll
technofattie.com

The code
github.com/jwcarroll.ng-contacts

directives – typically an attribute on an element
————————————————-
ng-app
ng-init (used to inject a title in his demo)
– ng-init=”contacts=[bob1,bob2,bob3]”
– plugged it in with {{title}}
ng-model
– he bound an input to the ‘title’ var he had leveraged in the injected title
– ng-model=’title’
ng-repeat
-ng-repeat=”contact in contacts”>{{contact}}
ng-search
– “searching by ‘{{search}}'”
ng-if
– truthy comparison results in rendering the stuff
– empty string resolves to 0 so nothing would render

ng-controller – find the controller, and hand off DOM control to the controller by adding ng-controller to an element (ie a containing element)
– ng-controller contactListCtrl as ctrl (do a one time all inclusive effort to make $scope aware of all your controller’s functionality)

ng-view (a new html tag by virtue of angular)
– ala

ng-animate – a way to harness css3 animations

General
pipes (|) are filters. (think gulp)
– takes in something and returns something
– example was var AgeFilter (which returned a function as the filter)

$http as a param passed to function
– this.$http.prop etc.
– _this.$http.get(){
.success(callback) //this is a promise
}
– same for delete, etc

Modules
– used an IFFE function
– a module is a container holding the stuff related to the application

Controllers – just a JS object
$inject = a way to tell NG you need a component (used with $scope)
– $scope being where the data binding happens

Lodash (_. prefix)

Services
– must register a service
– can inject a service into a controller

Routing
– ngRoute (out of the box routing within angular)
– colon (:) is a routing parameter
– as in /contact/:contactId?
– routing as SPA method.. each route can be passed a different controllers (essentially a path-specific template) etc.

Handling when a route fails (ie error handling)
– he made a new js file: routeError.js (again, directive is a new html tag)
– which contained a new directive