UI Therapy | UI Design and Development Podcast

UIT 8: In this weeks episode I start a series on using Sketch to build and maintain efficient and scalable design documents.

Overview

• Share with the audience why the absence.
• Cover important aspects of symbols in Sketch.
• Talk about the future content in this series.

Symbols

Symbols, when used properly, help to vastly speed up your workflow by giving you ways to save and reuse common elements across your designs and design systems. They also form the foundation of Sketch libraries (I will cover this in a future episode of this series).

When you make changes to a Symbol, those changes appear everywhere you use it in your designs. One of the major added benefits of symbols is overrides, which allow you to change specific parts of individual Symbols, without altering the underlying symbol itself.

I cover these symbol subtopics in this episode:

• Organise with good naming conventions
• Nest symbols, and treat them akin to an atomic symbol
• Name the layers inside the symbol with generic names
• Create atom variations at equal sizes
• Learn how to pin the layers that make up your symbols for correct resizing

Pinning

Before you create a symbol, make sure you spend the minute or so necessary to correctly pin, or anchor, all the elements that make up your component. It makes for drastically simpler and less pain when you eventually find you need to resize them. It’s essential practice for things like forms and buttons. Once you understand the benefits you’ll start setting it on everything!

Full show notes available at https://uitherapy.fm/episodes/8

Links

• Great Ormond Street Hospital
• Sketch
• Sketch: Symbols
• Sketch: Smart Layout
• Sketch: Resizing
• Sketch: Fix Size
• Sketch: Pin to Edge

UIT 7: In this weeks episode I share five fundamental tips aimed at developers who want to build their design skills and design appreciation.

Think and plan
As a developer, you wouldn't start building an app or Website without some planning! It's the same for design. Give it the time it deserves.

Establish requirements...

So before jumping straight to the code, establish a plan. I'd suggest downloading and printing out some gridded PDFs, but using sticky notes, a whiteboard, or sketching in a notepad are all great options. Don't skip this step even if you think you have all the details in your head. When you finalize your wireframes, review it and you will probably notice you are missing something.

Develop a solid understanding of UX principles
One of the most important tips I can give is to get a decent understanding of user experience design. If you can always design with the user in mind, and not your own personal preference (because you aren't usually the target audience) then the slightly less important user interface design will be able to absorb some perhaps more quirky design choices. This might seem like common sense, but I've worked with many CEOs, product owners, project managers and developers who don't appreciate the value of good UX, and it shows.

There are a series of ‘laws' associated with UX design, and I'd recommend digesting these over time. Pick one a day and keep it in your mind throughout your work day.

'Laws of UX' defines twenty laws, with a few examples being:

• Aesthetic Usability Effect: Users often perceive aesthetically pleasing design as design that's more usable.
• Fitts's Law: The time to acquire a target is a function of the distance to and size of the target.
• Law of Proximity: Objects that are near, or proximate to each other, tend to be grouped together.
• Law of Similarity: The human eye tends to perceive similar elements in a design as a complete picture, shape, or group, even if those elements are separated.

Use a colour palette
Unless you've studied colour theory, colour harmony doesn't come naturally to most of us. And trying to come up with colour combinations that complement one another during the design process can be a real bottleneck to beautiful aesthetics or at least seriously slow down the process whilst you try to work out if this colours works here and there... As a solid starting point for a new project I'd suggest a tool like Coolors, and check their Trending palettes... which gives you seemingly endless options.

Over time, you'll develop your own preferences and learn to recognise which colours complement each other, but this is a great starting point...

Full show notes available at https://uitherapy.fm/episodes/7

Links

• Laws of UX
• Sneakpeekit
• Free Online Graph Paper
• Gridzzly
• Coolors
• Canva
• Colormind
• Adobe Color
• Designer News
• Codepen
• Dribbble
• Awwwards
• Episode 4

Full show notes available at https://uitherapy.fm/episodes/7

UIT 6: In this week’s episode I talk with Chris Biscardi about the Jamstack, gatsbyJS and his own meta-framework called Toast, amongst many other interesting digressions :)

Overview

• Introduction
• JamStack
• Toast
• Party Corgi
• MDX Conf
• Wrap Questions

Introduction
Got into the industry via ActionScript, then moved over JS when Adobe killed it off. Worked at Docker, Dropbox and recently finished a contract with GatsbyJS.

Talk a bit about the Party Corgi Podcast, and the rainbow corgi logo (which is cute). Chris shares that he has nerves with his podcast too (after I apologies for a few nervous erm/ahhs etc). I’ve left these in unedited because the conversation took a nice direction.

What is the Jamstack
Jamstack and serverless are pretty much the same thing, and are both associated with Build vs Buy Paradigm i.e. if the technology is your core competency then build it, else buy it.

