The complicated relationship between design and MVPs 
- and why it’s worth it ❤️





In her song “Hurts so good”, Astrid S describes a complex and confusing love affair. The contradictory feeling is in many ways recognizable for designers working in teams using an MVP approach.



Merging design and MVPs

The Minimum Viable Product (MVP) approach is all about building to learn. You strive to build something that gives some value to users as quickly and efficiently as possible so you can learn and evolve the product. Build, measure, learn, repeat. It is a process of many iterations.

The benefits are many:

Development goes faster

Users get value earlier (more and more features over time instead of nothing until the product is done)

Risk per release is reduced

The team is more flexible to fix bugs or change course







So, only good stuff here. But what happens when you combine an MVP approach with design methodology?



As a designer I am all about user-centered problem solving. To be able to do my job I need to empathize with and understand the users and their needs. I also need to understand the context, ideate, test my hypothesis, and sketch (amongst other things). All time-consuming activities. Time which we in the digital product development world don’t have. I’m currently working in a team where we have just launched an MVP and are now continuously working to improve our product and find out what our next step should be. We are in the beginning stages of our project and we aim to go fast. Learn fast and build fast. Which brings me to why it hurts.




Speed vs. quality

When development speed increases, the designer has less time to design. There is no time to squeeze in a double diamond between each release. You do not have time to do the testing you would like, or gather the desired user insight. Without this insight and understanding, you feel like you will crumble on the first release. Releasing something that maybe only half done (or less) really, truly hurts. Oh my god. It hurts.

However, as soon as the first release is out you immediately have real users, and get real data. The learning begins. You learn from actual use of the MVP. User insight expires quickly, as our users are evolving in line with the digital development. Having short feedback loops results in current and continuous user insight. In addition, small releases leads to more accurate insight from tracking, testing and interviews because the changes between releases are smaller. So, on the good side, if your half-finished work was a total disaster you will see it real quick. PLUS, you will most likely know exactly what needs to be done to fix it.




Flexibility and immediate value

In digital development it is important to be able to adjust course quickly. Working with MVPs encourages short-term planning. By focusing on the next iteration, and not planning half a year in advance, allows the team to be flexible for changes and fixes. So your half finished work from before can be edited quickly. But, designing for the short term can result in a fragmented solution. It is therefore important to balance between quick and small iterations, and look up and ahead from time to time. When working in the digital world we not only have the possibility to be flexible, but also have the opportunity to create immediate value for the user. The MVP will not be exactly what the users wanted, but it will bring them one step closer to solving their problem. Instead of waiting a long time for the potentially perfect solution, you create small bits of help along the way to the full product.

So, let us head back to my project. My team and I are working on a possible digital service in relation to a physical product. We already have a digital product for the same target group. Our first step was defining our MVP. What would create user value and give us real feedback? Well, maybe informing our users about this physical product existence, and describe how it works. Just adding text in our digital product. Super easy and low effort, and enables us to track the effect this information has on the use of the real product. It is not even close to the digital service we might end up with - but, at this point we do not know if it is a digital service we should be making either!



…


Many designers are afraid their work will fall apart when forced into an MVP approach. But done right I believe your work as a designer can flourish and become more accurate. However, creating an MVP is not always the correct approach in digital product development. My point here is that even if such an approach may conflict with design methodology, it is not necessarily wrong. As designers we need to adapt our workflow and methods to the increasing speed of the digital world. Even though it hurts to release something that your gut tells you is not ready, it might be the best thing to do for the product and your users. We learn and grow the most when we go out of our comfort zone, so the pain is not necessarily bad, even though it hurts (so good).




So, let us sum this up:

You will have to feel the pain of letting go of something that is not even half of what it should have been.

You have to think short-term, day-to-day in some cases, even when your brain is screaming “IT’S ALL CONNECTED! I CAN’T BREAK IT INTO BITS AND PIECES!”




… but on the other hand

You will always have up-to-date user insight

You will have more granular knowledge about the use of your product

You will be able to make changes fast (fix bugs, tweaks ect.)

You will create value for your user earlier..




And, before you throw yourself out there. Here are some must haves when working with MVPs

A team who values user centered development

Logging: Tracking is key to learn as much as possible. Know your products numbers.

Iterations: Anyone on board in this process need to understand that there will be rapid iterations. Without iterations, logging and a user-centered approach your product will stand alone as a far from finished and not an MVP.

Do a more qualitative, thorough research from time to time. It helps on the holistic evaluation of the product, and trigger the long perspective.





…

