Podcasts about design doc

We're taking a week off to recharge! We'll see you back in two weeks with a new episode of Design Doc. Rest easy. Sincerely, Hannah and Evan Links/Credits: Website: turtlebun.com Patreon: patreon.com/turtlebun Design Doc intro/outro theme by ipaghost: https://www.ipaghost.com/ Episode edited by Rob Abrazado: https://robabrazado.com/ Support Design Doc with a coffee: https://ko-fi.com/designdoc Get in touch: Designdocpod (at) gmail (dot) com Turtlebun Discord: https://discord.gg/XD4WVDjvbz instagram.com/turtleandbun

We're joined by public historian and musical improviser Alanna Shaffer to discuss real-world amusement park horror and Dippin' Dots scams at Dorney Park. Alanna shares thoughts about story vs plot, new character drives, and everyone's personal breaking point after a day with no water. To see Alanna and Thank You, Places in person, check out their monthly improvised musical every last Thursday of the month at Tavern on Camac! Links/Credits: Website: turtlebun.com Patreon: patreon.com/turtlebun Design Doc intro/outro theme by ipaghost: https://www.ipaghost.com/ Episode edited by Rob Abrazado: https://robabrazado.com/ Support Design Doc with a one-time tip: https://ko-fi.com/designdoc Get in touch: Designdocpod (at) gmail (dot) com Turtlebun Discord (we chat about Design Doc here!): https://discord.gg/XD4WVDjvbz instagram.com/turtleandbun

From Mood, Moments, Mechanics, Materials (MMMM) to "Be aware, be charming," our Design Doc conversations over the years have inspired some of our favorite game design ideas. We talk about the ideas that have had a lasting impact on our game design, and how we're incorporating each one into our most recent project. Show notes: Okay, Let's Redesign Noirlandia, for Mood, Moments, Mechanics, Materials Scopeful Optimism, for discussion of scope FLETs, for fiddly little end things Imperfect Inspiration Kudos Conundrum Numbers Hide Everything Founder Energy Fish People, for "Be aware, be charming" High Life (2018 film) Lincoln in the Bardo (2017 George Saunders novel) Links/Credits: Website: turtlebun.com Patreon: patreon.com/turtlebun Design Doc intro/outro theme by Pat King Get in touch: Designdocpod (at) gmail (dot) com Turtlebun Discord: https://discord.gg/XD4WVDjvbz instagram.com/turtleandbun twitter.com/turtleandbun twitter.com/designdocpod

Support the show! On this episode, we have Hannah Schaffer and Evan Rowland, the two creators behind indie game design outfit, turtlebun. They've published games like Questlandia, Noirlandia, Damn the man save the music, Mud: a golem memoir, and many more. You can find more about those games at turtlebun.com. Evan and Hannah also co-host a podcast called Design Doc , which is in their own words, about "trying to make a living as people putting things out in the world". If you read any reviews of that show, you'll hear it being described with words like honest, vulnerable, caring, friendly. It's one of my favourite podcasts in the world and you should listen to it. Then, you can too get vulnerable insights into the daily practice of being a game designer and you can also learn that Carrie Fisher once overtweezed Hannah's mom eyebrows at a workshop. Follow them on Instagram Show Notes: 02:46 Getting started (Evan reinvents microtransactions) 09:07 Going from making big things to making medium-small things 11:30 Getting deep with Design Doc 25:00 What is collaboration and how do you even do it? 36:25 Infections Enthusiasm: The Beast and Usagi Yojimbo 39:40 Tyranny of Numbers 43:46 RePlay 45:33 All Advice Is Advice For Myself Some of my personal greatest hits from Design Doc : Burnout A Cat in the Lap and Other Good Things The Work of Games is Not Just Making Games The Games You Want To Make The Life You Want To Live

This month marks the sixth anniversary of Design Doc, a podcast that started as a "year-long" project documenting our progress redesigning our first roleplaying game. Six years later, we talk about the different directions we've taken, and what Questlandia 2 means to us today. EPISODE LINKS/CREDITS: Our games: turtlebun.com Patreon: patreon.com/turtlebun Turtlebun Twitter: twitter.com/turtleandbun Instagram: instagram.com/turtleandbun Discord: https://discord.gg/XD4WVDjvbz Design Doc intro/outro theme by Pat King Design Doc on twitter: twitter.com/designdocpod

Hannah and Evan discuss their personal experiences and struggles with focus. A new kind of work requires long stretches of sustained focus, disrupting old routines and demanding new strategies. They delve into the challenges and rewards of dodging distractions and shepherding wandering thoughts. Timestamps: 00:55 - Introduction. The need to transition from sprint focus to something more sustained. 10:10 - Our different styles of focus and how we work together: Switching off the role of cheerleader, having a plan and holding to routines; setting boundaries with friends, family, ourselves. 18:17 - Switching to long-form work. Ramping up, getting into a flow, building a slower momentum. 23:51 - External and internal distractions. When the work becomes its own distraction. 32:26 - The dynamic tension, the ongoing battle; eliminating distractions vs the resolve to ignore and power through. Self-esteem. 35:25 - How the switch to long-form focus has helped our work in games. 38:04 - Closing thoughts. What we've learned, the ritual of it. Mentioned in this episode: Deep Work by Cal Newport (We feel "meh" about this one) Stolen Focus by Johann Hari (We liked this one) Links and credits: Design Doc intro/outro theme by Pat King Design Doc twitter: twitter.com/designdocpod Our games: turtlebun.com Patreon: patreon.com/turtlebun Twitter: twitter.com/turtleandbun Instagram: instagram.com/turtleandbun Discord: https://discord.gg/XD4WVDjvbz

On this week's episode, Demetruis digs into what being able to describe your thought process is crucial for user experience.   Resources: Exact Instructions Challenge by Josh Darnit Visibility of System Status by Jeff Doubek What Makes Good Rhythm Game UX? by Design Doc   The Sideboard: The Sideboard is an exclusive weekly Bottom of the Deck segment for Patreon supporters. You can subscribe through Rio's Tip Jar for access to bonus content! Sign up at https://www.patreon.com/demetruis   Asset Credits: Podcast Cover Art - Junel Aceres Music Theme Song - Dominic Mucker via @Dmagic_22   Get in Touch: I'd love your feedback or questions, so feel free to tweet at @drawtwodesign, support me through Ko-Fi, or reach out privately through email!

