With the introduction of NavigationStack and NavigationSplitView in iOS 16, we now have the power to control navigation similarly to how we did with UIKit. However, as with anything new, it requires a different approach than the traditional NavigationView. Therefore, if we want to harness the dynamic navigation capabilities offered by NavigationStack, it's essential to embrace new design patterns. In the ever-evolving realm of iOS app development, efficient and user-friendly navigation is not just a luxury; it's a necessity. In a recent in-depth presentation, I had the opportunity to explore this topic comprehensively. In this blog, I aim to share those insights, focusing on three key strategies: Screen Coordinator, ViewCoordinator, and Router.

• Define the path Variable: Begin by creating a variable named path of type NavigationPath(). This variable will track the current navigation location.
• Use NavigationLink with value: Employ NavigationLink to establish transitions between views. When using NavigationLink, make sure to set the value parameter to the corresponding NavigationPath for each destination. This enables the selection of specific paths for navigation.
• Customize Navigation with .navigationDestination : To tailor navigation routes and behaviors, leverage the .navigationDestination(for: ) modifier. This powerful tool allows you to define navigation paths dynamically, offering precise control over transitions and application flow.

By following these steps and utilizing the combination of NavigationStack, NavigationPath, NavigationLink with value, and .navigationDestination, you gain the capability to create a highly dynamic and user-friendly navigation experience in your SwiftUI app.

Screen Coordinator:

The Screen Coordinator plays a pivotal role in app navigation by overseeing the views to be shown across the navigation flow. Within the app's structure, an enum is defined, named "Screen," which contains cases representing different views accessible within the app. Additionally, a function called "view" is implemented within the Screen Coordinator. This function takes a "destination" parameter and, based on that specific destination, returns the corresponding view. The magic happens when we utilize the ".navigationDestination()" modifier in our views. Within this modifier, we specify the Screen Coordinator's destination type (Screen). When navigation to a particular view is triggered, this modifier automatically invokes the Screen Coordinator's "view(for: )" function, providing it with the corresponding destination as a parameter. Thus, the Screen Coordinator determines which view should be displayed in response to navigation, simplifying UI management and navigation throughout the app.

The Screen Coordinator method, acting as the central command for app navigation, brings considerable benefits. It shines in its ability to centralize navigation control, significantly reducing the coupling between view controllers and easing the management of complex navigational flows. This makes it a robust choice for large-scale applications with numerous screens and complex navigation requirements. However, its complexity can be a double-edged sword. For smaller projects, this approach might be overkill, introducing unnecessary complications. Additionally, the steep learning curve associated with mastering Screen Coordinators can be a barrier for beginners, requiring a solid grasp of architectural concepts.

ViewCoordinator for Each View:

The View Coordinator approach takes a concept similar to the Screen Coordinator but brings it down to the granularity of individual views. In this design, each view has its dedicated View Coordinator responsible for managing interactions specific to that view. Each View Coordinator defines the views to be used within its scope and handles navigation-related operations. Just like in the Screen Coordinator approach, an enumeration ("Destination") is utilized to represent various view destinations. However, the key distinction lies in the fact that each view controller has its own declaration of the "Destination" enum and its respective "navigationDestination" modifier. Unlike the Screen Coordinator, which typically has a single declaration at the root of navigation.

Adopting a ViewCoordinator for each view presents a more decentralized approach to navigation. This method excels in providing granular control over the navigation of individual views, enhancing modularity and organization. It's particularly advantageous for applications that benefit from a modular design, allowing each section or screen to manage its own navigation independently. However, this approach can lead to a proliferation of redundant code, especially in simpler applications where such fine-tuned control isn't necessary. The added overhead of managing multiple coordinators can sometimes outweigh the benefits, particularly in smaller or less complex applications.

Router for Programmatic Navigation:

In the Router for Programmatic Navigation approach, we build upon the Screen Coordinator concept while introducing a new class called NavigationRouter. The primary responsibility of this class is to exclusively handle navigation. Within the NavigationRouter class, we define a variable named "path," which should be of type NavigationPath() and marked as @Published. This "path" variable is added to the "path" parameter of the NavigationStack. In this class, we also define functions like "navigate(to: Destination)," which enables programmatic navigation. Additionally, a "resetNavigation(with [Destination])" function can be implemented to return to the root view or reset the navigation path with different views. This NavigationRouter is then shared with other views using the ".environmentObject()" modifier, and each view accesses it using the "@EnvironmentObject" property wrapper. This approach provides a structured way to manage programmatic navigation within the app, offering greater flexibility and control over the navigation flow.

The Router approach, designed for dynamic and programmatic navigation, offers a high degree of flexibility and adaptability. It's particularly well-suited for applications requiring complex, non-linear navigation flows and those with conditional navigation logic. This method allows developers to tailor navigation precisely to the app's needs, accommodating a wide array of navigation scenarios. However, this flexibility comes with its challenges. The complexity inherent in setting up and maintaining a Router-based system can be daunting. It also presents a higher risk of introducing hard-to-debug issues, especially in large and complex applications where navigation paths are less predictable.

Final Thoughts:

In selecting the right navigation method, it's crucial to weigh these pros and cons against the specific needs and complexity of your project. Each method offers distinct advantages, but also comes with its own set of challenges. The choice ultimately hinges on finding the balance between the desired level of control, the complexity of the app, and the ease of maintaining the navigation structure.

Best Practices and Tips:

Irrespective of the approach, some universal best practices apply:

• Keep navigation logic separate from business logic.
• Ensure that your choice aligns with the scale and complexity of your app.
• Aim for clarity and maintainability in your navigation structure.

Explore on GitHub:

To see these navigation techniques in action, visit our GitHub repository. You'll find code examples and documentation for each strategy. Whether you're a seasoned iOS developer or just starting with SwiftUI, this resource can accelerate your learning. Feel free to review, fork, and contribute. Your feedback and contributions are appreciated.

GitHub Repository: github.com/edsonlipa/NavigationStack-in-IOS16

SwiftUI, Apple's user interface development framework, has introduced a groundbreaking feature known as the "Inspector." This tool enhances the development experience by offering detailed interaction and enriched visualization of selected content. Essentially, the Inspector is an intuitive tool that reveals additional details and allows for direct manipulation of UI elements in a contextual and relevant manner.

Usage and Implementation.

Implementation Examples:

• Keynote: Uses an Inspector as a sidebar to display formatting details for a given selection, such as the format of a shape or text.
• Shortcuts: Displays complementary content, such as a library of available actions, pertinent to the workflow being edited.

The Inspector is not just about displaying information; facilitates powerful interactions, allowing real-time property adjustments or content modifications of selected elements.

Availability and Adaptability.

Available on macOS, iPadOS, and iOS, SwiftUI's Inspector is highly adaptable. It automatically adjusts based on device size and context, morphing into a resizable sheet in compact size classes or overlaying in split screen on larger iPads.

Integration and Customization.

The Inspector integrates with SwiftUI's existing structural APIs and behaves similarly to navigation and presentation components. It can be presented or hidden as needed and is customizable through modifiers, offering fine control over aspects like the width of the Inspector's column or its presentation state.

Considerations.

• API Adoption: Learning to adopt the Inspector is straightforward; developers can integrate it into their apps using a new inspector modifier.
• Customization and Control: The width of the Inspector's column and its presentation state can be programmatically controlled.
• Form Styles: The Inspector defaults to grouped form styles, simplifying visual consistency.

Navigating the New Frontiers with SwiftUI Structural APIs.

Dive into the realm of SwiftUI's enhanced structural APIs showcased in this visual encapsulation. Central to this lineup is the NavigationSplitView, providing a modern take on split views, and the NavigationStack, which redefines navigation flows with its stack-like behavior.

A notable newcomer, .inspector, stands out as a transformative tool for adding contextual sidebars or overlays, bringing a new dimension to interface customization. Accompanying these are familiar APIs like .sheet, .popover, .alert, and .confirmationDialog, all integral to the dynamic and responsive nature of SwiftUI apps. Together, they represent the building blocks for crafting fluid, adaptive, and deeply interactive user experiences across the Apple ecosystem.

