Amazon Web Services and Azure both provide more than a hundred services each for various kinds of cloud computing needs. This blog post does not go into service level analysis on who has the best tools on various scenarios, but tries to bring some light to the ideological differences between the two.
Basic building blocks
Both of the products have quite similar basic building blocks, which is IaaS. You can go full ’bah humbug’ to modern services and build your systems on virtual machines on both clouds. The pieces are the same: routes, security groups, networks and VMs. Be warned though: there are differences on how the pieces are planned to be stacked on different clouds. Even if you know your stuff in one cloud it doesn’t mean that you can succeed in another; at least not in a secure and fault tolerant way.
Pieces vs models
One ideological aspect that differentiates the two cloud providers is the way services are built and designed. In AWS there is a sort of linux analogy going on with one service providing input to another. In order to build a functional system you do those service-to-service joins, spend some time deciding on inter-service-permissions and end up with some kind of mesh of services that provide you with the functionality that you want. For Azure it’s a little bit different: a single service (typically) is a bundle of functionality that tries to fulfill all your needs regarding it. If you need some external service pieces (IPs, logging, storage etc.) you just enable them on the service dialog. This ease of use and management comes with a caveat though: if you don’t like the service options you are given, it’s hard to extend or alter the functionality. When choosing a combination of cloud & services you have to balance the ease of infrastructure implementation with the functionality you are given.
Playing nicely with your existing toys
My four-year-old likes to play with Duplo by mixing them with cars, dinosaurs and train tracks, but playing with Lego consists of only playing with … Lego. In Azure almost every service I’ve studied has an aspect of being an extension to your on-premises datacenter. If a service has a Windows-server equivalent, you can be sure it can be integrated with your Azure cloud account. It’s an understatement to say that hybrid cloud thinking is strong in Azure, as for Azure it’s a way to differentiate from others. AWS has components that work well with your on-prem datacenter, but rather than hybrid they are more like an extension. You can extend your storage to cloud for example, or virtual networks, but you think of your on-prem and cloud as different entities.
Future & Common ground
Azure has been taking some steps in to the typical realm of AWS by introducing PostgreSQL and MySQL as managed databases and Linux based PaaS in App Services. AWS has also introduced services that have a more Azure-like mindset such as CodeStar (in addition to existing Elastic Beanstalk). Recently they both released the preview versions of Kubernetes as a service for container orchestration. My guess is that in the coming years the two behemoths will come to resemble each other even more, with more focus being on providing an easy way for developers to publish their code and less on building complicated himmelis (https://en.wiktionary.org/wiki/himmeli) to meet that need. Maybe there will even be a time (in the near future) when the OPS-people become obsolete as the developers can push their code out in the open assisted by systems that have elasticity, redundancy and sane defaults.
Further reading form the Gofore blog
As you’ve found your way to this blog post you’ve probably heard the term PWA somewhere. Good for you – PWAs are what the year 2018 will be remembered for, so you are right on the bleeding edge. How exciting! In this blog post, I explain what does the term actually mean and why you should care about it.
(source: Google Developer site)
What is a PWA?
PWA stands for Progressive Web Application. Let’s examine it by splitting it into two parts. The latter two words (”Web Application”) speak for themselves. PWAs are web applications. Here, web application simply means an app running as a website like, for example, Twitter. The first part of the term – Progressive – means that the user experience is enhanced gradually based on the browser’s capabilities. Essentially this means that the web application works well in older browsers but can utilise newer technologies to enhance the experience if the user is using a browser supporting them. Sounds simple, right? So where is the term from?
Progressive means that the user experience is enhanced gradually based on the browser’s capabilities
The term was introduced by Google Chrome engineer Alex Russell in his blog post in 2015. Since then, Google has been promoting their usage actively and provided a lot of resources on the topic such as a site explaining them in more detail.
While giving presentations around PWAs I always encounter the same confusion at this point. ”So… Is it a technology? Is it a standard? Is it something owned/patented by Google?” No, none of those. It is simply a term to describe a specific way to design and build applications. Next, let’s try to understand what they are by going through the characteristics.
Here are the original 9 characteristics of PWA by Alex Russell with an explanation as to what they mean in this context:
- Responsive: Page looks good on different screen sizes (e.g. phone, tablet, desktop)
- Connectivity independent: Function without Internet connection
- App-like-interactions: Look’n’feel of native application
- Fresh: Always up-to-date
- Safe: Utilise secure connection to mitigate multiple types of security threats
- Discoverable: Browsers identify PWAs automatically
- Re-engageable: Can bring users back to the app using, for example, Push Notifications
- Installable: Can be stored to the home screen just like native apps but without the extra hassle of the App Store
- Linkable: Can be shared around as plain URLs
For the reader of this blog post the most important functionalities are:
- Installability to the home screen
- Access to multiple native APIs such as camera, geolocation, vibration, payments etc.
- Support for Push Notifications
- Offline usage
- Full screen and splash screen support
(source: Alex Russell’s blog post)
To conclude all of the above, PWAs can do most of the stuff native apps can do and the gap between what native and web apps can do is getting narrower all the time.
By now you might be thinking that all this sounds so good that there must be a catch since the PWAs aren’t the default way of implementing applications. Yes, you are right. There is a catch. There has been a lack of support for the technologies empowering PWAs in some environments. Android support has been around for a while, starting from Android 5 which means that over 80% (source: Google’s Android statistics) of the Android devices worldwide support the technologies needed to implement PWAs. The adoption is even greater if you only consider Europe or North America. So the Android support is really good already.
Unfortunately, the other key player sharing the market in mobile phones hasn’t been too eager to implement the technologies (read why). The iOS support has been missing, thus preventing the wider adoption of PWAs. But as of the soon upcoming iOS 11.3, the support will be available also for iOS. Luckily the adoption of new iOS versions is relatively fast so a high level of support can be assumed to be available later this year. For reference, versions 10 and 11 represent 93% of all iOS versions used out there according to Apple.
While the focus when talking about PWAs is often in the mobile environment, they do work for desktop as well. Earlier this month there was an important announcement by Microsoft stating that PWAs are now supported by Edge and Windows 10. Chrome and Firefox are supporting PWAs already and so will the next release of desktop Safari.
Example: Twitter Lite
The most famous example of PWAs is the Twitter’s PWA version called Twitter Lite (try it with Android or desktop at mobile.twitter.com). Twitter has also published their reasoning behind building the PWA version. To highlight some of the facts from the post, compared to their native app, the size of the PWA version is only 1-3% and the average load time is 30% less.
Other well-known examples of PWAs include Forbes, Trivago, Washington Post, Telegram, Alibaba and most recently Google Maps Go. There is also a directory of PWAs available.
The year 2018 is expected to be the year for PWAs. The tooling is already at a great level and more and more PWAs are popping up all the time. Once support in iOS is highly available, PWAs become a realistic option for native apps. In case you are considering whether PWAs are the right choice for you, check back soon as I will write a guide on Should I do a PWA instead of a native app?
Gofore already has experience on PWAs and also possesses wide experience in building responsive, great-looking, offline-first and efficient web apps. Whether you need help with architectural choices, design or implementation of PWAs, don’t hesitate to contact us.
FURTHER READING FROM THE GOFORE BLOG
Are you in a situation where you need to choose between a Progressive Web App and a native application and have no clue how to assess which one suits your needs better? If so then this blog post is for you as I explain how I help our clients to make the right choices for their businesses. In case you need an introduction for PWAs first, please check my earlier blog post What is a PWA and why should I care?
To give an overview on the level of support for PWAs, below is a list of all major platforms (desktop and mobile) with their current and upcoming support. I’ll try to keep the list up-to-date while things are still progressing. Here, support is defined by implementing the two most important features of PWAs: Service Workers and Web App Manifest. The support for native features (such as Virtual Reality, payments and device motion) varies greatly among the browsers.
- Chrome: Not so surprisingly the support for PWA features has been around for a while in Google Chrome.
- Firefox: Latest Firefox for Android release brought the support for Web App Manifests, and Service Workers have been available on Firefox for quite a while already. I suppose the support for manifests will be seen in the desktop versions soon too.
- Safari: The support for Service workers was introduced as part of Safari 11.1. Same limitations (no Push notifications and support for Web App Manifest) apply as for iOS version below.
- Edge: On 6th of February Microsoft announced the support for PWAs in EdgeHTML 17.17063 soon to be released.
- IE11: No current or upcoming support.
- Apple: iOS 11.3 was released 29th of March 2018 with support for Service Worker. Support for Push notifications and Web App Manifest is still to be added. Luckily iOS has supported installing app as a desktop icon for quite some time already with vendor-specific functionality so that can be leveraged. iOS users are luckily known for quick update cycle so the support can be expected to reach a decent level relatively soon.
- Android: In Android there are multiple browsers that are used. The default browser (based on Chrome) has supported PWAs since the release of Android 5 and the support is also available in the Samsung Internet and Firefox for Android. Android 5+ represents over 80% of Android devices according to Google.
- Windows Phone: According to at least this article there is no support expected for the Windows Phones..
(Last updated 5th of April 2018)
What to consider when choosing?
Below are the main points to consider when evaluating whether a PWA can be used instead of a native application. Choosing isn’t always straightforward and often requires knowledge about the expected user base, plans & requirements for the application itself and state of support for multiple native features.
1. Know your user base!
The very first thing to consider is your user base. Even though the support for PWAs is spreading all the time, it just isn’t quite there yet. You need to understand what kind of devices the users are using the app with. Let’s view this via examples for both suitable and unsuitable cases for PWAs.
Suitable user bases
- App is to be used only by your organization’s own employees and your organization only provides employees with high-end Android phones. Such a case is usual in public sector and also in large enterprises.
- App is to be used mostly in geographical areas where the percentage of high-end devices is high enough and the users without such device can be ruled out. Even though it might sound harsh and infeasible, it is actually done all the time with native applications too as they more often than not don’t anymore support devices like Android 4 to provide the best possible user experience and to ease the development burden.
Unsuitable user bases
- App is to be used by public, mostly in geographical areas where low-end devices are typical and for example Android 4 is still a major factor. Africa and South America are examples of such areas.
- App is to be used with devices that don’t support the native features required for the app to provide value. See the next point for more details. Whether a PWA is currently a solution for your case is essentially a business decision and thus should be evaluated as such. If you are okay with some users missing features provided on top of the basic web site, PWA is a suitable option for you.
2. Nature of the app
What are the features required by the app and how do they or lack of them affect the user experience? Not all native features are supported by the web platform yet. Want to do geofencing, Virtual Reality or NFC? Then PWAs maybe aren’t for your use case (yet). Or maybe they are! The P in PWA stands for Progressive. What it means is that the user experience is enhanced based on the capabilities of the browser. So the decision comes down to if these features are a mandatory part of the application or is the app valuable enough without these features. What I can’t unfortunately provide here is a comprehensive list of native features available on the web platform. This is mostly because the list of native features is huge and the support is evolving all the time so the list would be outdated anyways. It needs to also be noted that even though many features are available on web platform they might differ in user experience and options when compared to using them in native apps. To give an example of such feature, consider an app that wants to utilize the camera with an overlay on top of the camera preview (e.g. Snapchat as seen in image below). It simply isn’t possible even though you can access the camera functionality itself.
To investigate the feasibility for your business case, you can start by taking a look at What Web Can Do Today, which checks your current browser’s support against all native features, and Can I Use?, which allows you to search for certain feature and check the compatibility table for most used browsers.
3. Technological suitability
Implementing your app as a PWA usually reduces the development costs heavily as you can skip the expensive native development for each platform you want to support while still being able to utilize many of the native features. The support is getting there and 2018 will be a big year for PWAs as iOS support is finally landing. Choosing a PWA over a native app boils down to understanding what are the trade-offs and how is it limiting your potential user base. This has to be evaluated on a case-by-case basis and requires extensive comprehension of the business case. Gofore has a wide experience in both service design and technologies empowering PWAs and can help you to make the right choice for your business case. Contact us and let’s see together how can we help you. In case the PWAs aren’t the right choice for your case, Gofore also possesses wide experience in native and hybrid apps so let’s craft the app together!
Further reading form the Gofore blog
Viime syksynä Jyväskylän toimistollamme vieraili päiväkotiryhmä tutustumassa toimintaamme. Vaikka lapsiryhmän lyhyt vierailu ei vaatinut suuria järjestelyjä, pohdin pitkään miten kertoisin 4-5-vuotiaille ohjelmistokehityksestä. Pelkästään ohjelmointi käsitteenä on jo hyvin abstrakti. Mieleeni palautui 90-luvun alku ja ala-asteen opetuskokeilu, jossa luokallemme opetettiin ohjelmoinnin alkeita Logo-kielen avulla. Logo on opetuskieli, jossa yksinkertaisilla komennoilla liikutetaan ruudulla olevaa kilpikonnaa, joka jättää liikkuessaan jälkeensä viivan. Kilpikonnan ruudulle piirtämä viiva tällöin konkretisoi annettujen komentojen vaikutusta hyvinkin selkeästi. Vaikka ATK-luokkamme Commodoren ruuduilla se kilpikonnakin oli pelkistetty kolmio, oli Logo meille aikanaan mieluinen peli. Siis peli eikä ohjelmointiympäristö, joka kuulostaakin joltain hirveän vaikealta ja tylsältä.
Tulin lopulta siihen tulokseen, että yritän ohjelman käsitteen kautta avata lapsivieraille ohjelmistokehittäjien työtä. Alustin asiaa näin: “Tietokone on laite, joka noudattaa sille annettuja käskyjä. Se tekee vain sen mitä käsketään, ei muuta. Useammasta käskystä syntyy ohjelma. Eli ohjelma on sarja käskyjä, jotka kone suorittaa.” Konkretisoin asiaa leikin kautta esittämällä robottia, jota lapset saivat ohjata yksiselitteisin liikkumiskäskyin. Laitoin robottipäällä koristellun pahvilaatikon päähäni ja annoin ryhmälle tehtäväksi ohjata “robotti” istumaan taukotilan sohvalle. Reitti oli noin 10 metriä ja sisälsi useita käännöksiä. Ensimmäinen komento oli “Robotti, kävele!”. Aloin kävelemään ja jatkoin kävelyä suoraan eteenpäin kohti seinää, mutta juuri ennen törmäystä joukosta kuului “Pysähdy robotti!”. Lapset sisäistivät pelin idean vikkelästi ja komennot muuttuivat vähitelllen yksiselitteisemmäksi. Lopulta robotti pääsi määränpäähänsä ja näin robotin kävelytysohjelman ensimmäinen versio oli valmis.
Vierailun jälkeen mietin, että tämän saman esittelyn voisi tehdä aika helposti oikealla robotilla – joten ei muuta kuin tuumasta toimeen! Robotin rakennustarvikkeiksi valitsin omista kokoelmistani pyöreän, kahdella dc-moottorilla ja renkailla varustetun robottialustan, L293-pohjaisen moottoriohjainkortin sekä ESP8266 wifi-moduliin pohjautuvan Lolin V2-kehitysalustan, joka on NodeMCU-klooni. NodeMCU on hyvin edullinen avoimen lähdekoodin kehitysalusta, joka tarjoaa vakiona Lua-tulkin ja kattavan työkaluvalikoiman IoT-protoiluun. Sitä voi myös ohjelmoida esimerkiksi Arduino-ympäristössä c-kielellä. Valitsin robotin aivoiksi ESP8266-pohjaisen ratkaisun koska se mahdollistaa langattoman verkon hyödyntämisen paristovirralla ja tarjoaa samassa paketissa myös riittävästi IO-pinnejä laajentamiseen.
Koottuani robotin perusosat, toteutin ohjelmistoon ensin liikkumisrutiinit. Tämän jälkeen kyhäsin logiikan, joka muutti merkkimuotoiset käskyt ennaltamääritellyiksi liikesarjoiksi: liiku 15 cm eteenpäin, käänny 15 astetta, jne. Kun robotti pystyi liikkumaan ja tulkkaamaan ohjauskomentoja, oli aika rakentaa robottia ohjaava käyttöliittymä. Päädyin hyödyntämään ESP8266WiFi-kirjaston palvelinominaisuutta, jolloin robottia voi ohjata samassa lähiverkossa millä tahansa selaimella, tabletilla tai älypuhelimella. Robotin firmware toimii hyvin yksinkertaisena http-palvelimena ja tarjoaa HTML5-käyttöliittymän lisäksi HTTP-rajapinnan, johon komennot lähetetään GET-metodilla. Käyttöliittymän rakensin hyödyntäen vanhaa hyvää trioa: Bootstrap, Font awesome sekä jQuery. Sain näillä toteutettua hyvin kevyen, mutta käyttökelpoisen ohjausnäkymän.Ohjauskäyttöliittymä on staattinen HTML-sivu, käyttöliittymän vaatimat resurssit ladataan selaimessa CDN-palvelimelta ja komennot lähetetään palvelimelle Ajax-pyyntöinä. Käyttöliittymässä komennot ovat nappeja, joita painamalla käskyt siirtyvät jonoon. Kun painaa play-nappia, selaimesta lähtee http-pyyntö Ajax-kutsuna robotille, joka suorittaa annetun käskysarjan ja lopuksi pysähtyy. Koska monimutkaisempien rakenteiden toteuttaminen olisi vaatinut selkeästi enemmän aikaa, päätin että robotti tottelee yksinkertaisia liikkumiskäskyjä kuten eteen, taakse, käänny oikealle, käänny vasemmalle ja odota. Tämän lisäksi implementoin silmukkamekanismin, jolla komentosarjan voi toistaa kaksi tai viisi kertaa.
Jos haluat itse rakentaa samankaltaisen prototyypin tai tutkia miten robotti toimii, voit ladata lähdekoodin GitHubista: https://github.com/manujoha/simplewifibot/. Alustaksi käy jokin muukin ESP8266-pohjainen alusta, kuten esimerkiksi Wemos. Valmis moottoriohjainkortti helpottaa protoilua, mutta käytännössä mikä tahansa H-bridge mahdollistaa pienten dc-moottorien ajamisen mikrokontrollerista. Myöhemmin ajattelin lisätä käskykantaan myös audiovisuaalisia efektejä, ääniä ja valoja sekä mahdollistaa parametrisoidut komennot. Pohdiskelin että seuraava versio voisi olla myös ulkoisesti viimeistellympi. Sillä voisi olla esimerikisi ystävällisen näköiset kuoret tai koko robotin voisi rakentaa vaikkapa legoista.
Sain robotin ensimmäisen version valmiiksi juuri ennen marraskuussa vietettyä ”lapsi mukaan töihin” -päivää, jolloin toimistollemme saapui jälleen lapsivieraita. Tällä kertaa ohjelmaan ei kuulunut sen kummempaa esitelmöintiä vaan robotti oli esillä vapaasti kaikkien kokeiltavissa. Pienemmissä lapsissa karun näköinen robotti ei juurikaan herättänyt mielenkiintoa, mutta kouluikäiset leikkivät laitteella mielellään. Improvisoimme heille tehtäviä mitä robotilla pitää suorittaa: kierrä roskakori, siirry lattian sinisen laatan päälle, jne. Kun robotin ohjaus ei tue robotin ajamista radio-ohjattavan auton tavoin, vaan pakottaa pohtimaan mitä komentoja tietty liikerata vaatii, se muuttaa leikin enemmänkin ongelmanratkaisuksi. Koeajajat ja robotti suoriutui tulikokeestaan hyvin: teknisiä ongelmia ei tullut, eikä mitään mennyt rikki.
When getting started with prototyping, you’ll face a large variety of tools. Therefore it is crucial to know which tool is the best for you. This blog post will provide you with tips on what you have to consider when picking the right tool for your project. But let’s start at a more generic level, or – as Simon Sinek taught us – let’s start with why?
Why do we prototype?
Nowadays most of us are familiar with the Lean Startup Theory by Eric Ries. His circular, iterative approach strongly influences today’s (digital) product development. Through his three concise steps – Build, Measure and Learn – we aim to incrementally develop, assess and refine our products: The definition of Prototyping per se.
Prototyping helps us to validate our ideas and concepts. It allows us to run experiments through which we can learn and evolve. Just talking with users about your concept will easily exceed their imagination. To get good feedback, you have to make things tangible. If you use it right, prototyping will, therefore, save you a lot of time and money, which you may have invested in the wrong features.
If you are not embarrassed by the first version of your product, you’ve launched too late. – Reid Hoffman –
A good rule of thumb for prototyping. Do not hesitate to test your early stage product and ask potential users for feedback. Go out and be embarrassed! It won’t feel as bad as you imagine.
What tool can I use?
The list of digital prototyping tools is impressively long. You’ll find a solid overview for example at prototypr.io. The question of what tool you should use is more complex. The answer depends on various factors. More on this later. The fact is: one tool for everyone and everything does not exist. Each tool out there is unique in its capabilities and constraints. Each is superior in certain areas compared to its competitors.
Consequently, depending on your project or the project phase, various tools might be beneficial for you. As Designers of today, you have to be flexible and adapt to these conditions. This often even includes working with different tools within one project. If you’re only able to work with what you are used to, you will soon reach your limits and be outpaced by others.
So, get out of your comfort zone! Challenge yourself and get going with multiple tools. Interoperability will be your advantage.
Even though the density of tools is significantly high, there are still large gaps when it comes to their ease of use. It definitely depends on yourself, if you prefer a techie/complex or a minimalistic/faster surface. Either way, you will find what you are looking for.
While a profound work process requires us Designers to use several tools throughout a project, most of the tools still lack on inter-compatibility. Instead of leveraging the benefits of each tool and combining those into our processes, we end up being forced into one system. To escape them, you need to leave behind what you already have achieved. These barriers to change create a significant loss of efficiency.
Looking into the future, it is not only about us as Designers becoming more flexible but also about the tools enabling us to profit from their individual benefits as a collective. Instead of fighting about being the tool for everyone, the tools we use should set their focus on what they are good at and let other tools do what they can’t themselves.
Back to the here and now, and finding the right tool for you. The core to this is knowing the answer to the following question:
What do I want to test?
As prototyping should be utilised to validate ideas and concepts, you have to know what exactly you want to verify. Align with your team what the goal of this experiment is before you start working on a prototype. Be precise and try to formulate a concrete hypothesis.
If you don’t know what you are testing for, it’s not worth prototyping it.
From my experience as a UX Designer, prototypes vary in the dimensions of their fidelity as well as their interactivity. Most commonly you will, therefore, test one of the following four aspects of your product: Architecture, Look & Feel, Friction or Experience.
The transition between these four areas (marked in grey) is fluent. Nevertheless creating a prototype which aims to test between the extremes will be inefficient. Focus on what this test is really about. Once you’re happy with the feedback, move on and prepare for another test – in another area.
Developing a product from scratch most likely starts with a very basic prototype to validate your product’s Architecture. Depending on the characteristics of your product and its scope of application, either testing the Look & Feel or Friction is the logical next step. More about the differences between these sections in the following chapter. Last but not least, you test the Experience of your product. As this needs a big investment, you should be certain about the other areas before developing such a prototype. For sure there are also exceptions, where a project might require totally different approaches. But in the end, exceptions prove the rule.
What should I use?
Let’s dig deeper into the four quadrants shown above and talk about their characteristics. Each tries to address different questions about your product, requires different tools for prototyping and leads to different benefits or constraints.
Case 1: Architecture
While starting the development of a new product, you will face questions which sound alike:
- Does the product cover areas of users’ interests?
- Are these areas structured in a ’for the users’ logical way and with a useful hierarchy?
- Can users get their job done or complete certain tasks?
As these are the basics of your product, you shouldn’t hesitate to prototype them at an early stage. Keep the fidelity and interactivity low to prove your ideas without a big investment. Tools like Balsamiq Mockup are a good choice for testing your architecture.
It allows you to visualise rough concepts in a fast and easy way. Simple interactions like clicking through pages or scrolling can be built without exporting any of your work. At the same time, you have to be aware that your prototype might seem very abstract for testers, as you can only control the visual appearance minimally. Make sure this is not distracting them from talking about the questions you’re focusing on.
Case 2: Look & Feel
Once you have roughly defined what your Architecture should look like, you will most probably run into such questions as:
- How do the users perceive your product?
- Is the visualisation of elements logical and usable for users?
- How can the architecture be refined? (see questions of Case 1: Architecture)
To figure out the answers, your prototype doesn’t have to be fully functional, nor does it need the ability to represent micro-interactions. Try to focus on the sizing and usability of crucial interaction elements like buttons, as well as the mood and image that is created through your colour palette, images and themes.
Tools like Adobe Xd and Sketch (in combination with Craft & Invision) allow a higher aesthetic control. The creation of simple interaction possibilities, such as clicking or scrolling, is straightforward. You end up with a more realistic experience for your testers. Consider that you need a consistent style guide upfront to build your prototype accordingly. Consequently, this leads to a higher effort for your design team. Showcasing a high-fidelity prototype often implies a greater functionality to your testers. Make sure they understand that this is only a prototype, which might not be fully functional.
Case 3: Friction
If your product relies on interactions and their clarity for the users, it is more important to test these than to think about the Look & Feel in the first place. You might find yourself thinking about:
- How easy is for users to use the product?
- How do users perceive interactions patterns used in the product?
- How can the architecture be refined? (See Case 1: Architecture)
With tools like Axure, HotGloo or JustinMind, you can create low-fidelity but highly interactive prototypes. You will be offered a broad variety of interaction patterns, which can be combined and interlinked even within a single screen if required. This helps you test several use cases at once as well as letting your testers behave in a more realistic way. Keep in mind, that these tools offer you low visual control, making it harder to adapt elements like checkboxes to your own styles. Setting up complex interaction patterns can be very time-consuming and, depending on the tool you use, sometimes even frustrating.
Case 4: Experience
A high fidelity and highly interactive prototype is the closest you will get to a real product. By testing such a prototype, you also validate all the previous cases. Be careful: if your product is still lacking on its architecture, creating a test for the overall experience will, for sure, fail. Make sure you tested the other areas before you go into prototyping for an experience test. Your open questions here should be similar to the following:
- How do users perceive the overall experience of interacting with the product?
- How do users perceive the look & feel of the product?
- Where are last friction points for our users?
Currently, the most suitable tool for testing an experience is the combination of Principle and Sketch. Alternatively, you should also consider using Proto.io or Framer.
Besides high-quality visual outcomes and aesthetic control, you’re able to mimic complex interactions. Different screen states, can easily be managed and combined to offer the most realistic experience for your testers. The set-up is therefore highly time-consuming and takes a lot of effort for your design team. Technical knowledge is often beneficial when creating complex transitions. The gap to coding your product (html, css, js) is rather small.
To sum up: The one and only prototyping tool does not exist. It is more about finding the right tool or even a combination of tools for your purposes. As every tool comes with certain benefits and constraints, you need to know which ones are most suitable for your needs. Therefore try to focus on the reason why you are testing and define what you really want to find out.
Consider that a prototype is a simplified version of your product. It doesn’t have to be fully functional nor high-fidelity. Don’t be afraid of showing it to potential users! In the end, prototyping has been, and will always be, a little exposure of yourself. Little by little you’ll feel more comfortable. Even more important, step by step you will evolve your prototype towards a user-centred and successful product.