Neste programa fizemos um bate papo com o time da Syngenta Digital para tratar sobre o assunto Design Docs e RFCs. Design Docs são documentos feitos pelo time ou melhor especialmente pessoas desenvolvedoras cujo objetivo é tornar claro todo o processo de desenvolvimento de uma solução. Além disso, Syngenta compartilhou com nós um pouco do seu trabalho no agronegócio. Assuntos abordados no tema Sobre a Syngenta Digital - história e introdução  Design DOCs e RFCs (Requests For Comments): O que são e para que usar?  Como criar um Design DOC eficaz? As tendências do Design DOCs e RFCs – O que está vindo de novas ferramentas e métodos para garantir uma colaboração eficaz e boas decisões? Experiência na Syngenta Digital (ou pessoal do convidado), como utilizam essas  ferramentas para tomar decisões de projeto – citar exemplos bem sucedidos. Momento polêmico: Como lidar com conflitos e divergências de opinião no Processo de Design DOCs? Como fazer para que as sugestões e comentários sejam considerados e implementados sendo aceitos por todos?  Principais pontos sobre como os Design DOCs e RFCs podem ser usados para melhorar a colaboração e a tomada de decisão nos projetos. Links úteis Mentoria Tech - https://site-mentoria-tech.vercel.app/ https://blog.pragmaticengineer.com/rfcs-and-design-docs/ https://eltonminetto.dev/post/2021-05-15-rfc/ Design Docs Google  https://www.industrialempathy.com/posts/design-docs-at-google/ https://www.youtube.com/watch?v=8IXLpoN8Xj0 https://4linux.com.br/o-que-e-postgis/ https://syngentadigital.ag/ https://www.linkedin.com/company/syngenta/ Participantes Jéssica Nathany (Programadora  e  host)LinkedIn: https://www.linkedin.com/in/jessica-nathany-carvalho-freitas-38260868/ Weslley Fratini (Software Developer e co-host)LinkedIn: https://www.linkedin.com/in/weslley-fratini/ Fernanda Silva (Software Engineer na Syngenta)Linkedin: https://www.linkedin.com/in/fernanda-a-r-silva-32194bb8/) Editado por: AGO Filmes https://thiagocarvalhofotografia.wordpress.com/ dúvidas, sugestões ou  publicidade envie para: debugcafe@gmail.comApoia.se: https://apoia.se/cafedebugSee omnystudio.com/listener for privacy information.

Hannah and Evan talk about the increasingly complicated logistics of packing and shipping games as small creators. In this episode, we talk all about packing and shipping. Where do you get bubble wrap when you need more than a roll, but less than a warehouse's-worth? What happens when a printer you've worked with for years really messes up, with no chance to fix it? All this and more in part 1, with part 2 to come. Episode Links and Credits The sticker makers we work with: https://stickerninja.com/ Design Doc intro/outro theme by Pat King Design Doc on twitter: twitter.com/designdocpod Turtlebun links Questlandia 2nd Edition: turtlebun.com/products/questlandia Our other games: turtlebun.com Patreon: patreon.com/turtlebun Twitter: twitter.com/turtleandbun Instagram: instagram.com/turtleandbun Discord: https://discord.gg/XD4WVDjvbz

We made the games, now we have to sell them. Hannah and Evan talk about something they're good at: making new games. And something they're bad at: confidently sharing those games with an audience that might like them. Design Doc intro/outro theme by Pat King Design Doc on twitter: twitter.com/designdocpod Turtlebun links Questlandia 2nd Edition: turtlebun.com/products/questlandia Our other games: turtlebun.com Patreon: patreon.com/turtlebun Twitter: twitter.com/turtleandbun Instagram: instagram.com/turtleandbun Discord: https://discord.gg/XD4WVDjvbz

Hannah and Evan discuss how to repair their relationship with a game they've spent a year struggling to complete. Design Doc intro/outro theme by Pat King Design Doc on twitter: twitter.com/designdocpod Mentioned in this episode: Microscope RPG by Ben Robbins. Turtlebun links Our games: turtlebun.com Patreon: patreon.com/turtlebun Twitter: twitter.com/turtleandbun Instagram: instagram.com/turtleandbun Discord: https://discord.gg/XD4WVDjvbz

Listen to the Design Doc episode that inspired this one at https://oneshotpodcast.com/design-doc/48-bad-lo-fi-game-ideas-to-study-or-relax-to/Maybe see some of these game ideas eventually at http://dannymakesrpgs.itch.io!

Hannah and Evan talk about the fiddly little end things that make a project go on, and on, and on much longer than you expected. Design Doc intro/outro theme by Pat King Design Doc on twitter: twitter.com/designdocpod Turtlebun links Our games: turtlebun.com Patreon: patreon.com/turtlebun Twitter: twitter.com/turtleandbun Instagram: instagram.com/turtleandbun Discord: https://discord.gg/XD4WVDjvbz

Hannah and Evan talk about the fiddly little end things that make a project go on, and on, and on much longer than you expected.Design Doc intro/outro theme: by Pat King

Well...technically, Hearthside Chats, if I'm being honest. It took so long since Hannah (@hanbandit) and I had our first interview that I had to ask her to come back on the show for an update! Make sure you check out Hannah and her design partner Evan Rowland's (@adrawnnovel) wonderfully weird games over on their website, https://turtlebun.com/ and on their itch page, https://turtlebun.itch.io/ and support them directly via Patreon at https://www.patreon.com/turtlebun. Oh, and they're also fantastic podcasters so make sure you give a listen to Design Doc which is part of the ONE SHOT Podcast Network (http://oneshotpodcast.com/interview-discussion/design-doc/.) Lastly, if you want to know what the hell we're talking about re: The Minds Eye videos, look no further: https://www.youtube.com/watch?v=cmE4IWPaULE I think that's all the links I mentioned...if I forgot anything, yell at me on Twitter! If you want to support the Pod of Blunders and help ensure we can keep bringing you interviews and actual plays, please head to www.patreon.com/podofblunders to learn what your $1/$5/$10 pledge will get you. (Hint: access to our fantastically active discord, exclusive episodes of Jumping the Street Sharks, free games, etc.) You can also support us by leaving a review on Apple Podcasts. Reviews help us reach larger audiences so we can tell more people about the amazing indie games we play and the fantastic folks that create them. Also, a special thanks to Rolemusic for our intro and outro tune taken from the track Pokimonkey! If you enjoy the tune, check out more of Rolemusic's work here https://freemusicarchive.org/music/Rolemusic or learn about the artist here http://rolemusic.sawsquarenoise.com/ As always, if you have any questions or comments, let us know @podofblunders on Twitter or podofblunders@gmail.com. We truly love hearing from you! --- This episode is sponsored by · Anchor: The easiest way to make a podcast. https://anchor.fm/app