It’s basically the reduction in complexity associated with large devops pipelines i.e. you’re not running a kubernetes or large distributed infrastructure. Instead you’re basically shipping a zip file that’s then deployed on to Amazon S3 or a CDN, and you’re serving a bunch or static files. All the compute necessary to generate your site is done at build time.

A reasonable understanding of where the reduction in complexity ends up; is instead with the developer. One may have removed the need for a server to host a dynamic site with databases etc, but the same functionality has to be achieved at build time in a way that shouldn’t be too complex for the developer.

Full show notes available at https://uitherapy.fm/episodes/6

• Chris Biscardi
• ActionScript
• JAMStack
• Serverless computing
• Build vs Buy Paradigm
• Amazon S3
• Amazon Lambda
• What’s a CDN
• Sapper
• NextJS
• Create React App
• GatsbyJS
• VueJS
• VuePress
• Grunt
• Gulp
• Brunch
• Joel Hooks
• SWC
• ES Build
• Rust
• WASM
• Neon
• Cloudinary
• Styled Components
• Emotion
• HMR
• ...

Full show notes available at https://uitherapy.fm/episodes/6

UIT 5: In this week's episode I share my thoughts on the use of GatsbyJS and whether I feel it's a viable static site generator framework.

What are static sites?
Static sites have been around for a very long time, and realistically are the original website: simply HTML, CSS, and JavaScript. They are not rendered during runtime; there is no server-side code, no database, etc.

What’s a static site generator?
It’s a tool that generates static sites whenever you decide to run a build on your code base.

Contrast this to typical javascript frameworks and libraries, these usually generate HTML content on the client side during runtime.
How is this different from server-side rendering? The primary difference is that there is no server-side code. So, unlike a framework such as Django, Gatsby does not render anything on the server when a request is made. Everything is generated at the build time of the application.
A few benefits of a static site are: speed, the simplest infrastructure, search engine optimization, and security.

GatsbyJS
“Gatsby is a free and open source framework based on React that helps developers build blazing fast websites and apps”

• Built on top of ReactJS
• GraphQL for data
• Uses any source for content; I use MDX (JSX in Markdown)

Pros

• Love React, writing components is a joy.
• Because it’s built on ReactJS has access to a huge ecosystem of packages.
• ...

Full show notes available at https://uitherapy.fm/episodes/5/

Links

• Free Stickers: https://uitherapy.fm/journal/free-stickers/ 
• GatsbyJS: https://www.gatsbyjs.org/ 
• GraphQL: https://graphql.org/ 
• Static web page: https://en.wikipedia.org/wiki/Static_web_page 
• JSX: https://reactjs.org/docs/introducing-jsx.html
• MDX: https://mdxjs.com/
• hopking.io: https://hopking.io/
• Django: https://www.djangoproject.com/ 
• Wagtail CMS: https://wagtail.io/ 
• Django-graphene: https://docs.graphene-python.org/projects/django/en/latest/ 

UIT 4: In this week's episode I share my thoughts on creativity, intuition and introduce the terms 'Qualitative Design' and 'Quantitative Design'.

Overview

• Welcome subscribers
• Introduce #QuickCuppa format
• Talk about the Free Stickers giveaway, open to everyone
• Share thoughts on creativity

Innovation

The following doesn’t necessarily directly apply to UI design, but I think it’s important to keep in mind as I continue through this exploration into creativity.

• Firstly, design can begin with the recognition of societal changes or trends. This involves listening carefully to users’ voices and needs. This can be called ‘demand-driven’ or design.
• Secondly, design can begin with discovery or development in science, technology or the arts. This can be called ‘genesis-driven’ design. Example being a new platform or media type: app design etc.
• Thirdly, design can begin with the generation of a product idea aimed at bridging the gap between demand and genesis.
• These three approaches are not mutually exclusive, and they can and usually are applied in parallel. Both demand and genesis are essential for design, and in actual cases of breakthrough design, the three approaches are often integrated.

Full show notes, including multimedia assets available at https://uitherapy.fm/episodes/4/

Links

• View stickers on Instagram
• Mami Kajiho, my wife and creator of the London themed illustrations
• Design Fixation - A Cognitive Model [PDF]
• History of the graphical user interface
• Thinking outside of the box
• Qualitative research
• Quantitative research
• Think aloud protocol
• Neumorphism in user interfaces