This visual guide outlines the strategic placement of toolbar content in relation to SwiftUI's inspector pane, demonstrating four distinct scenarios. When the toolbar is placed within the inspector's context, it aligns seamlessly within the sidebar or overlay, ensuring an integrated experience.

Conversely, toolbar content positioned outside the inspector retains its location regardless of the inspector's state, providing a persistent interface element. The accompanying code snippets provide clear examples of how to implement each scenario, serving as a hands-on reference for developers to tailor the toolbar's behavior to their app's design philosophy. Whether nested within the navigation stack or standing apart, these patterns highlight the versatility and customization possibilities with SwiftUI's latest structural APIs.

Final thoughts.

SwiftUI's Inspector is not just an aesthetic addition; it represents a leap forward in how developers and users interact with UI. By offering detailed visualization and real-time control, the Inspector aligns perfectly with SwiftUI's philosophy of creating powerful, intuitive, and adaptive user interfaces with less code.
This blog has been an introduction to SwiftUI's powerful and versatile Inspector. As we delve deeper into its capabilities and how it can transform both the development experience and user interaction, it's evident that SwiftUI continues to redefine expectations and possibilities in modern app development.

For those eager to see the SwiftUI Inspector in action, Apple’s WWDC 2023 provides an excellent resource. In their session titled “Inspectors in SwiftUI: Discover the details,” Apple engineers delve into the practical applications of the Inspector, among other powerful SwiftUI features. You'll get a firsthand look at how these tools can be used to enhance the development process, streamline UI design, and much more. Watch the full session here to deepen your understanding and see how you can apply these insights to your own SwiftUI projects.

Google Material Design reached out to Ravn for our expertise around design to code handoff tools, processes and experience. They also asked us to pilot their new Android design to code product, Relay.

We have been working with Google for some time now and we are excited as they have finally launched Relay (alpha) for Figma and Android. We've been skeptical of design to code tools in the past as most are gimmicky at best but Relay is different. Relay is really showing promise as a tool that could fundamentally improve developer experience, starting with Android.

We're happy to see they appreciate our opinion and expertise on the matter, but don't take my word for it - they wrote a case study about working with Ravn:

How Ravn solves design-developer handoff with Relay

The purpose: To Develop a PC desktop application to configure and interact with a new line of Skullcandy gaming headsets

The Challenge: Working with various unique hardware, firmware, and low level software libraries

The Solution: A solid team, Electron, Node Addon API, C++, and ReactJS

Outcome: A polished and news worthy desktop application: Skull-HQ software, quality code, and reliable automated updates

See it in the media here and here.

Who is Skullcandy?

Skullcandy Inc. is an American company based in Park City, Utah, that markets headphones, earphones, hands-free devices, and other products.

Skullcandy’s products are primarily targeted to the outdoor action sports demographic (snowboarders, skateboarders, etc.) and general consumer market, but they have expanded in recent years into the premium audio market with products such as the Crusher headphones.

Most recently they embarked on a mission to enter back into the gaming space with their SLYR, SLYR PRO and PLYR gaming headsets. It was at this point they reached out to Ravn for help.

Our partners at Ravn have been more than a pleasure to work with. They are competent, reliable, and have continually exceeded our expectations!

Jenny Buchar, Applications Product Manager @ Skullcandy

Challenge

Skullcandy wanted a companion desktop application to release alongside their new line of gaming headsets. As a mostly hardware company, and with a fast approaching deadline, Skullcandy needed a strong team of developers to be able to jump in and seamlessly integrate into their design and hardware teams.

The hardware and firmware were already deep into production cycles so we had to work within the constraints of what was already defined and ready for release.

They needed the app to run on Windows and it was important for them to build something that could be extended to MacOS in the future.

The requirements involved integrating code from a third party vendor to adjust settings on the devices and perform hearing tests as part of a feature which allows users to tune their devices to improve sound custom to their ears. We needed to be able to utilize this code, written in C++, in whatever technology we chose to go with.

Skullcandy was shooting for a modern retro style app aesthetic with challenging design elements.

Solution

Ravn decided that the best way to provide multi-platform support with potentially shared code was to use Electron. Electron allows you to build cross platform desktop applications with web technologies including HTML, CSS, and Javascript. We found Electron to be the perfect platform for this project.

Because there were so many unknowns associated with using the C++ headset communication library in javascript, we prioritized that work first.

Two teams were arranged to make the best use of a limited time frame. One team would focus on the Electron app and frontend while the other focused on consuming and integrating the C++ SDKs into the javascript side.

Electron apps exist in a NodeJS environment -- a Javascript engine built on Chrome’s V8 engine, which is written in C and C++. NodeJS offers its Node Addon Api, a C++ wrapper/bridge for developers to use C++ code in Javascript. For the headset communication and hearing test SDKs we used the Node Addon Api with an event-listener style architecture to send and receive events from the headsets. These were set up as private Github packages so we could version our changes for the client applications. We set up automated builds with versioning and release capabilities to ensure making changes to the package would be quick, smooth, and painless.

The headset didn’t support listening for changes in device values so we set up a polling system to reflect changes in the headset initiated by the build in headset buttons or from the mobile app.

The headsets have a wheel on them that the user can use to adjust system volume and we wanted to be able to reflect this value in the UI as the user adjusts it. Existing NPM packages for system volume either didn’t support listening for changes or utilized methods that hogged valuable system resources. We built a performant custom volume listener package using OS specific C++ APIs and the Node Addon Api and tied it into our existing automation flow for C++ packages.

We worked alongside the hardware and firmware teams to report bugs, pivot to support under-development features, and make recommendations for additional and necessary changes for the desktop application.

UI elements were carefully crafted and organized to be maintainable, extendable, and reusable.

The Ravn team built a hands off process for releasing and updating the app for the end user that was easy to follow and stay on top of from the Skullcandy side. We wanted to put an emphasis on creating a process that could live on long after we were gone. We implemented a similar process for the firmware updates that were necessary for the headsets to be able to receive updates.

Ravn - A team of strong, reliable, and high performing developers. They solved some pretty challenging issues and did so with grit and grace. It’s been a pleasure working together and I hope to continue a long term partnership with them.

Ian Sime, Solutions Architect @ Skullcandy

Outcome

After teaming with Ravn, Skullcandy successfully pushed the new gaming product line with the companion app, Skull-HQ software.

The companion desktop application was called out in media reviews as being a polished and delightful experience that set their gaming line apart from competitors.

The close and effective recommendations and collaboration of the Ravn team with the hardware and firmware teams resulted in a delightful headset and application experience for the end user.

The project is left in a state where onboarding a new developer is easy and development is smooth and enjoyable.

App and firmware updates are stable and stress free for both Skullcandy and the end user.

Not every leader is born wishing they had a team to lead, and frankly you don't need to. I can honestly tell you that I didn't want to become a manager at all because I was used to seeing and hearing how people in those roles acted in a way that went against my principles - other team members hated them, and they made their lives miserable in return.

Of course, I was generalizing, but I didn't have any good example to prove the opposite was true, and since I thought that managers were also leaders, I didn't want to become one either.

On the opposite side, I was always drawn to heroes. I loved how Luke Skywalker fought against himself and won to resist joining the dark side; how Peter Parker was just a kid from Brooklyn helping out his neighbors; or the way that the Guardians of the Galaxy were a bunch of misfits and still made it work. But there was one character I always rooted for and others didn't understand why, that character was Tony Stark AKA Iron Man.

This is the story of how I learned to become a leader by watching Tony Stark grow as a character over more than ten years.

The leader's journey

Being the center of attention

Put a confident, intelligent and sarcastic character on the screen and it will always catch my attention. It is just the type of personality I'm drawn towards. Ever since the first movie, Tony Stark wasn't afraid of taking the center stage and using his charisma (and money) to get what he wanted. I could relate, after all, I used to act similarly within teams: taking advantage of being the best in what I did to lead decisions and showing-off because everybody knew I was the best.