A big thank you to Ola, Jens Andreas and Sonja for help along the way!





Hurts so Good

This is the carol of how a co-worker and I created the same app using 4 different frameworks: Flutter, React Native, Xamarin Forms and SwiftUI. We did this to answer the age-old question: “Which mobile application framework is the best?” and to learn for ourselves the pros and cons of different approaches. We also polled a lot of colleagues on their experiences, including authors of some of Norway’s most used and important apps. Read on to learn our and Norway’s favorite mobile application framework!

At Bekk we have multiple communities of practice (CoP) each year. In 2021, I, together with my colleague Ina Bjørnestad, joined the community called the App Factory. The end-of-year goal for most of the App Factory members was to ship an app to the App Store or Google Play for the very first time, but since both Ina and I have shipped multiple apps in the past we’d rather try something new. I’ve used Xamarin since 2011 and Ina was well versed in the ways of React Native and we could never agree on the same framework to use. Then it hit us, instead of limiting ourselves to create an app using only one framework, we would instead build the same app 4 different times using some of the most popular frameworks out there. Then we could compare and contrast our experiences and perhaps agree on the best one.

The app we chose to create was called Top or Not and its premise was simple: if you randomly and without forewarning find yourself in an unknown area of Norway, our app will show you the nearest mountain to climb using the map. It should also be possible to mark summits as favorites and to search for them by name. The data was stored in Postgres and served over a REST-API powered by the excellent Supabase.

Creating this app 4 times gave us multiple points of comparison:

The getting-started experience

How easy it was to implement the app’s design

Maturity and ease of use for the framework’s component libraries

Choice of programming languages

Recommended patterns

Speed and chillness of implementing features

The frameworks were:

Flutter, Google’s new mobile offering using Dart

React Native, Meta’s excellent frontend framework, now reworked for mobile using Flow or TypeScript (fancy JS).

Xamarin Forms, Microsoft’s offering with C# for logic and optionally XAML for UI and layout. This will be superseded by .Net MAUI next year, but the same skills can be utilized

SwiftUI, Apple’s preferred way of writing their version of cross-platform apps running on almost all new Apple devices, but understandably off-limits for Android.

So, what did we learn?

General experiences

It should come as no surprise that none of the frameworks was the silver bullet. We encountered roadblocks, difficulties and stunning lack of progress using any framework. What flabbergasted us the most was not only our own problems, but that during one hackathon each and every member of the CoP was stuck for a long time on different problems. Everyone! No issue was the same, but it often had something to do with versioning of frameworks and libraries. Both iOS and Android are ever-changing and just keeping up with their updates was a task in and of itself.

Creating robust CI-pipelines for testing and automatically shipping beta versions of apps were also difficult. Although tools like Fastlane has excellent documentation and online services like App center exists, putting them to use for the first time proved time consuming and error prone for everyone involved.

Flutter

Flutter has the best documentation of the bunch. The docs are so good that answers to many questions can be found there instead on Stack Overflow. The official getting started guides were enough to get us going.

Flutter uses its own widgets to draw the UI and layout proved easy enough since we both were familiar with React from before.

Components exists for many popular use-cases and it’s of course possible to write your own. Some components, like the Mapbox-integration, lacks customization present in other frameworks, but this is not surprising as Flutter is the new kid in town.

Dart is modern language, easy to learn if you know C#, Java or JavaScript.

Flutter is a reactive, pseudo-declarative UI framework, supporting many different app architectures.

Flutter supports hot reload and hot restart, making the developer experience quite nice and feedback loop short.

React Native

React Native presents you with a choice beforegetting started: Which CLI should you use to setup your development environment, Expo CLI or React Native CLI? Expo is the easiest for developers new to mobile development, while React Native CLI requires Android Studio and XCode (on the Mac). Expo wants to do everything from JavaScript/TypeScript, while React Native makes it easy to create bindings against native frameworks. Both approaches let you hit the ground running if you know React from the web.

The component-based approach is easy to learn and quite powerful. Pain-points include state management, as always, but many solutions and patterns exist to mitigate that problem. React primitives render to native platform UI, meaning your app uses the same native platform APIs other apps do.

React Native libraries are plentiful and typically installed from the npm registry using a Node.js package manager such as npm CLI or Yarn Classic.

TypeScript and Flow are supported as default languages and JavaScript people will feel right at home.

React Native lets you hit the ground running if you know React from the web. It’s easy to separate program functions into independent and interchangeable blocks called modules, enabling co-working and partitioning of the app.