Charlie habla personalmente y no representando a Google de ninguna manera. Charlie: @charliesbot | Los Fullstackers: @losfullstackers Charlie trabaja como software engineer en Google en el equipo de Youtube. Aprendí que resolver el problema que tienes enfrente es la misión; no comenzar con la solución o la tecnología sin antes comprender el problema a fondo. Para esto, debemos poder adaptarnos a lo que el problema nos requiere. No importa el lenguaje de programación o la tecnología que estás usando siempre y cuando resuelvas problema (puntos extra si lo haces estar y seguro!). 1. Buenas prácticas en Google que recomienda aplicar Charlie: La más importante: la planeación. Antes de comenzar a programar hay que documentar. Podemos usar un formato de Design Doc (en Google, el buscador, se encuentran muchos templates y consejos para desarrollar uno). Parte del objetivo del Design Doc es identificar lo que vamos a programar y los posibles bloqueos. ANTES DE ESCRIBIR CÓDIGO, PLANEAR. Comparte el Doc con tus compañeros para revelar si algo se te está escapando. Es tan importante que puede ocupar el 60-70% de tu tiempo. Ahórrate el sufrimiento. Comunicación. Determina con tu manager cuáles son las prioridades. Si te sientes agobiado, coméntalo. Puedes pedir ayuda o priorizar. Comunica a tiempo, no un día antes del deadline. Adaptabilidad, de las favoritas de Charlie. Consejo de una manager de Charlie: Qué es un software engineer? Es la persona que resuelve problemas, no importan los lenguajes de programación. Esos los aprendes. La habilidad de adaptarte para resolver el problema que enfrentas es clave. 'Problema que llegue, problema que resuelves'. Importante: entre más conozcas, más puedes adaptarte. 2. Otros temas tocados Rust. Es un lenguaje de bajo nivel. No es recomendable para principiantes (Python podría ser más adecuado). Si ya entiendes los fundamentos de la programación (ya la amas) Rust puede llegar a ser muy potente. Nota: hay interoperabilidad con C++. Quizás para lo que tú buscas Rust no sea la solución, pero quizás sí... adaptabilidad. La web3 interesa a Charlie. Nuestro tercer invitado seguido que tiene como interés secundario la web3. También le interesa Remix (nuevo framework que compite con next.js) y Vite (alternativa a webpack). No compares tu progreso con el de los demás, no conoces su contexto; mejor compararse con tu yo de hace un mes. Si no logras resolver algo no te preocupes, calma. Va a salir eventualmente. Pocas cosas son irreversibles en el trabajo. Toma tiempo libre en el trabajo. Descansa. Tu estabilidad mental es clave. Evalúa seriamente si estás en un estado de depresión, es más común de lo que crees. Tener la mitad de los días malos y la mitad buenos es un estado depresivo. Prueba cosas como ir a un psicólogo o meditar. Identifica si la pelota está en tu campo. Eres tú el que debe hacer el siguiente movimiento o es otra persona? No te estreses por problemas que tú no puedes resolver. No todo es programación. Aprende nuevas herramientas o habilidades, eso ampliará tu perspectiva al ver los problemas, te da más creatividad. Ten puntos de vista diferentes. Siempre ten un segundo lado que contribuya con la persona que quieres ser. Eres capaz de todo, lo único que te limita está en tu mente. La adaptabilidad significa que problema que llegue, problema que buscas resolver así no tengas conocimiento. Adáptate a los problemas. Adecúate a los cambios.

Grab a cup of Earl Grey and kick back with us as we explore various extra materials from the Question Arcs. Featuring segments such as Anna's Music Box, Matt's Design Doc, and Izzy's Oh God Izzy Oh God Oh No Oh Man Oh God.   Show Notes Bonus Materials Reading Order 07thExpansion Wiki Bonus Materials Page Chronological Umineko Soundtrack Playlist Anna's Top 10(ish) Songs Playlist system0 With Star Trek Sample   Hosted by Jennifer Booher (@kebbbbs) Featuring Annabelle Barsky, Caelum O'Leary-Coderre (@hivehum) Isabelle Valant (@IzzyTimeStream), and Matthew Winter (@ImYourPaperPal) Produced by Annabelle Barsky and Jennifer Booher Cover art by Grace Hobson (@_GwenGrace_) Fishy Aroma by Luck Ganriki Haruka (Distant) by pre-holder

Dr. Vickie VanHurley, The Design Doc, branding consultant, packaging expert, artist, educator, author, and conference speaker, discusses the wide array of her experience in the creative and educational fields, and the print industry's role in fostering the next generation of professionals. Links Mentioned in Today's Episode: Dr. Vickie VanHurley on LinkedIn: https://www.linkedin.com/in/drvickievanhurley Bootstrap Branding: https://www.amazon.com/Bootstrap-Branding-Entrepreneurs-Building-Finances/dp/0692662448 Dr. Vickie VanHurley Website: https://drvlvanhurley.carrd.co/

Pull Up for "Chat with The Historian'' with Host Barbara Chandler and DeLand Community Historian, Mike Brown.  Mike will share the African American history of DeLand and what visitors will experience while touring the African American Museum of the Arts. https://www.africanmuseumdeland.org/  Our Community Spotlight features Dr. Felicia Benzo, Founder of the Catalyst Global Youth Initiatives, Inc., Volusia County Black History Honoree 2021. Dr. Benzo joins us and discusses why she started Catalyst mentoring and shares  success stories that the organization is having while fostering positive and healthy interactions within the community! https://mentoringforgreatness.org/Dr. Vicki Van Hurley is in the seat, as the Artist Spotlight with Andrew Browne of Browne Box Creative Solutions! Vicki Van Hurley is an artist, Branding Coach, and Adjunct Professor; you will hear her personal story of how she became known as the The Design Doc! https://www.thedesigndoc1.com/This week LaVonda Wilder, Founder of Eatonville Chamber of Commerce, Business Spotlight features a match up between John and Albert Richards of  Posh Rock Tennis Foundation! The Richards are committed to working with inner city youths and teaching the fundamentals of playing tennis which promotes a healthy and positive self-esteem in children. http://poshrockfoundation.org/