But taking advantage of your skills in such a way doesn't help you to become a leader. It creates the opposite situation where people prefer not to work with you because your attitude creates friction, even though the quality of your work is outstanding. As I've mentioned in the past: a team is like a band, so you have to tone down your solos to create group cohesion.

He was fine being the sole center of attention, until one day he was invited to join an initiative.

Denial of being part of something

When you're used to relying solely on yourself, you don't like the idea of depending on others or trusting them with your toys, just like Tony Stark wasn't keen on joining the Avengers. He was called because he was needed, but he wasn't interested in staying for long and being part of a team, he had much more interesting things to do on his own.

Switching from freelancing to joining a team feels unnatural, it certainly felt like that to me. I wasn't excited to fit in because I knew I could do things on my own, or at least that's what I thought. It wasn't until I realized that others possessed skills that I lacked that made me appreciate being part of a cross-functional team, and because of that, I started to find ways to help others do their work better.

It was uncomfortable for Tony to be asked to be part of a team, until one day something bigger happens and he realized he should do something about it. That was the battle of New York.

Trying and failing to strike a balance

He was getting more used not only to the idea of being part of a team but also leading them. The problem was when unexpected problems started to happen and he was expected to act as the perfect leader that others wanted him to be. Like being attacked by his former colleague Aldrich Killian based on resentment, dealing with the friction of conflicting values with his leadership peer Steve Rogers or looking at how his novel idea of creating Ultron to protect the world completely backfired him.

There was a time when I was moving into bigger and more complex challenges as an IC, with the idea of becoming a leader at the back of my mind without taking it seriously. The fact that I had recently left an unhealthy working environment didn't help at all, because it only made me doubt myself and prevented me from giving leadership a real chance.

It would be hard for me to point out an exact moment in time when I finally considered myself a leader, but two decisive factors that made a big difference to start my transition:

1. I found my first mentor, the person that saw the potential in me that I couldn't see by myself, giving me challenging opportunities to try, and teaching me what a real leader looks like.
2. My peers started trusting me as a leader without being asked to do so, even without a title attached to my name.

I wish there was a manual to read when you're just getting started as a leader. I have read several leadership and management books and articles, but there are so many variables and nuances around your context of becoming a leader that it's unrealistic to expect to be 100% prepared for it.

Tony Stark was having trouble trusting his leadership capabilities, until one day someone started looking up at him and trusting him blindly, that certain someone was no other than Peter Parker. If you're keeping track of the parallels you may have noticed this pattern already: When others start seeing you as a leader even if there's a lot left to improve, there's a better chance that you'll trust yourself enough to try.

Not feeling ready to level up

You know how the saying goes: What got you here won't get you to the next level. By the time Infinity War arrived, Tony was very confident about being a leader and a mentor. He had gone through a lot in ten years and seven movies, positioning himself as a clear leadership figure even for those that were skeptical at first, but he had only been saving the world, now was the time to save the universe.

He tried, apparently failed, and lost most of his team in the process. This is the type of earth-shattering scenario that can break even the most experienced leaders, and design leadership isn't absent from that. The sarcastic, intelligent, and highly confident Tony Stark was shattered.

When you think about people like Ryan Rumsey, Dan Mall, or Brad Frost it's easy to get inspired by how much they have contributed to the design community worldwide, but they are also humans and deal with struggles just like you and me. Sometimes is about stepping into a new role, expanding a business, or taking care of their wellbeing. Career paths aren't linear, which also includes a lot of challenges you weren't prepared for and can make you doubt yourself more than once. The key is to learn from it, adapt and overcome it.

I was directing design. And I was utterly stuck. - Ryan Rumsey

"SuperFriendly 2021 Wrap-Up," an article by Dan Mall

Working Better: Interview with web designer Brad Frost - Noisli

Stark decided that it was time to retire in a cozy cabin in the woods and leave his Iron Man alter ego behind. Until one day, the opportunity knocked at his door and this time he was ready to save the universe.

Returning, but as a different person

I knew Tony Stark would sacrifice himself as soon as I saw a little figure with a small helmet similar to Iron Man's. As a fan, I was in denial of seeing Tony die before Infinity War came out, and the last argument I could find to back up my theory was that he didn't have a family, to give closure to his personal life... until it was no longer the case and I didn't have a doubt about what was going to happen next. Why? you might ask. Because he was now a different person, he became a leader and a hero.

As I mentioned some time ago on Twitter: if you asked me years ago if I wanted to be a leader I would have said no in a heartbeat. People within my team find it hard to believe, but I'm an incredibly introverted person, hence my lack of desire to join a team just like Tony at first.

I went through a slow and conscious mindset change before the opportunity knocked at my door, and even if I didn't know 100% how I was going to build a team from scratch (which is a very daunting challenge if you have never done it before) I knew it was time, I was ready to join a new team, only this time I was the leader.

If you asked me five years ago if I would feel recharged as an introvert by helping out and leading a whole team through various interactions including calls every day, I would have said no in a heartbeat, but things change and people do too

— Laura Escobar (@laurieesc) January 7, 2022

When I first watched Iron Man I was in because of Tony's charming personality, but what made me stay was the character's arc. Similarly, starting in Product Design was fun because of the technical challenges, but what keeps me going nowadays is becoming a better leader and manager for my team each day, and I wouldn't have it any other way.

“You know who the best managers are? They're the great individual contributors, who never ever want to be a manager, but decide they have to be a manager because no one else is going to be able to do as good a job as them.”

― Steve Jobs

My son recently chose philosophy as his university major, and with the fervor of a recent convert, he guides me into conversations exploring fundamental questions like “What is knowledge?” and “Can we trust reason?” Of course, the answers are hard to firmly grasp, but the conversations, which I always enjoy, sparked some thinking about how the great minds in philosophy could help me in everyday life.

Since my knowledge of philosophy is . . .  shall we say . . .  underdeveloped, I need to lean on the few thinkers who helped me understand the world. Although his writing is sometimes impenetrably difficult for me, Kant is a favorite. He sought to review all knowledge to answer three foundational questions:

What can I know?
What must I do?
What may I hope for?

Kant maintains that these famous three questions are central to all inquiry.

At this point, you may be concerned that, like my son, I am also a fervent missionary for philosophy and seek to create a discussion about topics long ago happily forgotten. Don’t worry. Here is my very practical thesis: These questions are an excellent framework for any complex decision, including those we face at work. If a good question is half of wisdom, these three are gems.

Let’s take a deeper dive into the questions.

What can we know?

It seems fairly obvious that we should seek to understand the dimensions of each opportunity or problem. However, it is at the boundaries of knowledge that true insights occur. The question, poorly framed, is “What do we know?” Kant wisely phrased it, “What can we know?” The intention is to push back the boundary of our ignorance with more data, context, and consequences.

The question also implies that there are limits on our ability to develop complete knowledge. Nobody knows everything. We need to make decisions under conditions of uncertainty. There will always be doubt. Decision makers always want more input, but at what cost in time and treasure?

Once you know what can be reasonably known, it's time to move forward. Inaction and ignorance both impose a cost.

What must we do?

Exercising the power of judgment is necessary in every complex situation, but this question implies that action is an imperative. Once the best possible answer has been identified, there is a need to act with purpose. We ultimately have to produce something people will pay money to buy.

In this context, acting on a thoughtful and well-considered decision is a duty. Of course, it’s not the moral duty prescribed by Kant but a fiduciary duty to all stakeholders in an organization to produce desired outcomes while fomenting real good in society.

The duty to act cultivates responsibility and accountability. What good is action without ownership? The risk of blame for actions not properly completed requires courage. Courage requires confidence. Confidence is best obtained when it is the result of thoughtful and well-intended actions.

Whoohoo! We may have a virtuous path:

Explore > know > think > act > deliver

What may we hope for?

We can hope to craft a healthy, growing, and profitable business that is built to last. This feels like too heavy a lift for any mere mortal, but it is something to guide and inspire us. To be clear, these are not wishes—wishes are for genies—hopes are for planners and doers who reasonably expect a future event to be realized.

