With the network of devices expanding and becoming more commonplace in daily settings, the interconnected “world of the future” is shaping up around us. And it’s this rapid IoT transformation that’s paving the way for new innovations and possibilities — as well as fresh competitive advantage for brands who jump on board.

The marketplace is primed for IoT

To be clear, this surge in IoT interest is by no means an accident. Careful advancements, launches, and adoption rates have led to this sustained growth for the IoT marketplace. Below are a few of the key factors that have made IoT opportunities possible. 

5G is everywhere

With massive companies like Apple embracing IoT innovation and bringing it to the masses, it’s only a matter of time before 5G technology and its possibilities become mainstream. That’s because several aspects of 5G make it an excellent catalyst for IoT.

For one, 5G allows for far faster, more widely available mobile connectivity. This is crucial for many IoT deployment cases. And as more people move to 5G networks and leave current LTE and 4G networks behind, there will also be more low-power network bandwidth available for IoT devices. 

Equally as important, 5G’s high-data throughput allows for more complex computing to happen over telecom networks. This will pave the way for more intricate IoT solutions, akin to what we’re used to on personal computers. 

People are getting used to the concept of IoT

Another factor helping to push IoT tech forward is the normalization of IoT. Smart speakers, digital automation, and smart home devices have all started to penetrate the market in a significant way. 

It’s been slower than some may have predicted, sure, with many of these devices having existed for more than five years. But that can’t take away from the fact that market adoption is happening on a massive scale, especially among older Millennials (the 30-44 age group leads the way for use of smart TVs, smart speakers, smart security, and more). 

The global pandemic has likely played a large role in adjusting people to the idea of hyper-connected services and devices too. Who hasn’t depended on digital-first services to get food, interact with loved ones, banking, telecommute to work/school, or speak to a healthcare provider over the last year? 

This is likely driving the normalization of IoT innovation at an even faster pace, which is a net positive for the industry as well as individuals. 

There is more data and data-sharing than ever before

Thanks to the increasing adoption, we’re seeing a more data-centric and data-sharing world than ever before. It’s not uncommon for a business of moderate size to have more data at its disposal than it is capable of parsing through without machine learning. And individuals are now expecting services to not only have an online platform, but to work seamlessly together with other solutions at all times. 

This data renaissance both creates a platform for, as well as necessitates, IoT technologies. It’s creating the opportunity, driving consumer and enterprise demand, and posing a problem that only IoT, AI, and ML can solve. 

What does IoT innovation look like in practice?

Alright, so IoT innovation is growing in popularity, just as it’s been predicted to since its inception. Now, it’s time to look at this technology in practice. 

Recently, the team at Cheesecake Labs had the pleasure (and challenge) of developing a one-of-a-kind IoT solution: THAW, a product of  Alliance Consumer Group. 

Here is how our experience developing this IoT product went. 

THAW: A unique footwear solution

The premise behind THAW is simple: create a heated in-sole device for shoes. The in-soles connect to an app, allowing the temperature of the wearer’s shoes to be controlled manually and automatically. 

If you’ve ever been out hiking, mountain biking, skiing, fishing, or hunting when the temperature drops, then you know how quickly cold feet can put an end to your fun — and that’s the problem Thaw looks to solve. Using the app, the user can control how warm their shoe’s in-sole is and what times it turns on. 

How IoT took this idea a step further

Of course, this isn’t much of an IoT idea just yet — it’s still a really neat way to stay warm, but the connections aren’t there to call it IoT. So Cheesecake Labs partnered with the THAW product development team to take this concept a step further. 

We worked with THAW to integrate current weather reports into the product. This way, the device will not only turn on when it’s told to by the user, but it can also notify the user when it should be turned on (after the weather drops below a certain point). Likewise, we also implemented a notification system so that the user remembers to charge the device whenever the weather is getting colder. 

The challenge of THAW’s IoT

THAW isn’t just one device, it’s two (one for each sole). That means that both devices need to not only be connected and responding to the user’s input, but they need to be doing so synchronously, all of the time. 

And yet, we also wanted the user to be able to specify distinct settings for each in-sole should they wish to. Whatever we built needed to work synchronously and asynchronously; back and forth whenever the user desires. 

Using Flutter to make this IoT vision a reality

Conceptualizing how the app needed to work and the integrations it needed to have was just Phase One. Then we needed to come good on our ideas! To do so, the Cheesecake Labs team turned to Flutter — the development framework powering many of the world’s best apps.

Here’s why:

You can write for Android and iOS simultaneously

With Flutter, you can write your application’s code once and deploy it to both Android and iOS simultaneously. When you consider all the variables of an IoT application — plus THAW’s double-device challenge — this offered a huge benefit versus native development.

Cross-platform development isn’t always the right approach (see our comparisons of native vs cross-platform apps here) but for IoT innovation, it’s a great fit.

Flutter is headed by Google, who wholeheartedly believes in IoT

Google is a firm supporter of IoT, evidenced by the fact that Flutter not only works with Android and iOS but also desktops and embedded devices (like Thaw). Likewise, Google recently began developing the Fuchsia OS, which is aimed to deploy on a wide array of devices (not just the traditional smartphones and desktops we’re used to). 