UIT 3: The first two minutes before the episode ‘officially’ starts we talk a bit about why I’m creating this podcast, and then talk about how Fred started on his Pika journey. It’s nice content so I’ve included (note, that the recording quality for Fred during this segment is lower quality.

Fred talks about how he got into programming, and goes on to talk about his time at Google working on Polymer, the native components system for the Web. At this time JS was going through a similar transformation (think ES6 and ES Modules, which is for allowing the browser to import modules), which contrasted to the ES5 way of a single document with hierarchical organisation, was a paradigm shift for JS. Pika began as a way to explore this new technology. The old world of ES5 however did allow for an immediate feedback loop of write/reload/see changes applied (this was lost with NPM and bundlers). ES6 created the opportunity to re-enable this instant feedback loop, and Pika’s focus is to make that happen...

Complete notes at https://uitherapy.fm/episodes/3/

Links

• Fred Schott: https://fredkschott.com/
• FKS on Twitter: https://twitter.com/fredkschott 
• Project Polymer: https://www.polymer-project.org/
• ESM: https://2ality.com/2014/09/es6-modules-final.html 
• What is The Node Way?: https://fredkschott.com/post/2014/12/the-node-way/ 
• Browserify: http://browserify.org/ 
• Webpack: https://webpack.js.org/ 
• 11ty: https://www.11ty.dev/ 
• Parcel: https://parceljs.org/ 
• Snowpack: https://www.snowpack.dev/ 
• Rollup: https://rollupjs.org/
• Svelt: https://svelte.dev/ 
• Drew Powers: https://blog.logrocket.com/snowpack-vs-webpack/ 
• SASS Language: https://sass-lang.com/ 
• Pika: https://www.pika.dev/
• Pika CDN: https://www.pika.dev/cdn
• Pika Code: https://www.pika.dev/code
• Pika Registry: https://www.pika.dev/registry
• Pika CDN package example: https://cdn.pika.dev/react 
• Github Codespaces: https://github.com/features/codespaces/ 
• Component.studio: https://components.studio/
• Webpack Module Federation: https://webpack.js.org/concepts/module-federation/ 
• OS Awards: https://osawards.com/javascript/
• TailwindCSS: https://tailwindcss.com/ 
• ESNEXTCONF: https://www.esnextconf.com/ 
• ES Build: https://github.com/evanw/esbuild 
• SWC: https://github.com/swc-project/swc 

UIT 2: Kingsley talks about how he prototypes games, the current project he and his team is working on (a 3D Platformer game called Frog Island).

He also talks about another side project of his; a procedural games engine to generate worlds.

Kingsley talks about his thesis; ‘Approach for designing complexity in games’ which focuses the UX in games, and how principles from psychology and design theory can be used to teach players about affordances and signifiers. Also explores chunking of complex information (and abstractions), spaced learning techniques and the limitations of the human mind in terms of maximum amount of working memory. We also explore the idea of soft tutorials in games, and how they might be usable within Web or App experiences too.

We talk about his game, Frog Island, where he employs a lot of the ideas from the thesis as a test case. Tracking in-game to find and fix broken aspects of the UX.

Finally we move onto wrap-up questions.

Complete notes at https://uitherapy.fm/episodes/2/

Links

• Frog Island: https://ojaypopedev.itch.io/frog-island
• BeardyKing: https://twitter.com/beardyking
• Frogislandgame: https://twitter.com/frogislandgame 
• Shader Graph: https://unity.com/shader-graph 
• Celia Hodent - The Gamer's Brain: How Neuroscience and UX Can Impact Video Game Design: https://uitherapy.fm/thegamersmind
• Game Maker’s Toolkit: https://twitter.com/gamemakerstk 
• Unity: https://unity.com/ 
• Unreal Engine: https://www.unrealengine.com/
• Frostbite Engine: https://www.ea.com/frostbite
• Cryengine: https://www.cryengine.com/ 

UIT 1: In this first episode I introduce myself, my background and then share what the show’s intended purpose is, who it’s aimed at and why create it. I have a bit of a rant at the JS tooling and package ecosystem. I talk about why I believe that UI designers and developers should be more closely aligned on understanding and appreciation of respective skills and processes etc.

Overview of the episode

• Who’s it for, and what’s it about?
• Why am I creating this?
• Format/Frequency

Who’s it for?

• UI designers
• UI developers
• Anyone interested in machine/human interaction

What’s it about?

• It’s about the technologies, the people, the state of the UI design and development industry.
• UI Therapy name: clarify this (too many frameworks/tooling) it’s a mess and I want to offer help and simplicity here. Barrier to entry in this space. Even for veterans it’s frustrating.
• How will I do this?
• By being opinionated.
• Talking to professionals and experts in their field and sharing their frustrations (so you don’t feel alone).
• Being uncool and suggesting that where we’re headed might benefit from looking at the past.
• Covering tools, frameworks, languages, patterns, methodologies
• Not just the Web. Also about UI (and sometimes UX) in games (upcoming episode interview game designer), smartphones, consoles, apps; basically things with screens.

Why?

There are plenty of podcasts that are aimed at developers/designers in general and there are also shows about the Web, but ones specifically aimed at UI design AND development as a core focus, the pickings are thin at best.

Format/Frequency

• Weekly or bi-monthly
• Plan is for interviews, solo diatribes, 'quick cuppa' for short focused content and 'long brew' episodes, where I share case studies or deep dives into topics, tutorials or reviews etc.

Complete notes at https://uitherapy.fm/episodes/1/