Jim Collins coined the term “BHAG.” It is an acronym for “Big Hairy Audacious Goals.” They are long-term, stretch targets that define what is possible and align a group of people on distant goals. It is another way to express ambitious dreams.

Most of these goal-oriented hopes target human happiness or progress. They focus on building something valuable and meaningful.

A theory or framework with broad application is robust and durable. As my son can attest, I may not be able to answer all of the big questions in philosophy. But as I considered Kant's attempt to do so, I found his three questions to be wonderfully extensible: a robust framework with broad application that can help us in our own domains of technology, business, and entrepreneurship.

Experience without theory is blind, but theory without experience is mere intellectual play.

—Immanuel Kant

Although this guide is intended for React and JavaScript beginners, it isn’t limited to them. In fact, I’m certain many of the following nine React and JavaScript tips will be helpful to beginners and experts alike.

If you're a seasoned coder, implement these hacks to become more productive and improve your code. If you're new to coding, this is your chance to master React and JavaScript from the very beginning.

React Tips

1. setState() using function composition

By using function composition, you can compose functions for different purposes. This approach also helps you to write cleaner and more readable code.

Have you worked with forms before? I bet you have.

When it comes to forms, you may need to handle several input fields. A common solution is to create a setYourFieldName setter function for each input field so you can update its value.

Something like the following:

const [firstName, setFirstName] = useState('');
const [lastName, setLastName] = useState('');
const [username, setUsername] = useState('');

setFirstName("blarz");
...

While the above is valid, it isn't elegant. For a cleaner way of doing it, try using function composition.

Let’s take a quick look at this scrawl on my whiteboard. Try to read it line by line.

I am sorry if you weren't able to read it. (If you can't read my handwriting, cut me some slack, I use a keyboard for a living, not a marker 😜). The idea with this is to delay the reading of each line in order to give your brain time to digest it effortlessly.

For help mastering function composition, take a look at the live version of my example here.

To sum this up, using function composition allows you to:

• Write cleaner and more readable code.
• Centralize the logic for updating the state.
• Work with any number of input fields.

2. Pass props down using the spread operator

Components communicate with other components via props. Props are data (or settings) that components need. This means you may need to pass down a list of them.

It is just fine to pass a few props down explicitly and individually, but when you need to pass a huge list of them, it can be a pain.

Here is when the spread operator (...) comes to the rescue.

The simplest way to pass several props at once is to define an object with all the props the component needs. So you don’t need to be explicit setting the prop name and its corresponding value.

Let’s see the next piece of code for a better understanding.

As you can see in the code snippet, the Logo component expects four props: isBrandText, brandImageUrl, altAttr, and brandText. So in the app component, we pass down thelogoInfo object, which is spreading its properties and the corresponding values—a powerful and clean solution!

3. Using short-circuit evaluation

The short-circuit evaluation makes our code more elegant, readable, and clean. This tip sounds simple, but continue reading to see a few pitfalls you might not have seen before.

Let’s take a look at the next example.

return isLoading && <SpinnerComponent/>;

The above code checks if isLoading is true. If so, it renders the SpinnerComponent ; otherwise, it does nothing.

What will be the output of the following return statement in the ConditionalsInReactcomponent ?

Did you guess it? The output will be the following:

What happened here? Why is it rendering 0? Let’s discuss it.

🚨 Values of renderables and non-renderables in React

I spent my precious time trying to understand why the evaluation was rendering 0.

The answer:

I discovered that React will render anything that is a type of string or number, but it will not render value types of false, null, or undefined.

For a better understanding, let’s take a look at the next statements and their outputs. You will notice how the above explanation now makes sense.

return 1 && <Spinner/> // it will render <Spinner/>
return "string" && <Spinner/> // it will render <Spinner/>
return 0 && <Spinner/> // it will render 0

Solution

To make a short-circuit evaluation safe, you can use one of two strategies: the ternary operator or double negation (double casting).

The ternary operator

{rating ?  : null }

Double negation

You can do something like {!!rating && } , making sure the rating is cast to a Boolean value.

4. Update multiple-input state values with only ONE handler

When you're working with forms in React, you will need to watch for changes in the input fields. When there are only a few input fields, you can easily catch those changes by creating an updater function for each of them.

However, if you're working with large forms with several input fields, this approach would be a bad idea.

Instead, define one handler function to use for all input fields. By doing this, you reduce the lines of code, which in turn makes you more productive.

Let’s take a look at the next component.

In the above code snippet, we have created a component called MultipleInputs, which basically renders a form with several input fields.

Then we have declared the state variable inputs and its corresponding updater function setInputs. The inputs variable is the object with all the input fields we are going to need—  firstName, lastName, username, email, password, etc.

Now let’s focus on the handleChange function. Here we are receiving an input e, which is a SyntheticEvent object. This object contains useful metadata such as the target input’s ID, name, and current value.

Let’s deconstruct the e object and extract the name and value from its properties.

const handleChange = (e) => { 
...  
 const { name, value } = e.target;    
...

};

Finally, we update the current input field by passing its name as a dynamic key  [name] and its corresponding value.

const handleChange = (e) => {    
     const { name, value } = e.target;
     setInputs((prevState) => ({ ...prevState, [name]: value }));  };

Voila! You have saved time and have cleaner code.

5. Modify arrays in React with one of three methods

Below, I've demonstrated the three best approaches to modify arrays in React. Take a look at the scrawls on my whiteboard and read them line by line.

Using Lifecycle or setState()

Using Hooks — short version

Using Hooks — detailed version

Next I will show you a real example using Hooks. If you want to see how this should be done using class-based components, scroll up a bit to the picture of my scrawl whiteboard.

JavaScript Tips

6. Pause Console Debugger

One day, I was fighting with a dropdown. I just wanted to inspect one of its elements. It was frustrating.

The dropdown closed automatically when I tried to right-click on the element and click on the “Inspect” option.

I bet you have experienced this headache before too, but from now on, you will have the antidote:

• Open your console from a browser.
• Type in the following command: setTimeout(() => {debugger;}, 5000)

I hope this comes in handy!

7. Welcome back to console.log()

For those who are like me and always come back to the console.log(), here's a good tip: Type in the code below, and you will see the variable name and its value.

console.log({yourVariable});

8. Let React assign keys to children

Assigning keys to children is an important matter in React. It’s the way React identifies which items have changed.

I have used several methods to assign unique keys to children of an element, but once I discovered that React.Children.toArray has the power of assigning keys to children, my life changed.

Here's an explanation of React.Children.toArray from the official React doc:

Returns the children opaque data structure as a flat array with keys assigned to each child. Useful if you want to manipulate collections of children in your render methods, especially if you want to reorder or slice this.props.children before passing it down.

It’s really simple. You just need to wrap the children, something like the code below.

9. Use the nullish coalescing operator

Using a fallback value with the OR (||) operator is a good idea when it comes to check if a value is falsy.

Quick refresher — JavaScript falsy values:

false, '', 0, "", undefined, null, NaN

Let’s suppose we have this Car component.

Did you notice the issue in the above code?

In the span tag, we are using a fallback value whenever the car.price statement is evaluated as falsy. So this means if the car.price is 0, the component will render “Not available.” This, of course, is wrong because we should display 0 as the price.

The above code doesn’t cover the special case in which we need to check if the value is either null or undefined.

Solution

Here is when the nullish coalescing operator ?? comes in handy.

This is a logical operator that returns its right-hand side operand when its left-hand side operand is null or undefined .

Now, using the nullish operator, we will have the following:

Full code

You can find all React files/components on this Codesandbox.

Final Thoughts

I am sure that more than one of the nine React and JavaScript tips we discussed throughout this post will save you time and make you more productive from now on.

Start off using function composition when you want to compose a function for different purposes.

And remember, one of the main patterns in React is the usage of props to communicate to components, so when it comes to passing a huge list of props down, use the spread operator (...) to pass it all at once.