Hot reload is of course supported and the write-build-run cycle is blazingly fast.

Xamarin Forms

Xamarin Forms comes with Visual Studio both for Windows and Mac. The built-in templates are good starting points and Visual Studio, for Windows especially, is a great IDE.

UIs can be created using premade controls, which binds to their native counterparts, written in C# or XAML. XAML is a declarative XML markup language custom made by Microsoft for doing UI-layouts. For beginners, learning XAML can be daunting, but everything you can do in XAML can also be done in pure C#.

.Net makes it easy to utilize its extensive library of packages and component through NuGet. Since .Net is popular on the server as well, this enables you to easily use the same code and models between server and app if you so choose.

Even though Xamarin supports other languages too, like F#, C# is the language of choice. An excellent choice!

Microsoft recommends using the MVVM (Model-View-ViewModel) pattern, using bindings between ViewModels in C# and Views implemented in XAML. But Xamarin is flexible and patterns like MVU are also easy to implement.

Hot reload is, for now, only supported using XAML. Also, the app must be built before its first run since .Net is a compiled platform. The XAML designer which ships with Viusal Studio is mostly useless IMO.

SwiftUI

SwiftUI is Apples native offering and ships with XCode for Mac. No Windows or Android options here, just install XCode and you’re good to go.

Foregoing real hot reload in favor of a working visual designer, the UIs is declaratively written using Swift. If you remember to add test data, the views are actually rendered as they will appear in the app. A welcome change from the designers of yore.

Packages written in both Swift and Objective-C are available through CocoaPods and mixing in both native UIKit and libraries written in Objective-C is simple enough to do.

Swift is easy to learn and use and has finally gained something reminding of stability while still being improved every year. Apple’s release cadence coincides heavily with their yearly WWDC event, giving developers a full year to come to terms with changes in the language.

Both MVVM and MVU are easy to use with SwiftUI, and examples and tutorials are plentiful.

Since this Apples own way of writing apps, updates to the OS itself breaks SwiftUI more seldom than the other three frameworks. The designer works well and SwiftUI has the fastest loop if you enjoy testing on real devices.

Community responses

As our one more thing, we asked 63 expert mobile developers on their experiences using different frameworks. Red is “Which framework do you use today?” and blue is “Which framework would you choose if starting a new mobile project today”.

React Native was the currently most popular framework, while Flutter was the most alluring. Some also want to try SwiftUi, but that leaves Android as another story entirely. Xamarin is used reluctantly by some but is still popular.

We also asked if people would recommend a framework to a friend or colleague, thus enabling us to calculate a net promoter score for each one:

Even though each framework was more recommended than not, SwiftUI won by a NPS of 85 which is exceptional. Flutter with its 50 is also well liked, while React Native and Xamarin lags a bit behind.

Conclusion

Does that mean that SwiftUI for iOS and Flutter for Android is the way to go? No! Choose the mobile application framework that best suits your team and your surrounding organization’s skills and technology goals. Focus on what the app should do, for whom and why it should do that. With that in mind, the app can be made using any framework:

For iOS, SwiftUI proved easy to understand and Swift is a nice enough language.

For .Net shops, or people like me who just love C#, Xamarin and shortly .NET MAUI lets people utilize existing skills in a different context.

React is a super popular frontend framework with a broad reach thus making React Native a safe choice for frontend-heavy shops.

Flutter is the up-and-coming contender and has the best documentation of the bunch.

The last hurdle for any app is to be actually accepted in an app store. Which have rules. Many rules, and some of them seemingly random and esoteric. Do yourself a favor and read and understand these rules before designing and implementing your app to lessen the possibility of having done work in vain.

If you want to learn even more and you understand Norwegian, a video of a talk we held on this very subject is available on Bekk’s Vimeo account.

Creating the same app using 4 different frameworks

Trenger man egentlig designer og forretningsutvikler i produktteam?

Swift is mostly known as «that language people use to make iPhone apps». And while the two certainly are a good match, Swift is not really tied to the iPhone anymore. Let’s see how it performs as a language for making cross platform CLIs!

I love Swift. It hits that sweet spot between ergonomically pleasing and good safety features. It’s not too unforgiving (I’m looking at you, Rust), and at the same time manages to produce relatively safe code. It can certainly crash, that’s for sure, but the compiler catches enough of the errors I usually make to make me confident that my code just might work.

Let’s take Swift out of its safe harbor called iOS, and instead throw it into the ancient land of terminals. We’ll end up with a small CLI where we convert input text to a hash. We will support MD5, Sha1 and Sha256 hashes.