We sit down for an unplanned recording of Design Doc when Evan says something sad.Note: This episode discusses the toll that work can take on physical and mental health.End of episode donation notes:The Okra Project - https://www.theokraproject.com/Black Mental Health Alliance - https://blackmentalhealth.com/Bail Fund List - https://bailfunds.github.io/Music:Design Doc  Intro/Outro theme by Pat KingNew Ages I by Little Dog Big Ears 

Storyboard artist Sarah Huisken joins the club this week to talk about NDAs (non-disclosure agreements) and the factors that make games as deliciously "replayable" as Mass Effect 2. Also, Stephen sort of gets the final word, Mark does a transition (!), and Ellen is slow to get the joke. Sarah Huisken's website - Sarah HuiskenSarah's Twitter handle is @BoringHeathen - Sarah HuiskenEverything Sony Announced in Today's PS5 Event - Chris Kohler , KotakuWays you can help support efforts for racial justice in the U.S.Bundle for Racial Justice and Equality raised $8.1 million! NDAs 0:19:20 Mark LaCroixMarketingA Conspiracy of Silence: How NDAs Are Harming The Games Industry - Rick Lane, Kotaku Replayability 0:47:15 Ellen Burns-JohnsonGame DesignWhat Makes a Game Replayable? - Design Doc, YouTube

Storyboard artist Sarah Huisken joins the club this week to talk about NDAs (non-disclosure agreements) and the factors that make games as deliciously "replayable" as Mass Effect 2. Also, Stephen sort of gets the final word, Mark does a transition (!), and Ellen is slow to get the joke.  Sarah Huisken's website - Sarah Huisken Sarah's Twitter handle is @BoringHeathen - Sarah Huisken Everything Sony Announced in Today's PS5 Event - Chris Kohler , Kotaku Ways you can help support efforts for racial justice in the U.S. Bundle for Racial Justice and Equality raised $8.1 million! NDAs 0:19:20 Mark LaCroix Category Marketing A Conspiracy of Silence: How NDAs Are Harming The Games Industry - Rick Lane , Kotaku Replayability 0:47:15 Ellen Burns-Johnson Category Game Design What Makes a Game Replayable? - Design Doc , YouTube

The Design Doc is in the building! Dr. VanHurley is an accomplished professor, teacher, designer, artist, author, and packaging professional. She drops some knowledge on her past along with some trends she is seeing going forward. You can purchase her book "Bootstrap Branding" here - https://www.amazon.com/Bootstrap-Branding-Entrepreneurs-Building-Finances/dp/0692662448 Connect with her on LinkedIn - https://www.linkedin.com/in/drvickievanhurley/ You can connect with Adam Peek on LinkedIn - www.linkedin.com/in/adampeek If you want to listen to the podcast search for People of Packaging Podcast anywhere you listen to podcasts. Or online - https://wavve.link/peopleofpackaging/episodes

Its purpose, the act of creation. Its destiny, unknowable. Today's episode is about a bike on skis.Design Doc intro theme by Pat King.Intermission and outro music, New Ages I by Little Dog Big Ears.

In this episode of the Design Doc, host Brad Cypert (bradcypert.com) sits down with Osa Gaius of ParrotMob to talk about functional programming, elixir and building ParrotMob. Show Notes: 1. Elixir 2. Clojure 3. Rich Hickey Talks 4. Phoenix (Elixir Framework) 5. Clojure for the Brave and True (Daniel Higginbotham) --- Send in a voice message: https://anchor.fm/design-doc/message

In this episode of the Design Doc, your host Brad Cypert sits down with Ethan Miller to talk about landing his first real dev job. We cover how Ethan got into development, what his code boot camp experience was like, and more. If you've ever wondered if a code boot camp is right for you, this is the episode for you. --- Send in a voice message: https://anchor.fm/design-doc/message

In this episode, guest Shane Burkhart talks with host Brad Cypert about how he learns new technology and keeps up with the changes in the software landscape. We also talk a bit about react, the JVM, Hacker News, Dev.to, and much more. Tune in to find out. Show Notes React TypeScript GraphQL GoLang Clojure Kotlin Scala HackerNews Dev.to As always, you can find Design Doc anywhere podcasts are heard. You can find more of Shane on Twitter, Github, or his website. As for your host, you can find him the same ways: Twitter, Github, personal website. --- Send in a voice message: https://anchor.fm/design-doc/message