Finally, if you follow these tips you will be able to write cleaner, more readable, and elegant code.

I hope this post turned be out helpful for you. If you enjoyed it, please share it to reach a wider audience.

Thanks for reading. See you in the next piece.

Photo by Javier Allegue Barros on Unsplash

It has been nearly a decade since I started working with digital Product Design. At first, I thought it was going to be something temporary just to pay the bills, but the allure of blending creativity with challenging problems won me over and hasn't stopped me ever since.

Throughout this journey, many things have changed, especially the way I perceive this field and the people that are part of it. Relationships, experiences, and even obstacles have helped me to develop a set of guiding principles that have become a constant to keep moving forward, so it's about time I share these with others.

1. Quality over quantity

During my time at the university, I was taught that doing hundreds of explorations was the best path to be creative. It's certainly useful when you're in the divergence phase of the creative process, but what they don't teach you is that you need to identify when quality should come before quantity.

I can't pinpoint the exact moment when it became my personal motto, but it has been helpful in many different facets of my journey: Product Design outputs, team composition, and even time, they all benefit from prioritizing quality. The trickiest part is not forfeiting quantity, but pursuing quality in everything you do.

2. It's ok not knowing everything

As naïve as it may sound, during the first couple of years of my career I thought I had tons of experience and knew a lot, but boy was I wrong. The more I realized I had a whole world to discover, the more I feared I wasn't going to be able to capture everything, but I learned to apply my own principle and accept that quality was more important than understanding every single piece about this field.

Moreover, I learned to appreciate the feeling of learning new things for the very first time, accepting feedback from others, and being intentional about my learning in the last couple of years.

3. Learn something new every day

Keeping up with the learning topic, becoming proficient at something doesn't happen overnight. Instead, it occurs in small doses of learning moments on a day-to-day basis. One could argue that by reading a book in a day you've grasped a concept, but most of us don't spend our weekends devouring entire books in 24 hours or less.

That's why I love the online expression "Today I Learned", shortened as TIL, because learning can happen at any moment, with any person and any place of your day, you just have to be humble and curious to take it in.

4. Research, research, research

It's interesting how when you're working in development with an agency model, you get exposed to a wide array of unknowns in addition to your own craft. I've been completely new to markets like basketball operations, fintech, and data quality, but every time it all started the same way: doing research.

Learning from subject matter experts definitely helps to speed up the process of gaining understanding, but you shouldn't depend solely on that. With each new project or feature take that as an opportunity to do your due diligence with secondary research and understand the fundamental concepts.

You're not only expected to discuss Product Design in isolation, it should be applied to the context of the product and its business to drive decisions.

5. Keep it consistent

This principle unconsciously brings a smile to my face for a small reason: it became an association with me by others I was working with.

During my time as a Product Designer for Miami Heat, I had to deal with many moving parts and stakeholders with a deep understanding of the business. Every decision would impact the business at scale, and discussions were crucial to keeping moving forward, so I got into the habit of putting emphasis on consistency to ensure things never got out of control.

Before I knew it, some of them started to say "... for consistency's sake, as Laura would say" on conversations I wasn't even part of. I gladly took that with me to apply it intentionally elsewhere, which leads me to my next principle.

6. Modularity, flexibility and scalability

Most designers focus on aesthetics at the beginning of their careers. I know I did, but drop shadows and smooth interactions don't make successful products that change people's lives.

Systems Thinking is one of the most critical skills any Product Designer should develop, yet is often ignored and barely touched while deepening our skillset. With good System Thinking, your product has the modularity that allows for flexibility within existing features, which in turn enables scalability of the system as a whole.

This skill can be applied to all levels of any product, like a navigation pattern, a checkout User Flow, or even the buying module as a whole. The key to all of this is not only about creating the right connections but doing it consistently to naturally scale as new business and user needs arise.

7. Whenever possible, be prepared

When you're a freelancer or consultant you have to learn to do everything on your own, which means you have to be prepared because nobody else will do it for you. All those meetings, scope definitions, and milestone deliverables depended solely on me, so when the time came and I had to collaborate with a team it was like second nature to me.

As someone that values punctuality and responsibility, I wanted to lead by example with everything I was doing, like showing up on time to a meeting, being prepared to present in front of an audience, or facilitating a full week of Design Sprint for a client. Doing this consistently creates trust and reliability in you, and in turn, becoming a key player on the team.

8. Communicate early and often

It's very common to find designers and developers throwing the classic "I know you're always busy so I didn't want to bother" to excuse the lack of communication, especially during their initial years. The truth is, I prefer the opposite and have healthy constant communication with my teammates, even more so now that we're in a remote-first situation.

Asking -good- questions is a best practice that I teach to all junior designers because otherwise solutions are built on assumptions, and fixing them later will come at a higher cost. Many could fear that by asking they may seem dumb, but in a culture of psychological safety asking questions should happen early and often.

9. The sum is better than the parts

It must be clear by now how much I've learned to value being part of a team, with the keyword being "learned". As I've shared in previous articles, I wasn't used to being part of a team, I thought I could do everything on my own.

It wasn't until I started to see the outcomes of team collaboration that I noticed how powerful it is to be part of a team, each one of us bringing a different set of skills that will produce greater results than any of us could do on our own. Using music as an example: solos are great, but a tight band is always much better.

10. It's just work

This may seem contradictory but Wendy Johansson reminded me of this a couple of weeks ago during a fireside chat from ADPList: It's just work.

We could be the best designers in the world, but if you don't take care of yourself first you're not going to be capable of performing at your best. That's why I've learned to appreciate a good coffee with friends on a weekend, getaway vacations to disconnect, and even naps to recharge. Don't wait until it's too late, take care of your wellbeing every single day.

I hope these principles can help you with your own journey, I know that I'll remind myself of them and keep them at hand to guide me for many years to come.

"Are you sure you are in my backyard?"

"Ahh"

"Is there a blue slide by the pool?"

"No"

"You are not at my house."

I needed a new cover on my backyard pool.

They are expensive.

The installer completed the installation and called for payment.

He installed the cover on a pool three houses down the street.

My neighbor has a pool cover they do not want.

My project is late.

One careless worker can create two new jobs.

I still remember vividly how my first music class started: I was a 15-year-old girl whose sole experience until that moment constituted a couple of informal classes taught by a friend. With that meager background, I stepped into a room with guys taller and older than I was who had already been doing this for a long time. It felt like I didn't belong. After that day my fingers suffered countless times, and I ran into investments of all kinds I didn't know I had to make—but the results were worth it, and I discovered a new language that would forever change my life. Little did I know that it would impact my career many years down the road.

It took years of my career and an introspective moment to realize that being a musician in the first place taught me how to be a better Product Designer. I realize now that these two passions are connected in more ways than I thought possible.

Still with me? Let's make these worlds collide.

A Team Is Like a Band

Have you met show-off musicians? I certainly have, and during the first steps I took as a guitar player, it seemed to me that showing off was the only way for me to succeed . . . even though this was an attitude I didn't agree with at all.

In my first couple of classes, it was common to see people showing off their skills, but since I didn't have any musical skills to brag about, I sat down and listened, trying to learn from everyone in that room. Many classes and months later, I briefly joined a band, and that's when it started to click for me: in order for us to sound good as a band, I needed to listen to my bandmates and integrate my sound with theirs. Instead of trying to stand out, we had to be attentive to the key, our tempo and everything that was happening around us. Sound familiar?

Years later I joined a development team for the very first time, and it seemed oddly familiar to me: everyone had different skills, and some of them enjoyed showing off. But at the end of the day, in order to deliver, we had to work together as a team. Guess why? Because we needed each other to complement our own skills. From time to time I could have the spotlight with my designs, and it felt nice—similar to a solo—but at the end of the day, I had to learn to speak the language of my teammates to properly collaborate and become a high-performance team.

For the design and development teamwork in particular, I always like to reference what Dan Mall and Brad Frost call "The Hot Potato Process", to achieve a quick and iterative agile collaboration. Like any amazing band you enjoy, there's no room for egos if you want to succeed.