There is a pre-existing library of tried-and-tested modules

Finally, Flutter comes with a vast library of tried-and-tested modules. This allowed us to dramatically speed up and simplify the development timeline of this project, while also mitigating risk.

Ready to dive into your own IoT development cycle?

The Internet of Things presents incredible opportunities for both consumer and enterprise applications — and we’re not just talking about years in the future, either. The time to start thinking about IoT innovation for your business is now, and Cheesecake Labs can help. 

Reach out today and take your IoT journey on its first (or next) step. 

“>

The post IoT innovation: what’s behind the rise of IoT & how CKL approaches IoT development appeared first on Cheesecake Labs.

Utilizing this process ensures an app meets — and often surpasses — the expectations of our clients, their stakeholders and, most importantly, the users.

In the first installment of this blog series, we explained how our first phase — Product Definition — helps set the stage for successful design and development. Now it’s time to look at Phase #2: Product Design. In this guide, we’ll explain how the Cheesecake Labs team approaches application UI and UX design — and why that unique approach delivers real value to your business.

Designing delightful digital experiences for your users

Phase #2 is where the pieces of your idea really start falling into place. Until now, the vision for your app has been mostly conceptual — all the evidence is there to say it’ll likely work in the market, but you don’t necessarily know how it’ll look and feel.

By the end of this phase, you’ll have a clear understanding of what the app will look like, how much it’s going to cost to build, how long the development process should take and — crucially — how users will interact with it once it’s in their hands.

Your users are our core focus during Design. A technically-great app is that and that alone. It has no purpose. For a mobile app to be a success story, the users need to love it and to want to engage with it. That’s what we aim to achieve at this stage of the journey.

It’s worth noting that you don’t need to have undergone the Definition phase of our three-phase methodology to jump straight in at the Design end. We’d recommend it, but it’s not essential. Perhaps you’ve already done a lot of the strategic thinking and user exploration that’s required to design a stellar digital experience — we’re happy to pick up where you left off or bring you up to speed and fill in the gaps.

At the end of the day it all comes down to mitigating risk and delivering value. Even if you’re starting with Design, we’ll work hard to stress-test your app idea throughout the process — our QA team will be on hand to assess the tech and our developers will be briefed and ready to take the reins.

And let’s say you then decide to go in-house with your development or to commission a different agency for the build, we’ll still make ourselves available for briefing and trouble-shooting, to ensure a seamless transition and a successful outcome for everyone.

What happens during the Cheesecake Labs Design phase?

Every project, and every client, has unique needs. We might be called Cheesecake Labs but we don’t deal in cookie-cutter ways of working. And that’s why we always focus on what you need — not what our last client wanted.

Our preference is to work side-by-side with our clients; chatting frequently within Slack and hosting key, weekly meetings to share progress, check direction, and reaffirm that the app is working for its audience. Collaboration isn’t just part of our process; it is our process.

That’s why the first thing we do during the Design phase is to get everyone on the same page. Perhaps we’ve worked together on Product Definition already and simply need to recap. Or perhaps there’s a more significant alignment that needs to take place. Either way, we’ll start by (re)asking:

What are we here to design, who are we designing it for, and why are we designing it?

This holistic and unfiltered view of the product will then help us validate the ideas and ready them for prototyping.

Producing wireframes

You may be in possession of a few wireframes already, but now is the time to scope out how every screen of your mobile application will be structured. Low fidelity layouts will be designed with optimal UX in mind — the colors, images, and text will all be up for debate, but we’ll commit to the user experience and journey that help users complete their tasks efficiently and with delight.

Are we talking about a radically new interaction or experience for these users? Then we can use our clickable prototypes to conduct a round of initial user testing if necessary. By asking potential end users to walk through the mockups performing “tasks” or “jobs” within the app, we quickly spot opportunities to alleviate confusion. Better now than when your app hits the market.

This is also a great time to introduce our QA team and Tech Lead to the project. QA can spot functions that are potentially-buggy, while your dedicated Tech Lead will highlight anything that seems too good to be true. Validating the tech early — in Design and not just Development — means we know the build is technologically viable. It also saves time during the Development phase, as the QA team will have context and already know what it is they’ll need to test and what is expected from a user experience.

The layouts start to take shape

Next, our UI designers will start adding color and substance. For many clients, this is when things really start to get exciting, as the app comes to life right in front of their eyes.

So we can work efficiently, the UI team will create elements in a design system and replicate them across the app. Your design system will combine a variety of deliverables — such as pattern libraries and style guides — to create a collection of reusable components that reflect your brand. These elements can be assembled in several ways to fit each screen, while maintaining consistency and respecting your visual brand language.

We can even start discussing micro interactions, animations and any other extras your app needs. Our intention at this stage is to create a thorough blueprint of everything your application should have to be a success with its audience.

Invest in Design and the rest takes care of itself

By the end of the Design phase, you’ll have a representation of your app that’s as close to reality as possible, without requiring a single line of code. The next step is to take it into Development.