In the final part of our Questlandia 2 series, we discuss the process of worldbuilding, talk about designing a game made for campaigns, and chat about how our lives influence our art in our discussion episode with Hannah Shaffer and Evan Rowland, designers of the game and hosts of the Design Doc podcast, also part of the One Shot Podcast Network!Leave us reviews in any, or all, of these places:Character Creation Cast on Apple Podcasts (The best place to leave reviews for us)https://itunes.apple.com/us/podcast/character-creation-cast/id1363822066?mt=2&ls=1Character Creation Cast on Podchaserhttps://podchaser.com/CharacterCreationCastCharacter Creation Cast on Stitcherhttps://www.stitcher.com/podcast/character-creation-cast?refid=stprCharacter Creation Cast on Facebookhttps://facebook.com/CharacterCreationCastGuests and Projects:Hannah Shaffer @hanbanditTwitter: https://twitter.com/hanbanditPatreon: https://patreon.com/hanbanditEvan Rowland @adrawnnovelTwitter: https://twitter.com/adrawnnovelWebsite: http://smallflygames.com/Make Big Things @makebigthingsTwitter: https://twitter.com/makebigthingsWebsite: http://makebigthings.com/Design Doc @designdocpodTwitter: https://twitter.com/designdocpodWebsite: http://oneshotpodcast.com/interview-discussion/design-doc/Timestamps:00:00:21 - Intro00:00:46 - Hannah’s Character00:01:30 - Evan’s Character00:02:18 - Amelia’s Character00:02:51 - Ryan’s Character00:03:42 - D20 for your thoughts00:04:05 - Evan’s start in games00:05:11 - Hannah’s start in games00:08:02 - What do you like about collaborative worldbuilding?00:11:49 - Why make a GMless game?00:13:31 - Why is randomness still important?00:16:31 - What does character creation tell us about the game?00:19:44 - Why do we know so little about our ghosts?00:26:39 - What are the flaws and what are you proudest of?00:29:07 - Figuring out how to pitch the game00:29:57 - The character sheet00:33:49 - Changes from Questlandia 1 to Questlandia 200:36:15 - How real life influences design00:40:41 - FAN FIC!00:49:48 - Take it up a level00:52:10 - How does advancement work?00:56:08 - Making a campaign vs. a one shot01:01:42 - Plugs!01:04:13 - Closer01:04:40 - Show blurbs: Arms of the Tide01:06:33 - OuttakesTranscriptshttps://charactercreationcast.simplecast.com/episodes/series-223-questlandia-2-with-hannah-shaffer-and-evan-rowland-designers-discussion/transcriptMusic:Opening: Meditation Impromptu 03 (http://freemusicarchive.org/music/Kevin_MacLeod/Calming/Meditation_Impromptu_03) by Kevin MacLeod (http://incompetech.com)Clip 1: Music from https://filmmusic.io "With a Creation" by Kevin MacLeod (https://incompetech.com) License: CC BY (http://creativecommons.org/licenses/by/4.0/)Clip 2: Design Doc Intro/outro theme by Pat King (https://www.woodpenny.com)Main Theme: Hero (Remix) (http://freemusicarchive.org/music/Steve_Combs/Principal_Photography_1493/11_Hero_Remix) by Steve Combs (http://freemusicarchive.org/music/Steve_Combs/)Games discussed this episode:QuestlandiaWebpage: http://makebigthings.com/questlandia-rpg/Questlandia 2Itch.io: https://makebigthings.itch.io/questlandia-2 at https://makebigthings.itch.io/Our Podcast:Character Creation Cast:Twitter: @CreationCast (https://twitter.com/CreationCast)Facebook: https://facebook.com/charactercreationcast/Discord: http://discord.charactercreationcast.com/Instagram: https://www.instagram.com/creationcast/Podchaser: https://www.podchaser.com/CharacterCreationCastAmelia Antrim:Twitter: @gingerreckoning (https://twitter.com/gingerreckoning)Website: https://ameliaantrim.wordpress.com/Garbage of the Five Rings podcast: (http://garbageofthefiverings.com/)G5R Twitter: @G5Rpodcast (https://twitter.com/G5Rpodcast)Ryan Boelter:Twitter: @lordneptune (https://twitter.com/lordneptune)Website: https://lordneptune.comChimera RPG: @ChimeraRPG (https://twitter.com/ChimeraRPG)Side Heroes: @SideHeroesPod (https://twitter.com/SideHeroesPod)Patreon: https://patreon.com/RyanBoelterItch.io: https://lordneptune.itch.ioOur Website:http://www.charactercreationcast.comOur Network:http://oneshotpodcast.comNetwork Patreon:https://www.patreon.com/oneshotpodcast

Welcome to the second episode of series 22, everyone! This episode we actually play a little bit of Questlandia 2 and create a world with Hannah Shaffer and Evan Rowland, designers of the game and hosts of the Design Doc podcast, also part of the One Shot Podcast Network!Leave us reviews in any, or all, of these places:Character Creation Cast on Apple Podcasts (The best place to leave reviews for us)https://itunes.apple.com/us/podcast/character-creation-cast/id1363822066?mt=2&ls=1Character Creation Cast on Podchaserhttps://podchaser.com/CharacterCreationCastCharacter Creation Cast on Stitcherhttps://www.stitcher.com/podcast/character-creation-cast?refid=stprCharacter Creation Cast on Facebookhttps://facebook.com/CharacterCreationCastGuests and Projects:Hannah Shaffer @hanbanditTwitter: https://twitter.com/hanbanditPatreon: https://patreon.com/hanbanditEvan Rowland @adrawnnovelTwitter: https://twitter.com/adrawnnovelWebsite: http://smallflygames.com/Make Big Things @makebigthingsTwitter: https://twitter.com/makebigthingsWebsite: http://makebigthings.com/Design Doc @designdocpodTwitter: https://twitter.com/designdocpodWebsite: http://oneshotpodcast.com/interview-discussion/design-doc/Timestamps:00:00:00 - Announcements00:01:10 - Recap00:02:09 - Let’s make a place00:03:40 - The moon phase00:05:13 - Introduce an element - NPC00:10:58 - Introducing a location00:13:25 - Introducing an aspect of the setting00:23:11 - Rolling for a trouble00:43:19 - Phase changes00:50:18 - Episode Closer00:54:06 - Show Blurbs (All My Fantasy Children)Transcriptshttps://charactercreationcast.simplecast.com/episodes/series-222-questlandia-2-with-hannah-shaffer-and-evan-rowland-designers-creation-continued/transcriptMusic:Opening: Meditation Impromptu 03 (http://freemusicarchive.org/music/Kevin_MacLeod/Calming/Meditation_Impromptu_03) by Kevin MacLeod (http://incompetech.com)Clip 1: Music from https://filmmusic.io "With a Creation" by Kevin MacLeod (https://incompetech.com) License: CC BY (http://creativecommons.org/licenses/by/4.0/)Clip 2: Design Doc Intro/outro theme by Pat King (https://www.woodpenny.com)Main Theme: Hero (Remix) (http://freemusicarchive.org/music/Steve_Combs/Principal_Photography_1493/11_Hero_Remix) by Steve Combs (http://freemusicarchive.org/music/Steve_Combs/)Games discussed this episode:QuestlandiaWebpage: http://makebigthings.com/questlandia-rpg/Questlandia 2Itch.io: https://makebigthings.itch.io/questlandia-2 at https://makebigthings.itch.io/Our Podcast:Character Creation Cast:Twitter: @CreationCast (https://twitter.com/CreationCast)Facebook: https://facebook.com/charactercreationcast/Discord: http://discord.charactercreationcast.com/Instagram: https://www.instagram.com/creationcast/Podchaser: https://www.podchaser.com/CharacterCreationCastAmelia Antrim:Twitter: @gingerreckoning (https://twitter.com/gingerreckoning)Website: https://ameliaantrim.wordpress.com/Garbage of the Five Rings podcast: (http://garbageofthefiverings.com/)G5R Twitter: @G5Rpodcast (https://twitter.com/G5Rpodcast)Ryan Boelter:Twitter: @lordneptune (https://twitter.com/lordneptune)Website: https://lordneptune.comChimera RPG: @ChimeraRPG (https://twitter.com/ChimeraRPG)Side Heroes: @SideHeroesPod (https://twitter.com/SideHeroesPod)Patreon: https://patreon.com/RyanBoelterItch.io: https://lordneptune.itch.ioOur Website:http://www.charactercreationcast.comOur Network:http://oneshotpodcast.comNetwork Patreon:https://www.patreon.com/oneshotpodcast