Welcome Feedback

For two years, Saturday morning was a highlight of my week because I was constantly learning a lot, and the key ingredient to all this learning was feedback. Every new scale, every new technique and every new song required feedback from my teacher and my classmates to improve my skills. Otherwise, I would get a bad grade during my next evaluation, but most importantly, I wouldn't grow . . . at least not at the pace I was aiming for.

When I started design classes at the university, I didn't know my work would be critiqued every week. It was uncomfortable at first to hear my classmates (with little to no design experience) voice their opinions on my designs. But I had to accept that dreaded moment and hope that whoever critiqued my work wouldn't be rude. As soon as I realized that my peers could help me identify areas of opportunity, I embraced it and requested objective feedback to keep learning.

This translated almost to a tee in my career. As a Product Designer, I receive design critiques, I often request a second pair of eyes to solve a tough problem and I participate in design reviews with clients and stakeholders. Your work will and should receive feedback to prevent tunnel vision. As long as you understand that feedback isn't personal and constructive criticism is valuable for the product, you'll grow and help others grow too.

Feedback in itself requires effective communication, which is something that has already been explored by several authors specifically for design:

• Giving better design feedback
• Managing your design feedback
• Useful feedback: a lesson in communication
• When to give strategic vs. prescriptive design feedback
• The best tips for giving formal feedback

Average players want to be left alone. Good players want to be coached. Great players want to be told the truth. -—Doc Rivers

Practice, Practice, Practice

There's no shortcut when it comes to design or music: you have to practice what you have learned to polish your skills.

Many would argue that some people are born with talent. I've received that comment countless times referring to my illustrations, but I always emphasize that what they are seeing now is the result of years of practice and anyone could learn to do it. Most of the time I get a laugh followed by a "that's impossible, my drawing skills are as good as a five-year-old’s." But if I showed you what my initial drawings looked like, you wouldn't be laughing . . . at least, not at yourself.

Practice in music looks like endless nights of repetitive exercises, developing muscle memory and calluses on your fingers. It would be easy to just give up at the first sign of getting tired or not being able to play the song you're dying to learn. If music were easy to master, then anyone could be a musician, and the same principle applies to Product Design.

Whenever someone asks me how to get started on design, regardless of the field, I'm honest with them: I tell them upfront that it may take years before they're truly proud of their work. But I always follow up with the encouragement that by practicing as often as possible, they'll get to the results they expect sooner. With that being said, it’s not only the act of practicing that matters but being intentional about the what and the why of your practice.

When we're just starting, we may be so excited that we end up practicing and learning every bit of information that crosses our path. But as we get better at multiple aspects of our craft, it’s recommended to start focusing on the disciplines we enjoy the most, which helps us to become a well-rounded, T-shaped designer.

Learning to Play by Ear

If you have practiced music in the past, you'll sympathize with me that learning to play by ear is anything but easy—especially when everyone around you seems to do it flawlessly, and you feel like you need to level up your game.

When I was just getting started, I dreaded the moments during class when I had to identify the bass inside the songs because I simply couldn't find it. Finding Waldo seemed like a piece of cake compared to that. It took me a while to learn that I had to focus and mentally "separate" the instruments in the songs to find the elusive sound of bass, but I finally did. Separating the sounds of each instrument helped me to overcome the challenge of taking full songs for which there wasn't any sheet music on the internet (now, I bet there is) and learning to play them completely by ear.

Having a problem-solving mindset is not that different. At the beginning of our careers, we rush to provide a solution right after the client has spoken during a kick-off meeting. We take each new piece of information as a clear path to producing a solution as soon as possible, sometimes even during the meeting itself. Been there, done that.

But what if we switch our approach, and instead of rushing to find the solution, we focus on listening carefully to ask the right questions? Methods like asking the four Ws and the five whys help us frame the real problem before jumping to conclusions that more often than not won't be informed enough.Take inspiration from the Double Diamond method: aim to design the right thing first and then design the thing right. Otherwise, we could end up wasting time and effort on making the elevator faster instead of making the wait feel shorter.

If I had only one hour to save the world, I would spend fifty-five minutes defining the problem, and only five minutes finding the solution. -- Albert Einstein

Embrace the Uncertainty and Learn to Improvise

If there was one thing that made me even more nervous than identifying the bass, it was improvisation. How is one ever prepared to hear the unknown spontaneous sounds of the band, find the perfect timing and play something that has never been heard before but by some miracle is perfect for the unwritten song?

I didn't exactly take a class on improv, and every time someone on the stage improvised, it seemed as if they had it all figured out. But what if I told you that's not the case—that they have no idea at the beginning of the song when they will take the spotlight and what the solo is going to sound like? Let's switch to Product Design, and I'll share my own experience with uncertainty.

It is a truth universally acknowledged that every new project will be different from any other you have done in the past—not only the project but also the client, the team and the solution. There's no one-size-fits-all, and the only way for you to succeed in such ambiguity is to improvise, adapt and overcome. Regardless of the lack of predictability, these are three guidelines I have used in the past that can help you navigate unknown waters:

1. Use past experiences to inform your decisions about methods, processes and solutions, making each new project with shared circumstances easier to solve than the previous one.
2. Develop your creative intuition every day with references from real products, using them as inspiration the next time you need them, even if the industry or the platform is different from the one you're working with.
3. Leveraging Vlad Georgescu's words, “Perfect is the enemy of something that actually ships,” don't be afraid of testing something that isn't perfect. Everything that you put in front of the users will provide you with valuable feedback to iterate and improve.
   

To dive a little bit further into the topic of ambiguity, Julie Zhuo recently shared a fantastic Twitter thread with practical steps to deal with uncertainty in Product Design. Her advice can help you to be intentional without getting overwhelmed.

https://twitter.com/joulee/status/1390160651599843344

Despite all the difficulties of the journey, a couple of years after I started learning music, all my efforts paid off, and I was able to improvise with my Strat on stage. It required the conjunction of longs periods of practice, a high amount of feedback, learning to play by ear, letting go of my fear of improvisation and most definitely blending the sound of my guitar with the rest of the band.

Music is a unique experience hard to put into words. It changed my life forever. Getting lost inside of many songs made me see everything in a new way. When I played a solo, I was never sure where it would lead me, but the end now reminds me of how it would feel during the release of the many products I've worked with: triumph.

And I wouldn't be doing the title justice if I didn't share one of my favorite movie scenes ever—one that perfectly describes the way I feel when I'm trying to solve a design problem way before it appears on a digital screen. Let's enjoy the uniqueness of the challenges ahead of us because the outcome will certainly be better than what we expect.

https://www.youtube.com/watch?v=sduYNx92_go

In building Damn Good Digital Products (DGDPs) for a living 😜 I come across a lot of innovative ideas by young entrepreneurs wanting to change the world. Some are viable, some not so much. I think the question of our day (in software at least) should not be “Can it be built?” but rather “Should it be built?”

I was recently pitched an app idea by a non-technical founder. In his mind, the app would solve a painful problem for bikers--passing others.

His idea in a nutshell (details modified to protect the original idea)--a Bluetooth enabled app that bikers could install that would alert a rider if another rider wanted to pass.

A dozen red flags came to mind immediately as I heard this pitch:

• Mass adoption required. Every rider must have the application. On multi use trails this will require every hiker, dirt biker, mountain biker and equine rider to have the application. If <100% of people on the shared trail are not actively using the application, a false sense of security could lead to terrible accidents.
• Geolocation limitations. How accurate and responsive can gps and bluetooth be? How does it know the users are approaching? Ever had an annoying problem making bluetooth connections? Me too, sometimes it's frustratingly janky. Is the other party a companion or a stranger in danger.
• Liability. It will be difficult to charge a high price for an application that requires near universal adoption. And at the same time, if the application fails to prevent an accident the injured party may seek to be compensated. The business will be buried in lawsuits.