Because our expert dev team will have followed the journey of your app idea up until now, they’re primed and ready to provide a seamless transition from Design to Development.

The deliverables of this Design phase may vary, depending on your project needs, but they play a crucial role in defining a crystal clear brief for the developers to get started, as soon as you give them the green light.

Product Design deliverables may include:

• A clickable prototype, used to showcase the app’s full UX and UI
• A design system, complete with ready-to-use assets and UI components
• Any other documentation that will empower the development team (competitors and references, user personas, meeting notes, etc.)

Armed with the above, the Development team has everything it needs to hit the ground running.

They’ll have helped validate the tech already, so there shouldn’t be any surprises (for you or for them). And your Project Manager will continue alongside right up until your finished app is in your hands; think of them as your success rep, steering deadlines, managing budget, and ensure overall alignment, etc.

The Cheesecake Labs 4-phase, fully collaborative methodology has been tried and tested over the past 8+ years with a high level of success. Other agencies may be keen to jump right in and start coding, but we’re not. We’ve learned that greater value is delivered faster when everything is well thought through.

If that’s an ethos you can empathize with, then contact our team today.

The post Building an app with Cheesecake Labs: Phase #2 Product Design appeared first on Cheesecake Labs.

Will your app have an audience when it reaches the market? Does it align with, and benefit your business strategy? Is there a clear problem being solved? These are the questions you need to ask before you get started.

The Cheesecake Lab secret to success

Fewer than 0.01% of apps succeed upon launch. A failed app doesn’t just hurt the ego. It amounts to countless hours of wasted work, budgets stretched to breaking point and lack of confidence from current and future investors.

At Cheesecake Labs, we strive to build that 0.01%. We’ve designed a three-phase methodology for successful app development: product definition, product design and product development.

Our process ensures the final product not only meets the business, market and user needs, but that it’s the best possible use of your resources. It’s also achieved in total collaboration. We like to think of ourselves as the digital product experts, but you’re the spokesperson for your business. By working together, we’ll make a success of your mobile app idea.

In this article, we’ll tell you everything you need to know about Phase 1: Product Definition. We’ll look at why it’s essential to pause and explore the opportunities before you start building. We’ll also outline what’s involved in this early stage of app development and what you — as a client — can expect to get out of it.

Phase 1: Product Definition – 3 key benefits

The Product Definition phase can be summed up in one simple question: “what are you going to build?”.

Without a clear product definition, you’re guiding a ship through the fog without a lighthouse. You may — with luck — end up where you wanted to be. But chances are you’ll sink.

That’s why we champion the Product Definition stage with every client who comes to us in the early days of their mobile app development. Some other clients may be more evolved in their thinking — they already know how their app will benefit users’ lives and what form their app should take. Those clients need hands on deck to facilitate the build and that’s why they come to us. But there are a number of clients, in our experience, who aren’t nearly at that stage at all.

Other agencies may be chomping at the bit to sign a contract and get building, no matter whether the client is ready, but we’re not. Here’s why:

Product Definition is the smart way to start a project

There’s no shortage of ways to waste money in the early stages of app development — especially if you push ahead without a plan. Building features for feature’s sake creates a lot of unnecessary overhead. Setting unrealistic go-live dates may drain your funds (and team) entirely. That’s not how we do things.

By incorporating the Product Definition phase into our early conversations, we are able to give realistic estimates and a well-defined roadmap before a Statement of Work for design and development is agreed. The Product Definition phase is also costed separately to the rest of the development process. If the app idea isn’t a go-er at this stage, nothing’s really lost. In fact, you’ve likely saved yourself a lot of time and money. Either way, you’ll have a fantastic body of insights to help hone your thinking and ideate again. Go or no-go, this phase mitigates risk.

User-centric design demands Product Definition

Your app needs users. That’s why one of our core objectives in the Product Definition phase is to understand how and why a customer would engage with your idea.

Again, it’s better to know now whether you’ll have traction or not. By taking the time to explore whether users really need your app before costs start adding up, you’ll be able to progress with confidence — you’ll be building with the user in mind, right from the start.

Product Definition aligns the whole team

Collaboration is key when building a digital product. You’ll want your internal teams aligned on what needs doing and when, and you’ll want any investors or additional stakeholders to support your idea as well.

The Product Definition phase helps facilitate that buy-in. Proof of concept acts as a crucial motivator for your teams, while the roadmap provides a structured approach for the weeks and months ahead. Any extra funding required should be easier to obtain too, as backers will know what they’re funding and why it’s worth it.

Does every Cheesecake Labs project have to include Product Definition?

The short answer here is “no”.

Some clients come to us having already done this thinking. They understand the opportunity, have validated their space in the market and are ready to go. But these clients are more often in the minority. Most companies aren’t at that stage, even if they think they are.

That said, if you come to us with confidence and have enough evidence to move forward, we can skip straight to the next step: Stage #2: Product Design.

What to expect from the Product Definition stage

It’s important to remember that there’s no “one-size-fits-all” solution to defining your digital products. Cheesecake Labs isn’t here to take over your process, we’re here to collaborate and offer unique solutions tailored for every client’s needs.