Welcome to the first episode of series 22, everyone! This episode we cover character creation for Questlandia 2, get into some great discussion about game design and collaboration, and stumble into a really flattering design decision with Hannah Shaffer and Evan Rowland, designers of the game and hosts of the Design Doc podcast, also part of the One Shot Podcast Network!Leave us reviews in any, or all, of these places:Character Creation Cast on Apple Podcasts (The best place to leave reviews for us)https://itunes.apple.com/us/podcast/character-creation-cast/id1363822066?mt=2&ls=1Character Creation Cast on Podchaserhttps://podchaser.com/CharacterCreationCastCharacter Creation Cast on Stitcherhttps://www.stitcher.com/podcast/character-creation-cast?refid=stprCharacter Creation Cast on Facebookhttps://facebook.com/CharacterCreationCastGuests and Projects:Hannah Shaffer @hanbanditTwitter: https://twitter.com/hanbanditPatreon: https://patreon.com/hanbanditEvan Rowland @adrawnnovelTwitter: https://twitter.com/adrawnnovelWebsite: http://smallflygames.com/Make Big Things @makebigthingsTwitter: https://twitter.com/makebigthingsWebsite: http://makebigthings.com/Design Doc @designdocpodTwitter: https://twitter.com/designdocpodWebsite: http://oneshotpodcast.com/interview-discussion/design-doc/Timestamps:00:00:00 - Announcements00:02:38 - Introductions00:05:00 - What’s in a game?00:07:37 - What do we need to play this game?00:10:44 - Is there a reason to go with custom materials?00:15:38 - What sort of stories and themes does this game explore?00:22:44 - The history of Questlandia00:28:07 - How is it collaborating vs not?00:33:31 - Playtesting00:40:53 - Terms and Concepts00:43:16 - Let’s make some people!00:56:41 - Our Choices01:00:02 - Episode Closer01:01:57 - Show Blurbs (Session Zero)Transcriptshttps://charactercreationcast.simplecast.com/episodes/series-221-questlandia-2-with-hannah-shaffer-and-evan-rowland-designers-creation/transcriptMusic:Opening: Meditation Impromptu 03 (http://freemusicarchive.org/music/Kevin_MacLeod/Calming/Meditation_Impromptu_03) by Kevin MacLeod (http://incompetech.com)Clip 1: Music from https://filmmusic.io "With a Creation" by Kevin MacLeod (https://incompetech.com) License: CC BY (http://creativecommons.org/licenses/by/4.0/)Clip 2: Design Doc Intro/outro theme by Pat King (https://www.woodpenny.com)Main Theme: Hero (Remix) (http://freemusicarchive.org/music/Steve_Combs/Principal_Photography_1493/11_Hero_Remix) by Steve Combs (http://freemusicarchive.org/music/Steve_Combs/)Games discussed this episode:QuestlandiaWebpage: http://makebigthings.com/questlandia-rpg/Questlandia 2Itch.io: Coming Soon at https://makebigthings.itch.io/Our Podcast:Character Creation Cast:Twitter: @CreationCast (https://twitter.com/CreationCast)Facebook: https://facebook.com/charactercreationcast/Discord: http://discord.charactercreationcast.com/Instagram: https://www.instagram.com/creationcast/Podchaser: https://www.podchaser.com/CharacterCreationCastAmelia Antrim:Twitter: @gingerreckoning (https://twitter.com/gingerreckoning)Website: https://ameliaantrim.wordpress.com/Garbage of the Five Rings podcast: (http://garbageofthefiverings.com/)G5R Twitter: @G5Rpodcast (https://twitter.com/G5Rpodcast)Ryan Boelter:Twitter: @lordneptune (https://twitter.com/lordneptune)Website: https://lordneptune.comChimera RPG: @ChimeraRPG (https://twitter.com/ChimeraRPG)Side Heroes: @SideHeroesPod (https://twitter.com/SideHeroesPod)Patreon: https://patreon.com/RyanBoelterItch.io: https://lordneptune.itch.ioOur Website:http://www.charactercreationcast.comOur Network:http://oneshotpodcast.comNetwork Patreon:https://www.patreon.com/oneshotpodcast

This episode discusses the very exciting 1st stages of building your application and getting your idea out there. --- Send in a voice message: https://anchor.fm/bakari-finley/message

Questlandia 2 has been delayed. Now, we're releasing an entirely different RPG first. We talk about—and try not to apologize for—how timelines and business have to adapt to design difficulties. Design Doc intro/outro theme: by Pat King

In this short episode, Brad Cypert talks about launching the design doc podcast. We'll cover why the podcast was launched, what you can expect from it going forward and how often we're hoping to publish a show. --- Send in a voice message: https://anchor.fm/design-doc/message

Hello my beautiful Mario and Luigi makers! Super Mario Maker 2 is out this week so let’s chat! Takashi Tezuka has given us some pearls of info to muse on. Galen and Oni have a running argument on autorunner levels. The gang also discusses what Nintendo does with the future of Mario 2D side-scroller platformers as stand alone titles. Oni thinks they need to go a totally new direction, and he has THE BEST ideas. Nintendo, please check these out. They’re free. Oni and Galen have basically acted as creative producer on this and workshopped ‘em. Oni and Galen then blab on about some new info on an upgraded Switch model, and consider things not only from a consumer standpoint, but from a developer’s burden point of view, as well. We muse on the big questions like, “Is the inevitable Switch model going to be a small bump or a huge leap so it can at least hold its own against the PS5 and Xbox Scarlett?” Galen brings up marketing and aiming at different markets, while Oni fights back with discussions of the slippery slope effect that the Switch could lose 3rd party support. If you’d like to support our show, you can help out by sharing the show with someone who hasn’t heard of us before, and by rating us 5 stars on iTunes! We really appreciate all your support an thank you so much for listening! Timestamps: 02:42 – Adventure Log: Mario games in local co-op! 10:14 – Super Mario Maker 2 launches, exciting levels already created, Takashi Tezuka reveals a bunch on the development behind the game, influenced by fan creations. What’s next for Mario mainline games in the future? 2.5D, Mario Vehicles, Mariovania, Mario Tactics RPG? 33:01 – Switch hardware revision talk resurfaces. Switch Mini, Switch Pro? Switch Boy, Switch Girl? Overclocking GPU, CPU and RAM in hacked Switches. What Oni and Galen want. 3rd party support slippery slope. 54:15 – Additional DLC 56:55 – Listener Mail: Favorites from E3 – Super Crush KO and Luigi’s Mansion 3 Additional DLC: Inventory UX Design by Design Doc https://youtu.be/5_3BUU9ZmNo James Veitch – Comedian https://www.youtube.com/watch?v=f5d8pVg3Qtg Send us an email and we’ll discuss it! NintendoEverythingPod [at] gmail [dot] com #nintendopodcast #gamingpodcast #podcast