I have managed to run this on macOS and Windows through WSL2, so it’s cross platform enough for me. Swift wasn’t exactly born cross platform though, so there are no guarantees that it will run on your platform. If you are unsure, just try!

Now, enough with the warnings. I’m a big fan of git style CLIs with sub commands, so let’s make something like this:

In other words, the format of our CLI is <command> <subcommand> <input>.

Let’s get straight to it. The only thing you need installed is Swift Package Manager. Start up your terminal and generate a project

This gives you a bare bones project, and if you run it with swift run, you’ll be presented with the age old "Hello, world!".

Swift Argument Parser

We could of course parse arguments manually, but I’d rather let a library take care of the nitty gritty argument parsing details, and end up with readable and understandable code instead. Luckily, Apple has a library called swift-argument-parser which is both pleasant to use and supports a wide range of CLI styles: sub commands, options, arguments and flags. To install it, simply open up Package.swift, add it to your package dependencies and your target dependencies. Your Package.swift file should look something like this

This is all we need – the next time we use swift run, our library is installed. Now, open up Sources/hsh/main.swift and wipe away everything. Replace it with

Run it with swift run – and be amazed! You have just installed a library, put it to use, and got the exact same output as you did before you started – amazing! That is job security right there!

Luckily, there’s more to it. If you run swift run hsh --help, you will get automatically generated help for your little CLI. If you run it with some unexpected argument, you’ll also be told so, and told what to do instead.

Let’s take it one step further. We want our CLI to support the sub commands md5 and sha1 – this is, appropriately enough, implemented by configuring our command with sub commands, which refer to two new structs:

There are a couple of things to note here:

We removed the run() function in our Hsh struct. This makes the help text we get from --help the default output. I like this – it makes our CLI more discoverable and helpful!

The sub commands themselves are ParsableCommands as well. I don’t know why, but this really resonates with me.

Pop open your terminal once again, and run swift run hsh. This time, you’ll see your shiny new commands under the SUBCOMMANDS section. Try running them as well to see that everything is working properly.

Swift-crypto

Sooo. Where do we go from here? Well, we could always make md5 and sha1 actually do something useful. I have absolutely no intention what-so-ever of implementing these hashing algorithms myself (I could try to convince you I know how, but.. yeah, no), so let’s add a cross platform library which does this for us. Open up Package.swift and add this line to your topmost dependencies block

And this line to the dependencies block inside the executableTarget block

Let’s start by printing the md5 hash of a static value. To do so, we first need to import the Crypto library by adding import Crypto to the top of Sources/hsh/main.swift. We then replace the run() function in the Md5 struct with this

As you can see, Crypto really does all the hard work here. The only weird thing going on is the convertion to a string on the last line, which is due to the way Crypto represents the hash internally. It turns out there are better ways of storing hashes than as strings, which is what I have done since I started programming 15 years ago. Who could have known.

Try it with swift run hsh md5 if you want, or keep on coding if you’d rather hash an argument passed to your CLI! This is really easy with swift-argument-parser. First, add these two lines to the top of your Md5 struct

And then change "my-string" to value in the run() function. Congratulations – you now have the Md5 generating CLI of your dreams! Try it with swift run hsh md5 my-string (or something cooler – I don’t know). Try it without giving it an argument as well and see what happens!

Adding Sha1 support is just as easy. Start by adding the same @Argument... property to the Sha1 struct as well, and change its run() function into

(side note: seeing this while I write this blog post, the two run functions are.. strikingly similar. Could we perhaps generalize this somehow? )

Now, try running swift run hsh sha1 my-string as well, and see your wonderful CLI present you with an amazing sha1 hash as well!

For completeness, I have a fully working Sources/hsh/main.swift file here. Take a look if your stuck on something, or my wonderful explanation skills didn’t quite make it.

If you enjoyed this, there are plenty more hashing algorithms you could implement in the Crypto library. Or perhaps you could make your CLI more general, and implement other useful developer tools as well?

Cross platform CLIs with Swift

Retorikkens kunst

Retorikk er selve kunsten å tale for å overbevise, og kunnskapen om hvordan dette fungerer. Er det en ting som er sikkert, er det at vi trenger å overbevise andre for å nå frem med våre budskap. Det viser seg nemlig at det ikke holder å kunne nok om et tema, med mindre du også følger retoriske grunnprinsipper og klarer å overbevise andre om at det er riktig. 