From a top-level approach though, there are the four main steps for Product Definition. And at every step of the process, you’ll be working with senior members of the Cheesecake Labs team — a Product Manager, Project Manager, Tech Lead and a Lead Designer:

Research the business

Your leadership team will have a lot of valuable intel to help steer the Product Definition process. That’s why we interview the key stakeholders, to better understand your business mission.

The best digital products reinforce your brand values and vision — taking the time to hear from your team will help us understand how that can be achieved.

Research the market

Next, we’ll look at what the market needs and explore what your competitors are doing, or more importantly, aren’t doing in this space. If there’s a gap in the market, how can we — as a team — capitalize on it? That’s what we’ll capture in your benchmarking and competitors’ feature matrix.

Market analysis isn’t just about your competitors though. Your ideal customer is a deciding factor too. What issues are your customers facing — and how can you solve them? Are potential customers using other digital products to fill this need today? If so, how can you steal them away?

These crucial insights will feed into your product idea and help it thrive when it hits the market. We’ll help you explore the market opportunities you have and then decide on an app that speaks to that need — not the other way around.

Validate the tech

Our years of experience make us pretty quick at spotting tech with usability issues. But we also need to make sure that your app is technically possible to build.

It’s in this validation process that we’ll begin to map out the frontend and backend of your app idea. How will it work? What integrations may be needed? We don’t want to get bogged down in the details just yet, but there’s also due diligence required before the idea takes shape.

Deliver the Definition

The final step of Product Definition: putting (proverbial) pen to paper.

This is where we lay down the foundations for future development. Having collected all the necessary information, we can build a realistic roadmap for the development process. The roadmap will include time management and financial estimates, allowing you to gauge if the product will be viable with your budget, or if adjustments need to be made. We can work with a set-in-stone budget, designing within those constraints, or we can plan more iteratively — whichever works for you.

A customer journey map is produced to illustrate the target customer’s interactions with your app — conveying the need for your digital solution in their lives. The map will also identify potential problems that may hamper customer engagement to ensure the development stays customer-focused.

Lastly, we’ll also produce some exploratory wireframes and a user navigation flow, so everyone can get a feel for what the product will become. Think of this as an early prototype, showcasing key features, UI design ideas and how customers could interact with the product when it’s live (UX).

Below you can navigate the full prototype that we created for FindHeli on InVisionApp.

Remember that on the Product Definition phase we will not deliver that complete prototype, but:

• Explore and define the user experience for 3 main flows up to 5 screens each;
• Explore and define the UI design for 1 main flow up to 5 screens;
• Create a web-based clickable prototype of 3 main flows;

The definition phase should take 4-6 weeks and will set you up for successful design, development and — ultimately — launch date too. We’ll keep the lines of communication open with you throughout; our job is only done when you’ve got everything you need.

Are you ready to define your opportunity?

Cheesecake Labs has been bringing unique digital products to life for almost a decade and every single product was created upon the same foundation of collaboration, integrity and care.

We are passionate about product definition and understand how vital the process is for apps and other digital products like. Let us bring clarity to your vision. Get in touch with the team today.

The post Building an app with Cheesecake Labs: Phase #1 Product Definition appeared first on Cheesecake Labs.

Having said that, when it comes down to exploring new opportunities that could lead us to innovation, the way we build and tell these stories can lead us to success (or not). But why isn’t that so easy? Because we are programmed with many behavioral mechanisms that prevent us from acting. To briefly illustrate, one of these behavioral mechanisms is the so-called “negativity bias.”

Understanding our bias

Essentially, this means that we are much more likely to focus on the dwell of something that’s gone wrong than on things that have gone well. This scenario has been built by our society and it is intrinsic to our collective unconscious. This is what kept us safe in prehistoric times when faced with situations of danger, but it is not what is going to make us succeed in welcoming new ideas, for example, innovation.

This also has a direct impact on our power to continue improving and bringing transformation to the organizations we’re a part of.

Transformation is one of the most challenging things leaders face. What I mean when I say transformation is mapping possibilities, possible futures that we can materialize, and then successfully overcoming any obstacles preventing us to achieve the desired goal. At Cheesecake Labs, transformation is undergoing, leading us to realign and improve everything constantly.

With that in mind, can we transform organizations and products without transforming people and the way they connect in order to build the future? That’s when storytelling comes to play.

Where to start

I always say that if you don’t know where to start, you should start with the stories. The stories you tell your colleagues, your leaders, yourself. A single-story carries one of the most amazing powers it can have: the power to transform.

These stories may answer meaningful (and strategic) questions: what are the other possibilities? What does the future look like? What problems are you trying to solve? What path makes more sense to pursue in order to reach the desired goal? I’m always asking myself: how can we write better stories together?

A single-story has the potential to explore new possible futures, explain the strategy required to get there, and attract other people to make it happen. Stories have the potential to motivate an organizational transformation, and that means innovation!

Effective storytellers can reach the golden spot to innovation: engage people to embark on this new idea/product/future, and all of this is done in a structured way.