What is a Design Doc - Software Engineering Best Practice #1  

As a software engineer, it's your responsibility to write a good design doc so that your team knows how to solve the problem you're addressing. But what makes a design doc good, what should you include, and how should you write it? Angela shares all her tips so you can make your design docs as effective and helpful as possible. Written by Angela Zhang: https://twitter.com/zhangelaz Read by Abbey Rennemeyer: https://twitter.com/abbeyrenn Original article: https://fcc.im/2vAL4io Learn to code for free at: https://www.freecodecamp.org Intro music by Vangough: https://fcc.im/2APOG02 Transcript: As a software engineer, I spend a lot of time reading and writing design documents. After having gone through hundreds of these docs, I’ve seen first hand a strong correlation between good design docs and the ultimate success of the project. This article is my attempt at describing what makes a design document great. The article is split into 4 sections: Why write a design document What to include in a design document How to write it The process around it Why write a design document? A design doc — also known as a technical spec — is a description of how you plan to solve a problem. There are lots of writings already on why it’s important to write a design doc before diving into coding. So all I’ll say here is: A design doc is the most useful tool for making sure the right work gets done. The main goal of a design doc is to make you more effective by forcing you to think through the design and gather feedback from others. People often think the point of a design doc is to to teach others about some system or serve as documentation later on. While those can be beneficial side effects, they are not the goal in and of themselves. As a general rule of thumb, if you are working on a project that might take 1 engineer-month or more, you should write a design doc. But don’t stop there — a lot of smaller projects could benefit from a mini design doc too. Great! If you are still reading, you believe in the importance of design docs. However, different engineering teams, and even engineers within the same team, often write design docs very differently. So let’s talk about the content, style, and process of a good design doc. What to include in a design doc? A design doc describes the solution to a problem. Since the nature of each problem is different, naturally you’d want to structure your design doc differently. To start, the following is a list of sections that you should at least consider including in your next design doc: Title and People The title of your design doc, the author(s) (should be the same as the list of people planning to work on this project), the reviewer(s) of the doc (we’ll talk more about that in the Process section below), and the date this document was last updated. Overview A high level summary that every engineer at the company should understand and use to decide if it’s useful for them to read the rest of the doc. It should be 3 paragraphs max. Context A description of the problem at hand, why this project is necessary, what people need to know to assess this project, and how it fits into the technical strategy, product strategy, or the team’s quarterly goals. Goals and Non-Goals The Goals section should: describe the user-driven impact of your project — where your user might be another engineering team or even another technical system specify how to measure success using metrics — bonus points if you can link to a dashboard that tracks those metrics Non-Goals are equally important to describe which problems you won’t be fixing so everyone is on the same page. Milestones A list of measurable checkpoints, so your PM and your manager’s manager can skim it and know roughly when different parts of the project will be done. I encourage you to break the project down into major user-facing milestones if the project is more than 1 month long. Use calendar dates so you take into account unrelated delays, vacations, meetings, and so on. It should look something like this: Start Date: June 7, 2018 Milestone 1 — New system MVP running in dark-mode: June 28, 2018 Milestone 2 - Retire old system: July 4th, 2018 End Date: Add feature X, Y, Z to new system: July 14th, 2018 Add an [Update] subsection here if the ETA of some of these milestone changes, so the stakeholders can easily see the most up-to-date estimates. Current Solution In addition to describing the current implementation, you should also walk through a high level example flow to illustrate how users interact with this system and/or how data flow through it. A user story is a great way to frame this. Keep in mind that your system might have different types of users with different use cases. Proposed Solution Some people call this the Technical Architecture section. Again, try to walk through a user story to concretize this. Feel free to include many sub-sections and diagrams. Provide a big picture first, then fill in lots of details. Aim for a world where you can write this, then take a vacation on some deserted island, and another engineer on the team can just read it and implement the solution as you described. Alternative Solutions What else did you consider when coming up with the solution above? What are the pros and cons of the alternatives? Have you considered buying a 3rd-party solution — or using an open source one — that solves this problem as opposed to building your own? Monitoring and Alerting I like including this section, because people often treat this as an afterthought or skip it all together, and it almost always comes back to bite them later when things break and they have no idea how or why. Cross-Team Impact How will this increase on call and dev-ops burden? How much money will it cost? Does it cause any latency regression to the system? Does it expose any security vulnerabilities? What are some negative consequences and side effects? How might the support team communicate this to the customers? Discussion Any open issues that you aren’t sure about, contentious decisions that you’d like readers to weigh in on, suggested future work, and so on. Detailed Scoping and Timeline This section is mostly going to be read only by the engineers working on this project, their tech leads, and their managers. Hence this section is at the end of the doc. Essentially, this is the breakdown of how and when you plan on executing each part of the project. There’s a lot that goes into scoping accurately, so you can read this post to learn more about scoping. I tend to also treat this section of the design doc as an ongoing project task tracker, so I update this whenever my scoping estimate changes. But that’s more of a personal preference. How to write it Now that we’ve talked about what goes into a good design doc, let’s talk about the style of writing. I promise this is different than your high school English class. Write as simply as possible Don’t try to write like the academic papers you’ve read. They are written to impress journal reviewers. Your doc is written to describe your solution and get feedback from your teammates. You can achieve clarity by using: Simple words Short sentences Bulleted lists and/or numbered lists Concrete examples, like “User Alice connects her bank account, then …” Add lots of charts and diagrams Charts can often be useful to compare several potential options, and diagrams are generally easier to parse than text. I’ve had good luck with Google Drawing for creating diagrams. Pro Tip: remember to add a link to the editable version of the diagram under the screenshot, so you can easily update it later when things inevitably change. Include numbers The scale of the problem often determines the solution. To help reviewers get a sense of the state of the world, include real numbers like # of DB rows, # of user errors, latency — and how these scale with usage (remember your Big-O notations?). Try to be funny A spec is not an academic paper. Also, people like reading funny things, so this is a good way to keep the reader engaged. Don’t overdo this to the point of taking away from the core idea though. If you, like me, have trouble being funny, Joel Spolsky (obviously known for his comedic talents…) has this tip: One of the easiest ways to be funny is to be specific when it’s not called for [… Example:] Instead of saying “special interests,” say “left-handed avacado farmers.” Do the Skeptic Test Before sending your design doc to others to review, take a pass at it pretending to be the reviewer. What questions and doubts might you have about this design? Then address them preemptively. Do the Vacation Test If you go on a long vacation now with no internet access, can someone on your team read the doc and implement it as you intended? The main goal of a design doc is not knowledge sharing, but this is a good way to evaluate for clarity so that others can actually give you useful feedback. Process Ah yes, the dreaded P-word. Design docs help you get feedback before you waste a bunch of time implementing the wrong solution or the solution to the wrong problem. There’s a lot of art to getting good feedback, but that’s for a later article. For now, let’s just talk specifically about how to write the design doc and get feedback for it. First of all, everyone working on the project should be a part of the design process. It’s okay if the tech lead ends up driving a lot of the decisions, but everyone should be involved in the discussion and buy into the design. So the “you” throughout this article is a really plural “you” that includes all the people on the project. Secondly, the design process doesn’t mean you staring at the whiteboard theorizing ideas. Feel free to get your hands dirty and prototype potential solutions. This is not the same as starting to write production code for the project before writing a design doc. Don’t do that. But you absolutely should feel free to write some hacky throwaway code to validate an idea. To ensure that you only write exploratory code, make it a rule that none of this prototype code gets merged to master. After that, as you start to have some idea of how to go about your project, do the following: Ask an experienced engineer or tech lead on your team to be your reviewer. Ideally this would be someone who’s well respected and/or familiar with the edge cases of the problem. Bribe them with boba if necessary. Go into a conference room with a whiteboard. Describe the problem that you are tackling to this engineer (this is a very important step, don’t skip it!). Then explain the implementation you have in mind, and convince them this is the right thing to build. Doing all of this before you even start writing your design doc lets you get feedback as soon as possible, before you invest more time and get attached to any specific solution. Often, even if the implementation stays the same, your reviewer is able to point out corner cases you need to cover, indicate any potential areas of confusion, and anticipate difficulties you might encounter later on. Then, after you’ve written a rough draft of your design doc, get the same reviewer to read through it again, and rubber stamp it by adding their name as the reviewer in the Title and People section of the design doc. This creates additional incentive and accountability for the reviewer. On that note, consider adding specialized reviewers (such as SREs and security engineers) for specific aspects of the design. Once you and the reviewer(s) sign off, feel free to send the design doc to your team for additional feedback and knowledge sharing. I suggest time-bounding this feedback gathering process to about 1 week to avoid extended delays. Commit to addressing all questions and comments people leave within that week. Leaving comments hanging = bad karma. Lastly, if there’s a lot of contention between you, your reviewer, and other engineers reading the doc, I strongly recommend consolidating all the points of contention in the Discussion section of your doc. Then, set up a meeting with the different parties to talk about these disagreements in person. Whenever a discussion thread is more than 5 comments long, moving to an in-person discussion tends to be far more efficient. Keep in mind that you are still responsible for making the final call, even if everyone can’t come to a consensus. In talking to Shrey Banga recently about this, I learned that Quip has a similar process, except in addition to having an experienced engineer or tech lead on your team as a reviewer, they also suggest having an engineer on a different team review the doc. I haven’t tried this, but I can certainly see this helping get feedback from people with different perspectives and improve the general readability of the doc. Once you’ve done all the above, time to get going on the implementation! For extra brownie points, treat this design doc as a living document as you implement the design. Update the doc every time you learn something that leads to you making changes to the original solution or update your scoping. You’ll thank me later when you don’t have to explain things over and over again to all your stakeholders. Finally, let’s get really meta for a second: How do we evaluate the success of a design doc? My coworker Kent Rakip has a good answer to this: A design doc is successful if the right ROI of work is done. That means a successful design doc might actually lead to an outcome like this: You spend 5 days writing the design doc, this forces you to think through different parts of the technical architecture You get feedback from reviewers that X is the riskiest part of the proposed architecture You decide to implement X first to de-risk the project 3 days later, you figure out that X is either not possible, or far more difficult than you originally intended You decide to stop working on this project and prioritize other work instead At the beginning of this article, we said the goal of a design doc is to make sure the right work gets done. In the example above, thanks to this design doc, instead of wasting potentially months only to abort this project later, you’ve only spent 8 days. Seems like a pretty successful outcome to me.