Retorikk har røtter som stikker langt dypere enn man kanskje skulle tro. Ifølge historiebøkene stammer studiene av retorikken fra antikkens Athen fra omkring 400 år fvt. Allerede på denne tiden så man viktigheten av å ha med seg folket når man talte, og etablerte at retorikk var noe man kunne lære seg på lik linje med mye annet. 

Også i dag er det utrolig viktig å ha med seg folk og ha evnen til å overbevise gjennom å tale. Hvordan skulle ellers noen fått til å kjøre Elm i produksjon uten kjøretidsfeil, om ingen startet med å overbevise oss om at dette er fremtiden. Og hvordan hadde det gått med vaksinasjonsdekningen i Norge om ikke Nakstad & co klarte å overbevise oss om at det var en god idé å vaksinere seg?

Denne artikkelen gir en kjapp innføring i tre retoriske grunnprinsipper og appellformer; etos, logos og patos. Disse appellformene er på mange måter nødvendige for å oppnå troverdighet som taler. 


De tre appellformene

For å fortelle om de tre appellformene skal jeg bruke det å bli overbevist om å bruke programmeringsspråket Elm som eksempel, men her må du gjerne bytte ut Elm med noe helt annet.


Etos – din karakters troverdighet

Den første appellformen, og kanskje den mer komplekse av de, kalles for etos. Etos handler om å appellere til publikummet sitt gjennom talerens troverdige karakter. Etos er det greske ordet for "karakter". Dette kan vi gjerne kalle bagasjen til taleren, det som taleren tar med seg inn i talen/diskusjonen og som er med på å skape autoritet eller troverdighet på et gitt område. Etos kan deles videre inn i ulike underkategorier, som alle skaper troverdighet på hver sin måte:


Kompetanse

Innehar taleren/overbeviseren kompetanse på området? Ville du hørt på en som anbefalte deg Elm og som ikke selv har prøvd Elm i praksis? På samme måte sitter det litt inne å la en ufaglært totalrenovere badet ditt. 

Moral

Er personen moralsk god? Er det en dydig person? Er personen empatisk, rettferdig, pliktoppfyllende, måteholden? Rett og slett; har personen en inneboende karakter vi kan stole på?

Velvilje

Er personen som overbeviser deg en som vil deg, prosjektet eller organisasjonen din vel? Er personen sympatisk? 
 

Logos – dine logiske resonnementer

Den andre appellformen, logos, handler om å "mette" mottakerns kritiske sans – det handler om fornuft, fakta og alle de logiske argumentene. Gjerne noe som attpåtil kan være konkret og tallfestet. Noen eksempler:

"Hvor mange kjøretidsfeil har vi registrert etter at man byttet over til Elm i produksjon? 0."

"Vaksinen har vist seg å beskytte 90 % mot kritisk sykdom".

"Backenden vår gikk fra 15 000 kodelinjer til kun 2500 når vi byttet fra Java til Kotlin, som igjen gjør at det krever mindre av nye utviklere å sette seg inn i kodebasen."

Patos – vekk mottakerens følelser

Den siste appellformen heter patos, og handler om følelser. Det er vanskelig å overbevise noen ved å kun bruke etos- og logos-appeller. For å bevege noen må de føle! Patos appellerer til følelsesmennesket. Om du skal få noen til å starte med Elm på prosjekt, må du kanskje også gi de godfølelsen, vise de litt kode, kanskje gi de et Elm-klistremerke til å ha bakpå laptopen sin, eller gi utviklerne mulighet til å se for seg hvor digg det kan være å fortelle produkteieren at de nå har et mer robust produkt? 


Hva med i praksis?

Når man skal bruke de tre retoriske appellformene burde man tenke på det litt som en cocktail – alle ingrediensene må med. Og hvordan du skal blandet cocktailen din er helt avhengig av hvem som skal drikke cocktailen. Kanskje noen først og fremst er følelsesstyrte? Eller ser tvers gjennom følelser, og vektlegger fakta og tall når de tar beslutninger?

Et annet interessant aspekt ved å levere retoriske budskap, som politikere er ganske flinke på, er selve timingen (kairos) til budskapet ditt. Det kan for eksempel være et fint tidspunkt å foreslå innføring av Elm rett etter man har hatt en menge produksjonsfeil. 

Håper du har de tre appellformene i bakhodet neste gang du skal overbevise om noe som er viktig for deg!



17-Dec

Today's posts

Hurts so Good

Creating the same app using 4 different frameworks

Trenger man egentlig designer og forretningsutvikler i produktteam?

Cross platform CLIs with Swift

De tre retoriske appellformene