Why was the founder so passionate about his app idea? Because he had a classic case of “Falling in love with the solution, not the problem”. From my experience, this is the number one reason that tech startups fail. An inability to find product/market fit paired with a fixation on a particular solution or technology.

You’ve got to start with the customer experience and work backwards to the technology. You can’t start with the technology and try to figure out where you’re going to sell it. -Steve Jobs

Fall in love with the problem and solutions will come. Free yourself to be creative and innovative in finding the right solution, which might not necessarily be the sexiest but will ultimately be the best for your customers.

Laura Escobar and David Haynes are colleagues at Ravn who enjoy reading nonfiction and posting book suggestions on our internal Slack channels. The two recently discovered Hamilton Helmer’s book 7 Powers: The Foundations of Business Strategy. Although 7 Powers received little recognition when it was first published, many in the business world now herald it as a hidden gem. With numerous favorable reviews and 4.6 stars on Amazon, Helmer’s unique business guide earned a spot on Ravn’s bookshelf, and Laura and David were eager to pick it up.

As it turned out, our resident bookworms enjoyed the venture. They found 7 Powers to be a compass to understanding the practical strategies of power that enable a business to unlock differential returns. We asked them to share a conversation about what they learned on the Ravn blog. For context, Laura leads the UX/UI design team, and David is a partner at the firm.

What follows is a summary of their conversations about the book and its use within the domain of digital product design.

Laura: David, let’s start with a question I enjoy asking colleagues. How would you explain this book to a five-year-old?  

—David chuckles—

David: That's a very good question. Perhaps an analogy about people will work for our fictitious preschooler. Companies are like people: each is unique. And, like it is with people, some differences are important. The writer of the book shares 7 powers (like super powers) that help companies to be strong and live long lives. He wants companies to learn and use these powers so they can stand out against other companies.

Laura: You know what I'm glad about? I’m glad you finished the book first and mentioned that the math equation parts of the book are not vital to understanding the framework. Although I did enjoy math during elementary school, I find it unnecessary when you're just getting started on business strategy. I think the equations may scare off readers who are not so patient when entering unfamiliar territory.

David: The math sections felt like an addenda to elevate the gravitas of the author’s thoughts. I like quantitative analysis, but these sections served little purpose. I am glad you skipped them.

So, Laura, what was the most meaningful part of the book for you?

Laura: By far the revelation of how power is achieved: the dynamics of power. I often hear comparisons like “X company is better than the others,” but what I truly want to know is how to become company X, and then guide business projects to success.

David: True, the book promises that a business with 7 easy-to-understand characteristics will be strong and lasting. This is exciting because it seems achievable. I thought it was an excellent summary of how to evaluate a business strategy and improve it. The author makes strategy formulation accessible and systematic. It is a perfect primer.

Laura: What made 7 Powers stand out for you?

David: The book is relatively short (about 200 pages), offers credible and relevant examples and is understandable by a layperson. And, perhaps best of all, it does not use unnecessary jargon.  

Armed with the knowledge and insights from 7 Powers, Laura, what would you do differently in your work at Ravn?

Laura: I'm a product designer, and my clients are usually trying to build software applications to advance strategic initiatives. These initiatives are part of larger business strategies. With this wonderful introduction to business strategy, I'll definitely be more attentive to the stage of the business I’m working with and how the software they’re trying to build fits into the big picture.  

At Ravn, we often work with young companies. At its early stages, a company is fast-paced but vulnerable in many ways. You could say it is on a power prologue, and so every decision it makes should be intentional towards the goal of achieving power. 7 Powers provides a solid foundation to ensure the company is constantly moving toward the desired destination. Every case is unique, and strategies should be addressed properly for each client, but businesses must also be going somewhere—dare I say it—powerful.

You mentioned something about this book being a good introduction to strategy, David. Can you recall a time before you read the book when you used the principles shared by Helmer?

David: Absolutely. I have used many 7 Powers concepts prior to reading the book. I believe it was Isaac Newton that said if he had seen further, it was by standing on the shoulders of giants. Helmer also stands on some powerful shoulders, like those of Michael Porter, Peter Drucker and Clayton Christensen. I have profited from the work of these authors for decades. I see 7 Powers as a work of synthesis, organization and communication more than a product of ideation. Almost all of the concepts presented in the text have been well-discussed by business academicians. The book’s most prominent characteristic is its ability to communicate semi-complicated concepts with brevity and clarity. In this respect, it is an excellent and highly recommended text.

Laura: Did you see any weaknesses in the content?

David: I take issue with Helmer’s view that operational excellence is not a power. The reason he offers is that operational excellence is easy to copy. My experience would strongly suggest that operational excellence is, in fact, very hard to reproduce. The vast majority of commercial exchanges have discontinuities and suboptimal processes. Many firms have successfully used quality as a distinctive advantage. I believe operational excellence is very powerful, and Helmer’s arguments to the contrary are not persuasive. Further, although he emphatically states that operational excellence is not a power, his process power approximates the value of operational excellence. I wonder if perhaps the book should be retitled 7+ Powers.

I also felt the seven powers (scale economies, network economies, counter positioning, switching costs, branding, cornered resource and process power) came up a little short because too many powers were offered as if your company were alone on an island. This seems like a weakness in Helmer’s framework. Every strategic decision should be made in relation to other companies or the competitive landscape. For instance, Michael Porter’s classic, Competitive Strategy, is hyper-aware of the interdependence of companies, regulation, suppliers and customers.

Laura: I see where you’re coming from. Although counter positioning considers the competitive environment, I think it’s the only one of Helmer’s powers that is dependent on the actions of other companies.  Hmm . . . this is a bit of a problem, isn’t it?  

With that being said, I thought counter positioning was complex and fascinating. With counter positioning, a business can adopt a model that its direct competitors will find difficult to imitate—an attempt to do so would contradict their own singular positions. Netflix versus Blockbuster is a wonderful example offered in the book. Blockbuster could not follow Netflix into streaming for fear that it would subvert its own business. It was quite the conundrum. In chess, there is a word—zugzwang—that describes when no possible move increases the strength of your position. Blockbuster couldn't do anything to counterattack Netflix that wouldn't reduce their own established power in the short term. It was by all means a brilliant play.

David: All things considered, do you recommend the book?

Laura: Without a doubt—especially to UX designers looking to dive deep into the business side of product design. It wasn't long ago when I realized that in order to share how design creates a tangible impact on the bottom line, I must learn how to speak the language of stakeholders and business partners. Most designers might see their work as a nice addition to the branding identity and service they provide customers, but its true potential, though often overlooked, is so powerful.

True human-centered design isn't only about a desirable product: it should also take into account technical feasibility and viability from a business perspective. By identifying not only these fundamental power types but also how and when they can create a competitive advantage, product designers become more valuable allies in developing new business opportunities. 7 Powers definitely broadened my perspective on software application design.

David: It is a profitable investment in time. Highly recommended.

In 1996, a mischievous physicist named Alan Sokal sent a fraudulent article for publication to an academic journal, The Social Text. The submission lacked serious rigor and included paragraphs like this howler,

Secondly, the postmodern sciences deconstruct and transcend the Cartesian metaphysical distinctions between humankind and Nature, observer and observed, Subject and Object. Already quantum mechanics, earlier in this century, shattered the ingenious Newtonian faith in an objective, pre-linguistic world of material objects “out there”; no longer could we ask, as Heisenberg put it, whether “particles exist in space and time objectively.”

Despite the complete nonsense, it was published.  Sokal’s hoax punctured the veil of pretend academic rigor and highlighted the power of complex but meaningless language to obscure and misdirect.  This famous incident is known as the Sokal hoax.  If Sokal had chosen to use plain language, the lunacy of his paper would have been apparent but instead he used a complex tangle of words designed to manipulate the academic reviewers.  The experts assumed he had something meaningful to say because it was hard to understand.  They were fooled by complexity.

Unfortunately, complexity entices us.  The human preference for the complicated is called complexity bias.  It's a logical fallacy to believe that the complicated is better than the simple but we consistently lean toward over wrought explanations and problems.  This can be seen in our use of excessive jargon, knotty math formulas, silly conspiracy theories or the delight when observing a Rube Goldberg device.