From Behind The Screen 4 Featuring: Kent Blue and Tim Devine This week Kent has Tim Devine of Dice Up Games on to chat about his hacks of Lasers & Feelings; Wits & Chivalry and Truth & Daring. Then the two talk about what it is like being gaming dads. Finally, Kent and Tim go into all kinds of different games and podcasts on their minds lately. Be sure to check out the Wait Wait, Don’t Roll Me podcast to hear Tim running his games. Also check out the Design Doc podcast the guys talk about. Also, go tell Jim McClure we need Talking TableTop back in our ears. Please, if you enjoy what we are doing and want to see us grow, rate us on iTunes or share us with a friend! Social Media: www.rolltoplaypodcast.com Facebook: Roll To Play Podcast Twitter - @RollToPlayPod Instagram – rolltoplaypodcast Email – gm@rolltoplaynetwork.com Theme Music:"Intro by Tri-Tachyon" "https://creativecommons.org/licenses/by-nc/4.0/" "https://soundcloud.com/tri-tachyon"

Hannah and Evan embark on a journey to redesign their first roleplaying game. Welcome to Design Doc, our year-long experiment in transparent design! Social media https://twitter.com/designdocpod designdocpod@gmail.com

Dr. Vickie, The Design Doc answers key questions like: What is branding? Why do I need it? How can it help my business? Small businesses can't afford NOT to brand! Learn how to use branding to give your business credibility, develop your promise to your customers, and cultivate relationships with your customers. There are many other tips and exercises to help you brand your business to success! This information is targeted toward small business owners, entrepreneurs, and start-ups!