Essential elements of a strategic narrative

I believe that a great story includes the human context (what will be done and by whom), the shared purpose (why do you want others to embrace this story with you?) and what makes the story unique (the desired outcome or the possible future that you envision). It is not only the outcome that makes a story unique but also the journey itself.

To illustrate how you can act hands-on, I’ve used Friends TV series episodes as an example because it is the greatest tv series in the whole world! You can also check this great book as a reference as well as other frameworks.

The Arc

The narrative arc is a term that describes a story’s full progression. It visually evokes the idea that every story has a relatively calm beginning, a middle where tension, character conflict, and narrative momentum builds to a peak, and an end where the conflict is resolved.

You may already be familiar with one classic example of the story arc: a startup idea, a challenging beginning, reaching success. This may sound oversimplified, and it is. Adding complexity to a basic story arc is part of what differs one story from another, even when they’re ostensibly dealing with the same ideas.

On a daily basis routine, this means I may engage my team in new projects using the arc narrative. First I give them specific information about our new partners, their interests and settings like: who and where are them? What do they feel about this product? How did they get to us? Having said that, I climb up the story with the wrinkles: what problem do they want to solve with this product? Which pains and frustrations do they have? With that in mind we can reach the climax with the team’s purpose on how they can help it and all the skills needed to deliver an excellent product. The falling action (resolution) is the part of the story we’ll write together.

The Hero’s Journey

Monomyth (also called the hero’s journey) first described by Joseph Campbell is a story structure found in many movies and tales across the world.

It’s an adventurous and challenging journey of a Hero, who moves from certainty to uncertainty and returns safely with reward. For this article’s point of interest, “hero” can be a disruptive idea that is born through uncertain conditions as we know it (this point in human history is a great example) but has the power to bring extraordinary and reliable results (reward).

As an example, I’m using one of Friends episode to illustrate the Hero’s Journey structure as follows:

Science Fiction

Science fiction is a great tool to inspire thinking about new and possible futures in addition to the impact of technology on human lives. Silicon Valley has a deep connection with Science Fiction (as an example, the book Fahrenheit 451 written in 1953 inspired earbuds creation).

Imagine the future 5 to 10 years from now. Consider real-life problems using technology. Think about the stories behind it. Write about it. At this point, do not worry too much about how it’s all going to happen. Just take the time to think about the future. As described in “Leading Transformation“, from this point forward, a multitude of options will present itself. Once that is achieved you will be able to write a strategic narrative about how the future could be. Use the arc or the hero journey (the user) with a dilemma (a real-life problem) and a resolution.

We may explore possible futures using the power of science fiction. Science fiction can be used as part of a product creation process. With Sci-fi, there are no boundaries. Out of the box thinking is not only allowed, but encouraged. We can create little scenarios or even larger dramas to integrate the product we’re building into a narrative that is engaging and aligned with the product’s purpose.

What is your setting (time)? The future, an alternative timeline or historical past that conflicts with historical background? Where does the story take place? Outer space, other worlds, or alternative versions of the earth? What are the narrative elements? A new technology, a new product, a new scientific principle or a new political system? These are some of the questions to start creating a Sci-fi narrative. Explore. Dream. Discover.

Storytelling as a Project Manager

I consider it crucial to question ourselves how we are telling the stories about our efforts towards innovation. We need to realize the power of stories and embrace the fact that it is determinant to our efforts to succeed.

Conversely, as a Project Manager at Cheesecake Labs, I’m constantly challenging myself considering the team’s unique perspectives in a positive manner, using these tools (science fiction, the hero’s journey, the arc) as I see fit. It is important to maintain a continuous conversation about the products that we are building – we are always trying to ask as well as answering the right questions together in order to build it meaningfully – truly adding value to our partner’s businesses and Cakers. We believe in the stories we’re writing while developing products, always keeping the drive to help build successful tech products that solve real-world problems.

Working together through the stories, the best way possible – this is how we bring innovation to the table.

References

Fahrenheit 451
Leading Transformation
The hero’s journey

The post Storytelling your way to innovation appeared first on Cheesecake Labs.

Having said that, I wanted so much to contribute to this project!

In the end, I came up with a pretty good solution for a better understanding of game mechanics and goals, applying product thinking and storytelling techniques. I called the Game Design Canvas.

Game Design Canvas Workshop

Thanks to Barbara Cabral, GDG community member, I was able to facilitate a workshop talking about the project and about the Game Design Canvas I created especially for this challenge. The result you can check below:

Since this challenge was for girls between 15 and 21 years old, I thought it was very important, besides the parts of a game that makes the game what it is (goals, resources, and powers, mechanics), to focus on the Learning Journey: will the player be able to develop analytical skills or maybe think about different strategies? We often think that games bring no learning at all but we might end up finding that every game does bring a learning opportunity after all.

During the workshop I also presented two games translated into the canvas (thanks to Lucas Popenke, our iOS Cupcaker – you rock, Lucas!) that you can check below: 

Candy Crush Saga Game Design Canvas

The Sims Game Design Canvas

About the Game Design Canvas