Perhaps complexity signals desirable traits like intelligence. It’s a case of demonstrating capability through immersion in the complicated.  A way to communicate to others that you are uniquely capable. This is a plausible explanation for the siren song of complexity but in the domain of software development the fascination with the complex is completely wrong.  Why?  Because it is not too difficult to make the simple complex.  It is difficult to make the complex simple.  

“Any intelligent fool can make things bigger and more complex... It takes a touch of genius --- and a lot of courage to move in the opposite direction." – Einstein

The truth is that it is simple designs and construction that signal wisdom, understanding and industry.  It is simplicity not complexity that demonstrates competence.  Good design and code is logical and parsimonious.  It is easy to understand.  It uses what Nassim Taleb calls distilled thinking or “thinking based on information . . . that is stripped of meaningless and diverting clutter.”  It is rarely complex.

When crafting or evaluating UI designs, UX flows, architectural diagrams, migration plans and software code elegant simplicity is the mark of excellence.

At Ravn, we believe that before work product can be reusable, testable, scalable and extensible – all core characteristics of proper deliverables - they must first be understandable.  

“I would not give a fig for the simplicity this side of complexity, but I would give my life for the simplicity on the other side of complexity.” – Oliver Wendell Holmes Junior

What do you mean M . . . V . . . P

The term Minimally Viable Product (MVP) is wonderfully self-explanatory and refers to a product with just enough features to be usable and provide feedback from actual customers. It is often employed when a startup wants early real world market feedback or as the starting place for an iterative process of development.

MVPs have helped to deliver many of the innovative software applications in use today.  (Amazon, Facebook, Dropbox, Uber, Twitter and many others started with MVPs)  It draws from scientific method: observation, hypothesis, test and iterate. This virtuous circle of improvement has delivered nearly all of man’s notable advancements.

What could be better?

Well . . .

Like many powerful ideas, the process has been claimed, extended, shaped and renamed with vigor over the two decades since it was first articulated. Some of this work is high value while other might be best described as social engineering. I will share a few thoughts of our real-world experience with MVPs but first I should introduce some related terms such as mVP, Mvp, MaxDP, MinDP and SLC.

At the risk of not properly explaining these concepts, here are brief descriptions.

·       A mVP places greater emphasis on the viability of the product and is usually more feature rich and built to scale than a traditionally defined MPV. However, it must still be iterated over time to reach its full potential.

·       A Mvp is a very light weight application ready for investors or a small subset of the addressable market. It is often employed when a startup does not have adequate resources to build a more complete initial release.

·       At the zenith of terminological inexactitudes, the MDP is used to define both a maximally delightful product and a minimally delightful product.  To reduce confusion, it can be noted as MaxDP and MinDP.  A maximally delightful product is a robust differentiated end-stage release. It is the antithesis of an MVP.  Superhuman is notably using this approach.  A MinDP is a rephrasing of MVP to focus on a highly pleasing user experience.

·       An SLC or “slic” is a simple, lovable and complete product.  SLCs tend to fall between MVP and a MaxDP.  We see SLCs from well capitalized efforts to build a MVP.

An important common attribute with an MVP is the recognition that any undertaking is a series of tradeoffs.  The necessity of tradeoffs is well captured in the classic engineering giggle: “Cost, Time and Scope.  You can pick two.”  Although there is no doubt that a high-performance team can reduce tradeoffs, prioritization is unavoidable.

A lamentable limitation of the MPV is the burden it places on early adopters. Potential evangelists for the new application are dragged through development cycles where the product never seems quite right. This is a manageable problem with a distinctive product and a sticky user base but it can decrement goodwill at a remarkable rate. When an MVP starts to show substantive acceptance, substantial investments are required to quickly improve the application before your customer’s goodwill bank account is overdrawn.  Early relationships with funding sources can be very valuable.

We speak with entrepreneurs that often simply do not have the funds to build an MVP.  Their desire is to build a very minimally viable product or Mvp.   Of course, this is a difficult tightrope walk. We often recommend deeply capital constrained projects start with a clickable prototype that can be used to help secure funds.  In this way the marketplace hypothesis can be properly tested when sufficient funds are available to construct a more complete application. If the application is reasonably complete and it fails in the marketplace, was the failure due to unviable application or a lack of marketplace acceptance? You will not know and this is a serious research design failure.

“A job well begun is half done.” is a quote attributed to both Mary Poppins and Aristotle so it should be given proper consideration. Investing time and treasure in the design phase of an MVP can pay considerable dividends both because the application will offer a reasonable user experience and it will be better prepared for the follow-on effort to scale and extend the feature set. We have found that design is best viewed as a distinct prerequisite task for a successful application build. Absent this important milestone the UX/UI is crafted real time by the entrepreneurs and engineers. Those smiling at the aforementioned statement have demonstrated their wisdom through experience.

Successful new products tend to be the outcomes of excellent craftsmanship not a production process. There are few easy answers that work in all circumstances. Although we can share many experiences and rules of thumb, successful projects are delivered by capable and aligned teams. Team members with relevant and varied experience with early stage application development are an invaluable asset. Call us if you would like to discuss how to best bring your ideas to market.

Google reports that they will now accept relevant certifications as loosely equivalent to a four year degree.^[1] They primarily frame this initiative as a means to increase inclusion. Since my profession would benefit from greater levels of participation, their intentions are noted and appreciated; however, the bigger story is that a lighthouse employer now accepts relevant certifications as loosely equivalent to a four year degree. Another brick in the wall between your current reality and full potential has fallen.^[2]

I work with team members that possess a broad spectrum of educational attainment. Is a degree helpful? Absolutely - but more to build a broad base of skill required to navigate in a complex world. Generally, it does not indicate a level of technical proficiency. I have worked with Nx developers with degrees in business, math, literature, music and even geology. If a computer science degree was the best way to build technical skill, entry into the space from vastly differing vectors would not be common.

Many luminaries have persuasively argued that degrees are of marginal benefit as a practitioner of the technical crafts. Thought leaders such as Peter Thiel and Paul Graham have been devastatingly critical of higher education and many of their blows land right on the chin of the expensive colleges.^[3] Increasingly a degree is a signaling mechanism not evidence of a useful set of skills.^[4]

Over the years, I have collected a fistful of certifications and formal degrees. Recently, I completed a few Amazon AWS certifications and can report that this process was more rigorous than past certification programs. No longer is it sufficient to digest and regurgitate a gaggle of technical terms and concepts. The higher level AWS certifications consist of scenario based questions that test both acquired knowledge and complex problem solving skills. They essentially ask the test taker to demonstrate they can do the job . . . by well . . . doing the job for a couple of hours. Obviously, this makes good sense, but by requiring the student to also solve difficult and nuanced problems, they test something broader and highly relevant: general cognitive ability. There are elements of the exam that are similar to college entrance standardized tests. The test evaluates both acquired knowledge and the aptitude to solve knotty problems. When both of these elements are present, the individual is certainly qualified. As qualified as an applicant with a four-year degree? In most cases, yes.

I also expect that the certification process will become an increasingly mainstream means of entering a technology field and maintaining a sharp edge. There is a pack of strong fast-moving technology companies and each firm is looking to be the lead dog. Most of tech has winner-take-all dynamics where if you are not the lead dog, the view never changes. A large cadre of people proficient with a particular ecosystem is a necessary condition for market dominance. Why not open the aperture on the field of available candidates and offer qualified people a legitimate alternative path to demonstrated competence? AWS, Microsoft and Google have the resources and motivation for continued success as a college alternative.

At Ravn, we use a set of our proprietary technical tests to evaluate our candidates. Although we believe degrees and certification have merit, our focus is squarely on the ability of the candidate to demonstrate real world skill that can be employed by high performance teams. The artifacts of prior accomplishment are considered as a part of a wholistic examination of a potential team member but our focus is on how much wood can the applicant chuck.^[5]