The Game Design Canvas contains building blocks to create a game – and not necessarily all of them will be populated. It is just a fun and visual way to help consider all the key aspects of a game – the product thinking way – considering the player first (character, in what world will be in, learning journey), job to be done next (goal and how to overcome obstacles) and finally the output required to make it happens (mechanics and resources and powers related to it).

Here at Cheesecake Labs, we believe that in order to create the utmost value with a product (in this case, a game), we must think about what you can do with the game much more than what the game can do for you — it sounds the same, but they are completely different approaches.

The Sims is not providing you the ability to play a game — it is making it possible to live the life you perhaps wanted in the real world, plus knowing how it will turn out after some time.

I hope that this mindset inspires you to research further about Product Thinking and empower you to build more meaningful games and consequently, products. 

The power of stories

When creating a game, no idea should be put away until they’re sure about which story they would develop for their game. The girls were able to consider several opportunities and stories to be written based on the canvas and how the building blocks were structured.

I hope you can use the canvas to generate insights in your endeavors. 

The post Game Design Canvas for Google Play Challenge appeared first on Cheesecake Labs.

There are great articles out there about Product Thinking, like this one, but no canvas that brings together all the main questions Product Thinking focuses on.

With that being said, I took a stab at it and created one (there is a tiny possibility others are looking for something like this but never found it).

The result you can check below:

The Product Thinking canvas tackles user first (problem + target audience) followed by job to be done (vision + what you can do with our product + strategy) and finally the goals to be achieved and which features will ensure the product meets them.

The heart of the canvas is: what you can do with our product because this sentence impacted me profoundly:

“Here’s what our product can do” and “Here’s what you can do with our product” sound similar, but they are completely different approaches.

— Jason Fried (@jasonfried) November 13, 2013

As an example to materialize this sentence, we can state that Uber is not providing an app; it’s providing the possibility of connecting riders and drivers, anywhere, anytime.

Along with the fact that Product Thinking focuses on resolving real problems, it also opens up the opportunity to build products that can help us faster, that have the ability to know us more and surprise us whenever possible.

I hope this post inspires you to research further about Product Thinking and empower you to build more human-centered, product-oriented and business-relevant products.

The post How I created the Product Thinking Canvas appeared first on Cheesecake Labs.

So how about having a seat and staying in the room? To have a seat nowadays, a brand should have feelings and opinions, not just sell itself. Otherwise, it will have to leave the room. That’s what we call Branding Experience.

Brand Experience is the set of feelings and experiences that consumers have with a brand. From a query to a purchase, the potential customer tests the company’s ability to attract him and show reasons for him to complete an order.

And more than that, it is fundamental that today a brand does much more than simply sell itself. Yep, we are all tired of the old advertisement. And we demand that brands to strive and to deliver brand experiences for us. We need identification with the ideals of brands so we can defend and support them.

Technological innovations are redefining personal habits along with the emergence of gadgets, applications, social networks and other digital products. In this environment, brands are no longer fixed concepts. They are always the result of a work done in several hands and over which a company has no longer total control.

Ok. So you are already tired about the huge amount of hard work to do?
Do not give up, now it’s time for some tips.

Branding experience: how to make it happen.

Here’s how the consumer nowadays wants to receive ads: in places that they are not prepared to receive it. They really value offline. I know, it sounds like contradictory in our digital era, but it’s not. Consumers want to be surprised, so they are demanding brands to be more creative. Go to their work, go to their houses, go to their parties. And take care: do not to be invasive. Promise not to be boring, ok?

Brand experience is about building affective bonds connecting ideals with your consumers. So how about dropping the sameness and looking for punctual actions that might be harder to build (maybe more expensive), but that mark the life of the client? We are talking about invest in actions that “look like and event” for your brand. Attractions in the middle of street, attractions in the middle of the concert, powerful stuff like that.

Another tip to create an awesome brand experience is to invest in sensory experiences with customers that play with touch, smell, sight, taste and hearing of them. It will be remarkable, for sure. You shouldn’t be happy only about giving something for free to your consumers, give them a new learning, a new challenge to discover, a new environment to immerse. Think of the smell your brand may have, think of the taste it can have and give them all this experience.

No one is better than this guys to prove that.
They are not just a drink, they make music, they connect the city and they make you live things you never thought.

And then.

You better know that the work will never end. Investing in social media advertising means nothing after this impact experience, it will be only the bare minimum. Take care, experiences vitiate both the brand and the consumers. You can be sure, if you thrill and amaze your consumers, they will resonate these ideas for a long time with other people, becoming “brand lawyers.” After all, who is more expert to talk about the brand than someone who has been there and already had the whole experience you have given.

Yes, no one is safe today. In no time consumers can talk well or badly about any channel they want and make people hate brands. But the last tip I give is that it’s not worth fearing.

You must surrender and give as much as they want: Awesome Brand Experiences.

The post Branding Experience: the coolest way to talk appeared first on Cheesecake Labs.

I have recently had the opportunity to work on a new product from scratch made in React and PWA with the well-crafted and componentized UI at Cheesecake. However, when we discussed with the whole team the best way to approach the development, we ended up having the same old problems that have happened in most past projects, such as:

• Lack of Styleguide of components;
• Lack of precision in estimating development time;
• Great amount of setup time for developers;
• Inconsistency between components and view;
• Repeated code;
• Side effects;
• Very specific components to each pages;

We’ve started to build the CSS architecture using the ITCSS methodology that organizes the style files on stacks from generics styles to the specifics ones, which helps you to scale large projects easily. But along with ITCSS, we were using CSS Modules to scope the components, so we noticed that component stack was getting huge and even the generic styles were being componentized and reused within other one.

That was the moment in which we paused to rethink our architecture and how we could set the components in a more distributed and organized way. Then we found a methodology called Atomic Design that creates multiples stacks of components, with different hierarchies of complexity and dependence.

What is Atomic Design?

Popularly known within the design world, Atomic Design helps to build consistent, solid and reusable design systems. Plus, in the world of React, Vue and frameworks that stimulate the componentization, Atomic Design is used unconsciously; but when used in the right way, it becomes a powerful ally for developers.

The name Atomic Design comes from the idea of separating the components in atoms, molecules, organisms, templates and pages, like in the image above. But what are the responsibilities of each separated part?

Atoms

Atoms are the smallest possible components, such as buttons, titles, inputs or event color pallets, animations, and fonts. They can be applied on any context, globally or within other components and templates, besides having many states, such as this example of button: disabled, hover, different sizes, etc.

Molecules

They are the composition of one or more components of atoms. Here we begin to compose complex components and reuse some of those components. Molecules can have their own properties and create functionalities by using atoms, which don’t have any function or action by themselves.

Organisms

Organisms are the combination of molecules that work together or even with atoms that compose more elaborate interfaces. At this level, the components begin to have the final shape, but they are still ensured to be independent, portable and reusable enough to be reusable in any content.

Templates

In this state we stop composing components and begin to set their context. Moreover, the templates create relationships between the organisms and others components through positions, placements and patterns of the pages but it doesn’t have any style, color or component rendered. That’s why it looks like a wireframe.

Pages

Pages are the navigate parts of the application and it’s where the components are distributed in one specific template. The components get real content and they’re connected with the whole application. At this stage, we can test the efficiency of the design system to analyse if all the components are independent enough or if we need to split them in smaller parts.

React + Atomic Design

When we started to use Atomic Design within React we had to adjust some rules of the methodology to ensure that components were reused as much as possible, that they were stateless, without styles of positions and very specific margins so to avoid any side effects in the pages of application.

So with each new component we asked ourselves: “Are these components generic enough to avoid specificity and/or repeated code in whatever context they are used?”

So we were able to write a few rules:

1. The Atomic Design should have a file of variables and it must be imported by each component;
2. The atoms should be written without margins and positions;
3. Only the molecules and organisms can set the positions of atoms, but these stacks can’t have any styles of margins and positions;
4. Templates have only one function: to set the grid of pages but never positions of specific components;
5. Pages render the components with a template defined and it’s here that the Atomic Design will be connected to the rest of the application;

Let’s code

What I will show here is everything in a boilerplate on GitHub, which you can test and then start your projects using Atomic Design, so let’s do it:

–

To build a UI LIbrary we used an awesome tool called Storybook, which is a great ally to the Atomic Design in React (you can use it for the React Native and Vue too), it allows to render the components and list all states/variations of one.

With the Storybook installed the folder structure will look like this:

Note that inside of the button component there is a file called ‘index.js’ which is the component itself, the ‘styles.css’ is the style that will be imported by CSS Modules (here we’ve used the BEM CSS inside the structure; I recommend reading the article ‘CSS Architecture with ReactJS’) and the ‘stories.js’ is the file that will import the component into the Storybook, which looks like this:

Each ‘add ()’ function is a variation of the component and it is the best approach to describe each state individually rather than a single function, so it becomes easier to highlight and control each one of them. So if you describe all the component variations , the Storybook should look like this:

And the coolest part of the Storybook is that you can add some ‘addons’, such as the Storybook Info, which does awesome things like: story source, props types, defaults values and which values are required or not.

Conclusion

At the end of project, we reached the initial goals and we believe we left a good legacy, a structure which ensures that the project can grow and that other developers can understand the architecture quickly. Maybe we initially spent some extra time writing stories and etc, but the more the project grows, the more the benefits make clear why we should use such architecture.

However we could see that this architecture probably doesn’t work for every project because it depends on several factors. The main one is that the design needs to be thought in the same way as the development: in an atomic way. But the integration between design and development is a point that every project wants to reach, so it becomes a very positive point for Atomic Design.

References

Boilerplate on GitHub

CSS Architecture with ReactJS

Atomic Web Design

Patternlab

Using React within a design system

Atomic components managing dynamic react components using atomic design

The post Atomic Design with React appeared first on Cheesecake Labs.

How the web layout works

All the options mentioned above make sense when applied on static medias where all copies will be the same, for example, books and magazines. But on the web things usually work differently: there are infinite device sizes, pages need to load quickly, while being accessible for screen readers and you need the developer’s ability to build everything that was drawn in Sketch or Photoshop, using the minimum possible amount of code so it can be reusable as much as possible.

Having this structure in mind, it is easy to mentally picture the largely-adopted 12/16-column grid in order to build responsive websites and define the transition from desktop to smartphone browsers. However, there are still big limitations (such as the fact that the HTML order directly interferes in the content visualization), resulting in a big and complex amount of code. There are some CSS frameworks that try to solve the grid problem, the most famous are: Bootstrap, Foundation, Flexbox Grid, Lost Grid. But let’s see the written code in these frameworks:

<div class="row">
 <div class="col-xs-6">.col-xs-6</div>
 <div class="col-xs-6">.col-xs-6</div>
</div>
<div class="row">
 <div class="col-xs-8">.col-xs-8</div>
 <div class="col-xs-4">.col-xs-4</div>
</div>
<div class="row">
 <div class="col-xs-4">.col-xs-4</div>
 <div class="col-xs-4">.col-xs-4</div>
 <div class="col-xs-4">.col-xs-4</div>
</div>

In addition for having to import a considerable amount of code, these structures are usually unreadable and in practice there are always some exceptions that the framework can’t solve. This was a battle won by pure CSS.

The grid display solution!

The display grid is a new specification from CSS that drastically reduces the complexity of building web layouts and structures. Now we can divide the page into areas that can be flexible or fixed, which would be filled with content.

Let’s create a of 12-column grid and try to understand what has changed:

#container {
  /* 1: Set the width */
  width: 960px;

  /* Invoke the grid */
  display: grid; 

  /* 2: Define the columns, in this case 12 columns with liquid width */
  grid-template-columns: repeat(12, 1fr);

  /* Define 8 rows with 110px of height */
  grid-template-rows: repeat(8, 110px);

  /* 3: And the gap width 10px */
  grid-gap: 10px;
}

Only by using this amount of the code, the elements will already fit inside the grid and will never break or exceed the configured width – a problem that existed on CSS frameworks. And we can still easily get all these values from Sketch.

And the elements from the page are described like this:

.box {
  /* Occupy the third to the eleventh column row */
  grid-column: 3/11;

  /* And occupy the region from 1 to 2 line */
  grid-row: 1/2;
}

If you wish to learn and understand more about the syntax and distribution options of the elements, I recommend you to read the documentation in MDN or in CSS Tricks.

In the Sketch Layout

First you need to allow the layout view in Sketch by using the command “Option + L” and then you just need to configure it on the View > Canvas > Layout Settings. As you can see we use the same values for both CSS and Sketch.

Incredibly simple and beautiful 🙂

Responsive layout is now fun

Let’s create a classic website as an example, using header, sidebar, article and a footer. Then, we will introduce the concept of grid-area, within the specification of the display grid.

Again, we need to define the columns and rows of the layout, and then we start naming the sections of the page with the grid-area property, so you can describe which will be the layout format, like this:

.container {
 display: grid;
 grid-template-columns: repeat(3, 1fr);
 grid-template-rows: 100px 400px 100px 100px;
 grid-gap: 10px;
 
 grid-template-areas: 'header header header'
                      'sidebar article article'
                      'sidebar footer footer';
}

.header { grid-area: header }
.sidebar { grid-area: sidebar }
.article { grid-area: article }
.footer { grid-area: footer }

And to change the layout in the mobile you just have to set up the layout, like this:

@media screen and (max-width: 768px) {
  .container {
    grid-template-areas: 'header header header'
                         'article article article'
                         'sidebar sidebar sidebar'
                         'footer footer footer';
  }
}

As you can see, it doesn’t matter the order or position of HTML, because what really matters is how we set the layout position in CSS.

What will change in my layout?

You will be able to create more dynamic responsive layouts and with more distinction between desktop and mobile, using elements that could not change positions because of their relation with HTML. Now the elements can be free to occupy areas of the layout that were unreachable before, without repeating code and content (which is bad for SEO and maintenance) and without demanding great efforts.

To make the changes clearer, imagine a desktop layout that looks like this:

On the mobile it can look like this:

Can you see the new possibilities?

Think outside the grid

There are many possibilities that “display grid” has created, without creating complexities, unreadable codes and upset developers. To see more about these possibilities, I recommend the website Grid by Example where it shows the power of this new specification and helps to demonstrate what we can accomplish.

And that changes everything again: since the web’s early days there have been a lot of attempts to write some practical and reusable specifications to build web layouts, from terrible tables, to the floats and now flexbox and grid. Today, the web takes important steps towards friendly code and with possibilities that don’t limit designers and developers’ creativity.

References

https://gridbyexample.com/examples/

http://maketea.co.uk/2016/09/28/css-grid-layout-is-a-step-change.html

http://fantasai.inkedblade.net/weblog/2012/css-layout-evolution/

https://rachelandrew.co.uk/archives/2015/02/04/css-grid-layout-creating-complex-grids/

The post Dear designers, love your developers because they’ve learned display grid – and you’ve done it too appeared first on Cheesecake Labs.