This is the last part of blog series: “Design Essentials: How to Prosper on Every Platform”.
Know Thy Customer
The need for self-expression
I sometimes like to fall back on Maslow’s hierarchy of needs when trying find fresh ideas. To simplify the theory, after the essential needs for humans have been fulfilled, comes the level of self-expression.
Some animals do self-expression, but this is where human behaviours are on another level. Expressing identity is nowadays a hot topic; maybe it always was. Clothing, makeup, jewellery, behaviour and rituals are a part of every culture since ancient history. The ruling Pharaoh in ancient Egypt had various styles of crowns to express his/her authority.
People do self-expression via brands as well:
In a culture that values individuality and personality, what we choose to wear, to drive, even what we order at a restaurant, are potential opportunities to fulfil our need for self-expression and marketers must understand and find ways to fit their goods into this process.
A business cannot reach any individual if there is no clear understanding of what a brand, product, or service symbolically represents.
The need for belonging
The internet is the ultimate way to find like minded people. Maybe you like Manga, live gigs or DIY – There’s always a community available online. The way to connect with communities happens through electronics, mainly apps and websites. Ultimately, all the social connections that are not made in real life rely on some sort of data transmission. As a designer your goal is to build the best possible experience on top of that connection. (Let’s not forget the importance of the whole software team). The Long tail enables easier customer acquisition and sales based on niche items and services.
some neuroscientists have suggested, human beings could be wired to feel pain when we are bereft of social connection, just as evolution has wired us to feel pain when we are deprived of our basic needs (e.g. food, water and shelter).
(Belonging) offers “reassurance that we are not alone,…
Successful brands are based on customer values. By creating a lifestyle brand, you have a better chance at succeeding.
(Lifestyle brands) can help us to connect more with our ideal version of ourselves
These businesses have figured out how to earn the respect and trust of their customers by giving them access to the lifestyle they crave.
The underlying idea of a lifestyle brand can be traced easily back to Carl Jung and the concept of archetypes. An archetype is a universal idea, symbol or motif, that is repeated throughout history, art, literature, mythology and religion. The 12 Jungian archetypes are presented here:
If you wish to build a great brand, you should understand your audience, and build a lifestyle brand based on the ideal version of themselves. Pick 1-2 archetypes to start with.
If you look closely, you will start noticing these archetypes all around you in brands.
Take a look at Patagonia, a clothing company that markets and sells outdoor clothing.
Their marketing is full of awesome landscapes, people living the active outdoor lifestyle. Recently they entered the fight against the climate change, big time.
Now try to categorise them with the 12 archetypes provided.
My interpretation of the archetypes: Explorer + Jester with some adjuncts from Hero. Is your interpretation different?
Putting it all together
As a designer, you need to have a mindful attitude towards life. Learn to observe and enjoy the notes you take. These notes are an invaluable asset for you. To observe things better, start carrying a pen + notebook or a rangefinder camera with you. This helps you get better at observing.
In order to design something great, you will have to tackle multiple things at once. Learn to take a wider perspective, but also be able to focus on the tiniest details. Service design considers touchpoints as any possible interactions happening with your brand, that might affect the way how he/she feels about it. By understanding what happens at each of the touchpoints, you are able to design a better customer experience.
As a service designer, you are obliged to observe your personal experiences and take part eagerly in any new experience opportunities. Especially in large cities, where these services are often well-formed. Think like a service designer when you are having a holiday. This works vice versa, too: Think like a customer when you are doing service design work.
As I was writing these three areas of blog posts, I realised that a book would be a better format. I hope I was able to give you some fresh perspectives on design. By tackling platform, context and customer – you are on your way of becoming a great designer!
This post ends blog series: “Design Essentials: How to Prosper on Every Platform”.
Part 1: Design Essentials: How to Prosper on Every Platform – Know thy Platform (Part 1)
Part 2: Design Essentials: How to Prosper on Every Platform – Know thy Context (Part 2)
Know thy Context
In a designer utopia, the user is always performing one task at a time, i.e. performing a single use case in your product. Often times, the modern world consists of intertwined tasks and interruptions. This leads to a conclusion that understanding the use context is essential in order to carve great experiences.
Examples of what the user might do while she is using your mobile app product:
- Use other apps
- Have multiple tabs open
- Talk with other people
- Browse email
- Browse the world wide web
- Use other smartphone features
- Listen to music
- Watch Netflix
- Do pushups
In a nutshell: 100% of the user’s attention is not targeted to your product – it is divided among other interesting tasks. You don’t have full attention, so make your designs as if you were designing for an ape: Intuitive enough to be used with as little amount of attention as possible.
The user may or may not have experienced something from the list within 1 hour of usage of your app.
- Run a marathon
- Quit a marathon
- Had a meal
- Eaten too much
- Slept 12 hours
- Haven’t slept for 24 hours
- Given birth
- Attended a funeral
Emotions of a person are a cumulative result of a person’s past experiences. When experiencing your design, a user may already be frustrated by misfortunes experienced recently. On the other hand, she may be feeling like she is on top of the world.
But how to take this into account?
Learn the aspects of classical UI design. Read books, for example, Designing Interfaces: Patterns for Effective Interaction Design.
It’s all about compassion. Until we can deliver truly personal experiences, we should use polite but not too childish language in our user interfaces.
A frustrated person may also get angry with the experience if she has to wait for loading. You should avoid loading experiences or make them unnoticeable.
Take advantage of user personalisation on different platforms. For example, someone may prefer different font sizes on iOS. On the web, make things responsive, zoomable and bookmarkable.
Personas are the de facto way to put yourself in someone else’s shoes.
A persona is a way to model, summarize and communicate research about people who have been observed or researched in some way. A persona is depicted as a specific person but is not a real individual; rather, it is synthesized from observations of many people. Each persona represents a significant portion of people in the real world and enables the designer to focus on a manageable and memorable cast of characters, instead of focusing on thousands of individuals. Personas aid designers to create different designs for different kinds of people and to design for a specific somebody, rather than a generic everybody.
Get hands-on experience of the context
Acquire hands-on experience of the use context as much as possible. If you are designing an AR-based collision-detection system for an excavator, be sure you step into the control room and learn basic maneuvres with the actual excavator.
These kinds of experiences have many benefits, they:
- Help you gain empathy towards users
- Help you understand simultaneous tasks
- Make you go through the same emotions as the user
- Motivate you as a designer
- Give you unforgettable experiences while working (great!)
So now you are with real users – why not observe them at their work and hold a workshop on the same day? Get another designer to accompany you – alternate the roles of documenting and observing users during the day.
Go through the materials and extract the most important remarks. Make iterative designs
The Setting (Location, time of day and weather)
Alright, let’s come up with a totally imaginary situation and platform.
Imagine this context: 7 mountaineers are trying to reach the top of Kilimanjaro. A storm arises, the group is dispersed. John and Andy are with each other, but Andy has broken his ankle. Luckily John packs a weather-proof mountaineer smartwatch – there is an app installed that is supposed to have one mission: Work as a beacon for safety helicopters to save mountaineers in danger. This app will send a GPS signal for the rescue squad in the background and is only used in emergencies.
Now let’s make a quick 5-minute mockup in Sketch. Once you open the app on the watch, you will see this. The soothing green with text informing you that you are not in any danger (I know, red and green are a bad colour combination).
Once you tap the green screen, the view will go red and the text will change – Now a rescue squad is on the way.
Great… But wait, there is a snowstorm on Kilimanjaro, and the text vs. background contrast may not be enough in bad weather. Here’s how the landing view would look like in a bad storm:
Indeed, we need to improve the text legibility.
Here’s the second iteration with larger text size and more contrast (black on white with green circle)
Here’s the snowstorm simulated again:
Now compare the legibility in the “snowstorm” – We gained some contrast and legibility with our changes, great!
As the smartwatch is positioned on the mountaineer’s hand, he can always bring the watch closer to his eyes to gain extra legibility.
If I were to be rescued, I’d like to know that the rescue signal is still being sent (my battery hasn’t run out). I’d also like to know that the signal is being answered. Let’s improve the rescue mode too. (I’ve made the same legibility changes also to this screen).
I’ve decided to add a GPS signal icon to symbolize the rescue signal being sent. Also, I’ve added a vibration feature to the app, so the person who is being saved gets a vibration on his wrist for 60 seconds (or so, this should be user-tested) and is aware that this rescue mode is on. It is reassuring for the user to feel the vibration and trust that the rescue squad is on their way. A soothing beacon…
But how does the user know that help is on its way? We need a way for the rescue squad to signal back to the watch.
Let’s split the rescue mode into two views: pending vs. on-its-way views. Let’s make these statuses as obvious as we can, so the mountaineer doesn’t have to think too much while their life is on the line.
We can make use of the circular red + text to signal these two UI states.
Here are all three final versions
Rescue app opened
Rescue request received
…And the possible state transitions.
The rescue operator would need a client to handle rescue events, but let’s not design this. It would be likely a web/desktop application and the operator would use a phone on his daily work.
What we have learned
Design is affected by simultaneous tasks and user’s emotions. In order to put yourself in the end user’s shoes, you should get first-hand experience with the context by defining personas and putting yourself into user’s shoes. Design changes based on the setting (Location, time of day, weather).
In our example, we ended up making changes to the original design idea based on understanding the use context.
- Haptic feedback
This was just a 30-minute example – more complex scenarios lead to more complex changes. What you need to do is iterate on the designs, and make end-user tests. Norman & Nielsen suggests that you only need to have 5 end-users to get saturated on end-user testing. Lean UX is a set of principles that rely on iterating the designs. Don’t forget to pivot if you need to!
To be continued – This was part 2 of a number of posts on the topic: “How to Prosper on Every Platform”.
Be sure to read part 1: Design Essentials: How to Prosper on Every Platform – Know thy Platform (Part 1)
In service design we talk about touchpoints, where, when, and how customers come into contact or interact with a service. A touchpoint can be many things:
- An artefact: a letter, a chocolate on a pillow
- Customer service: how support or sales staff treat and guide your customer, how they greet customers
- A full digital service or a website and everything that goes with it
Companies want all the service touchpoints to communicate company and brand values consistently and to provide excellent service to their customers. A service exists only to provide value to customers.
Touchpoints should be designed to deliver a successful service. The term orchestration is often used to describe all the actions as successful service delivery means that you are planning and designing processes, ways of working, touchpoints that work both internally and are economical (back end, support) as well as touchpoints that serve and delight the customer (the front end).
I’d like to share some insight into a study where we were testing a multi-touchpoint B-to-B, B-to-C service scenario with customers. In just one hour with a customer, we were able to get many kinds of feedback. Often studies are either explorative, looking into a theme or exploring a hypothesis. We are observing and interviewing to find the needs, wants, fears, pain points before a service is developed or improvement actions are started or then focusing on a single touchpoint and how to make that work better for the customer. Looking at the whole customer journey or some longer parts of it is less common, so, getting to do this multi-touchpoint study was a great learning experience!
Touchpoints that were in the focus of the study:
Advertising: different methods for drawing attention and advertising in web marketplaces
Environment: Our customer was introducing a change. Moving the service from their offices to a partner company’s facilities, they wanted to understand: Will the new environment promote trust? Will they lose brand value?
Customer service: What should be said and at what points in the process, what can be left to later? Tone: how to be helpful, how to induce trust? Timing: How long will getting the service take?
Artefacts: What information should the web service have and in what order? What is the minimum set of information that needs to be on paper?
Back-end and support processes and how these responsibilities should be shared with partnering businesses in this new way of working?
In addition to this, we were able to:
- Map out the customers’ earlier experiences.
- Test the value proposition of the service.
- Clarify the roles of the two service producing companies and organizations.
- Clarify communications, what should be said in online, on paper or by the customer service staff.
In order to be able to test all this, we had
- A quick interview including testing of our concept adverts.
- A scenario involving the real environment and our customer service staff. (we had two different customer roles, so, two scenarios were tested on separate days)
- Quick feedback interview of all the process steps, about the environment and customer service.
When the study had been done, I decided to stick the results onto a wall that resembled a mix of a service blueprint and a customer experience map with real-life artefacts (the fake adverts, and test versions of the different forms and photos from the environment). The swim lanes had different customer roles, notes for customer service staff, notes for both business 1 and business 2. And everything was moving in time:
- Discovery and decision making phase: How customers had discovered similar services earlier and how they compared offers, what was important in decision making.
- Service steps: What we discovered about the environment, customer service during the scenarios.
- Decision-making phase: Would you buy this service? Feedback about how it all felt, about timing etc.
All this required careful planning and the ability to ease the participants (both customer and the service staff) into the scenarios and acting.
The response that we received from our customer was “Great that we tested on such a concrete level.” “We received tools to take this solution into production, for example, a list of highlights for the Customer service staff, to make the customer feel at ease and informed in the different stages of the process.” “Good work! I’m really satisfied.”
For me as a designer, this was an exercise in careful planning and testing of the study setup before we started. It also proved that you can achieve a lot in just one hour with a customer. When one of the customers started to make a bargain at the counter, we knew that he was really into the situation and not faking it. People were able to throw themselves into the scenarios.
Making it real paid off.
Know thy Platform
If you have any hands-on experience developing a new software/hardware platform, you know how laborious a task it is. Developers, engineers, designer, usability experts and managers (amongst others) can spend gigantic hours on fine-tuning the subtle interplay of hardware components’ combined performance, UI interactions, animations, branding, usability and foremost – the platform.
Upon release, besides the huge marketing budget, documentation is one of the key aspects to make or break a new platform. See for example the iOS Human Interface Guidelines. Documentation quality has improved; this is a blessing of the 2010’s and the Internet, as the competition against other platforms is a make-or-break. Do not think that you are a platform expert after studying it though, as you might end up trying to come up with custom conventions / UI patterns that no user is familiar with. Trust the guidelines that the platform developers have provided for you. Do not re-invent the wheel.
Each platform comes with unique features; unique does not always mean great. It’s your job as a designer to harness the crème de la crème of each platform to suit your specific case. Understanding and unveiling the potential of a set of features each platform provides – that is the truest sign of any great designer.
Examples of platform features:
- Devices with large screens provide lots of area for multi-tasking or visually intense interactions
- Prefer NUI against GUI features as it is a more natural way of interaction for people (Read more: https://www.interaction-design.org/literature/article/natural-user-interfaces-what-are-they-and-how-do-you-design-user-interfaces-that-feel-natural)
- Physical knobs and switches
- Audio quality
- Voice control
I’m not going to explain how to get potential from each of these in detail now. Just understand them profoundly. Besides, platform features are an easy thing to spot – They are usually used in marketing materials / technical specifications of any product.
The fine-tuned staccato to make the platform reverberate needs to be harnessed in order to design the most functional and engaging experiences that take advantage of the platform in full capability.
Most platforms come with pre-installed applications – study them in detail and try to understand why certain decisions were made. If you are new to the platform, first try to design them in wireframes by guessing what the application does, only based on the icon of the app. Discussing with other bright minds can be helpful here. After making your own rough paper prototypes of the same apps – compare them with the apps provided.
Helpful resources for understanding the platform do exist most times you can find interviews, videos and blog posts online about those exact design decisions. That is just a part of how marketing works nowadays. The platform developers want to explain why they made specific decisions and what criteria were considered. Understand, though, that those 2-3 min videos may be an overview of a 12-month project. Go further and dig into the specific people interviewed, they usually have great Behance profiles, blogs, Twitter feeds or Github profiles.
Benchmarking is like listening, where you learn from other peoples’ knowhow. Stick with top rated applications for the platform, as their user value is confirmed by the users themselves. Also, big players are good at making great software. (AirBnB, Spotify, Facebook, Google, EA,…)
If the platform is brand new, consider similar platforms and their conventions – make your best guess on which of these to use in your specific case. Iterate a lot on the design by making rapid prototypes and test with real end-users. Build – Measure – Learn (- Pivot or Persevere).
Interacting with the platform
After you have familiarized yourself with the platform and maybe drawn some rough wireframes of your app, you can start planning the interactions themselves. To avoid cognitive load, you should keep to platform conventions and utilise users’ pre-existing knowhow. This means taking advantage of common human skills and reusing domains skills. The less you force the user to learn new things, the less annoyed she is.
It is not enough to know what looks good, but a well-documented platform also contains examples of dos and don’ts and explains when a specific UI pattern is relevant. See for example documentation of Material Design. It has plenty of case-by-case examples.
A well-documented platform will also provide alternatives to a specific UI component. Try learning the major components well and understand their most potential use cases – This makes it easier to pull out a component for a specific need.
Your customer might say: “Display a list of PS4 games and open each of them”. Basically, this should translate in your ears into: “I need a component that is able to display multiple elements in one view and allows the user to view a detailed view of each element”.
If you did your homework, finding a component like this from the platform pattern library should be rather easy.
Again, take advantage of all possible interaction possibilities of a platform, understand the context and go ahead – make that great interaction.
To be continued – This was part 1 in a series of upcoming posts on the topic: “Design Essentials: How to Prosper on Every Platform”.
It takes tremendous effort to design something that feels effortless and pure. But does your team have what it takes to get rid of the extra weight to get there?
It works – so why isn’t it selling?
Many solutions that we use on a daily basis are examples of good design. The ergonomics of your coffee pot, the non-slip coating of your toothbrush. The social media app that you browse on your phone, and the bot sending you a reminder about that thing. Our every day is surrounded by good design, but we’re rarely conscious of it. We’ve become accustomed to it, and we know to expect it. Good design has become a commodity.
The thing with design is that when it’s good, it becomes invisible. A good design gets the job done but that alone doesn’t get you ahead of the game; the leading manufacturer of rubber boots doesn’t compete with the fact that they keep their customers’ feet dry.
When you’re browsing for flights for your next vacation, you’re thinking about your previous experiences. The check-in. How the staff greeted you. The taste of the coffee. The leg room. The WiFi. You’re not buying the solution to get from A to B, but the experience as a whole. You don’t buy the thing you need, you buy the thing you want.
If you want your product to stand out, you’ll have to design for the experience. Thie key moments that make up the whole story.
It’s as if they’re not even trying
When watching the Olympic games, you see athletes reach 8 meters in the long jump, throw a javelin for 85 meters and sprint 100 meters in under ten seconds. These people compete at the peak of human performance, but you can’t help but wonder how easy it looks for them. It seems to come to them so naturally as if they’re not even trying that hard.
But the athletes know that being the best means stripping the task all the way down to its molecular level and cutting out everything that doesn’t contribute to the goal. Only then can they start enhancing the tiniest details that can improve their performance. It takes everything to put all of the focus and energy into only those few moves, but it’s only those few moves make up the whole performance and bring them to the top. But to the viewer in front of the TV, there’s nothing but the few seconds that look easy.
The same effect is in action with design: the better the experience or the end-result, the less visible the effort behind it. The best design always appears as if there’s no effort to it at all. But that’s an illusion, too. In reality, “effortless” takes the most effort.
Google Search is an excellent example of this. So much is happening under the hood, but it only takes one input field and a button to deliver everything.
Effortless demands the most
Ideas might come easy, but no excellent design is ever created on a whim. It’s never luck. I’d say 80% of a designer’s work effort will never be directly seen, touched or heard by the user who buys or uses the finished product or service. That effort goes to identifying, questioning, explaining and deciding what the remaining 20% needs to focus on: finding out the right why to design for and getting to know the people who to design for, before even starting to think about the what.
Every thought, desire, and motivation researched, mapped, and prepared for. Every decision, contact, emotion, and action anticipated and accounted for. All with the aim to orchestrate a certain kind of experience that leaves a personal, emotional imprint. It’s this rigorous work done in the background that makes the final design feel effortless, sophisticated and pure. Because, as the user or the customer, you’re experiencing only those few key things that you’re meant to.
Your product needs a weight loss program
In 1955, Dieter Rams wrote his well-known ten commandments of good design. One of these commandments goes “good design is as little design as possible”. Times have changed, but the principle has never been more relevant. Today, we have so much that we want our users and customers to see and interact with that it’s never difficult to fill a screen with information, interactive elements, and a bunch of features. It’s an embarrassment of riches. You’re going to need to leave stuff out to make it better.
But I’m not talking about having fewer buttons in the user interface or using a more limited colour palette – I’m talking about checking the pulse before giving your thumbs-up for another year of life support.
What if the real problem has nothing to do with the user interface looking outdated?
What if the feature you’ve been working on so hard adds nothing to the experience?
What if instead of giving it a facelift you’d get rid of the whole thing?
Wait, why are we doing this again?
The question of why is a powerful tool. It forces people out of autopilot mode and dares them to look at the big picture again. Make the why into a habit in the project, and it becomes a knife that starts separating the fat from the meat. You start to see more of the core. The things that matter and have real value.
But the deeper you carve with the why, the harder the decisions become.
Making the decisions to focus only on those few things that matter the most, and doing just those superbly – that’s the hardest job there is. Bubbles will burst, and a lot of people will get uncomfortable. There will be compromises and disagreements. But being the best at one thing means not doing the other thing at all.
In design, the devil isn’t in the detail, but the things that aren’t there. It’s in the choices that aren’t offered, and the white space that doesn’t make people think. In the end, it’s often the absence of the things that defines the design.
The next time you face an excellent design, think of the things that aren’t there. Only then can you truly appreciate the things that are.
Diversity and inclusion matters have been on the rise lately, and fortunately so. All of these topics are valid and serious issues. We strive to find solutions to some of the ongoing issues. This topic needs to be tackled from multiple angles, however, during this blog, we’ll look at how we can have a positive impact on the process as UX and Service designers.
A quick note on terminology
The acceptance, understanding and embracing of the differences in people including, but not limited to:
– gender, age, race, religion, disability, sexual orientation, and ethnicity.
– personality, education, skills, knowledge, and experience.
Inclusion is a collective of conscious choices to improve a supportive, collaborative and respectful environment. The idea is to increase participation for all employees regardless of the above.
*Diversity and Inclusion
This describes the company’s practices and strategies to boost the diversity and inclusion in the workplace. The aim is not only to be a noble company but, the goal is to achieve a competitive business edge.
What you can do as a designer.
Alrighty, enough talking about intangible concepts, let’s have a look at what we can do as designers to directly impact the diversification of a workplace.
1. Redefinition of masculinity and femininity through design
As designers, we help re-enforce stereotypical thoughts in our user’s mind. Challenge yourself to always think differently about gender roles. Why do Yoga apps always look delicate? Why are some pages still pushing for pink and purple to attract women? Stop designing sports pages with male-oriented linguistics. Choose boundary-pushing imagery, not sometimes but often. Whether it’s a female truck driver or male nurse, always challenge the status quo. However, be aware of pretentiousness, users can see right through that. Have a cohesive and holistic approach to achieve a consistent image of correct redefinition.
2. Discard assumptions and bias from your Design Thinking or UCD process.
Does the nationality of a person really add vital information to your persona or will that build more stereotypical assumptions? Are you covering all shapes and sizes of people in your user research? Thinking constantly about these questions will help prevent any backlash and produce truly inclusive products.
3. Re-evaluate “normal” and “average”.
Over the centuries we have been trained to think that normal equals homogeneity and diverse equals odd. A lack of diversity in traditional and digital media also trumps the development of diverse and inclusive concepts. As designers, we are constantly working closely with these mediums and we are able to redefine normal. Being diverse is normal.
4. Accessibility as a requirement.
Security aside, no doubt that most designers would like to create products that are accessible to everyone. However, most designers find it quite complex to create a product that is truly usable and useful for people that are less able in certain aspects. The reason being ‘working from the bottom down’. In other words, the thought about accessibility is considered at a late stage where further simplification might prove tough. Around 5% of the world is colour-blind, meaning that colour coding should always have an alternative in your design. In other words, do not rely on colour to communicate. In general, the solution to accessible design is simple. Have accessibility analysis as part of every step in the process. This is an extra step but that should be standardised to reach a truly inclusive experience.
5. Place yourself in someone’s else psyche
By placing yourself in some else’s shoes, often you can reveal emotions and needs that you might otherwise overlook. This is the next best approach, other than getting direct user feedback. Let’s look at an ethnicity form example where one had to make a choice from a defined list
What is your ethnicity?
Now let’s think about a person from the Middle East trying to fill in this form, he can either choose Asian as it happens that her/his country is situated in Asia or Other. Neither of those choices defines who that person is or what he identifies as. Such a form will extract false information and will create an un-inclusive experience that will indicate that the system or company has not taken his ethnicity into consideration. An alternative solution could be
What is your ethnicity?
O I Identify my ethnicity as …………………………
O I prefer not to say
This design will give equal importance to all ethnicities as well as a choice to not state ones’ ethnicity if they don’t wish to do so.
As designers, we often underestimate our role in society. Never have we had so much power to create a positive impact in the world. Our designs and products are getting distributed worldwide at a rapid pace. Thinking about the business value for our clients, without a doubt is important, and pairing it with a thoughtful design process to improve lives will transform us from good to great designers!
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.
FURTHER READING FROM THE GOFORE BLOG
In this blog post, I’m going to tell you about our design for an electric bicycle user interface, implemented using Qt Company’s software development kit. I’m going to go through the case with you and share some insights that we gained from the experience, especially in terms of how to design user interfaces with the very low performance (some might say cost effective) hardware in mind.
You can also watch a video of the presentation I gave about the subject at the Design Jyväskylä Meetup on January 17th (below).
For CES 2018, the Qt company wanted to demonstrate that an independent design and development team could effectively create an electric bicycle user interface that would be user friendly and also visually good looking, on entry level touch screen hardware. All of the UI had to run at 60 frames per second, on hardware that doesn’t have a dedicated GPU.
We took this demanding project as a creative challenge and put together a team of 2 UX-designers, 1 visual designer, and 1 developer, with skillsets complementing each other. The span of the project was only 8 to 10 weeks, which meant that we needed to work very efficiently and in a lean manner to achieve a great result.
The target hardware used was a very entry level resistive 5,7 inch touch screen, and a very low performance Toradex board with an integrated graphics controller. The development board in question had only a low amount of memory, which in addition to lacking a dedicated GPU made things tricky.
At this point someone might say: “60 frames per second, on a device that doesn’t have a dedicated GPU?! Is that even possible?”
It turns out that, with the right technology, people and knowhow; yes it is.
How the project went?
Initially we created 2 separate concepts with the target hardware in mind, in only a couple of days. After a review by Qt Company, we ended up picking the best parts of both concepts. We decided to go forward with a concept that incorporates a large main dial that sums up the most important indicators an e-bike user needs to have while riding and also a menu interface that the user uses by pushing the different quarters of the screen. The focus of the design was on ease of use and clarity of interaction on a not-so-sensitive resistive touch screen.
Each week, we would refine and further develop the initial concept. We would do development tests and visual designs straight away and then try to implement them on the target hardware and see, would it match our standards and would it run at 60fps. We also did some user interviews and testing on actual e-bike users during to project, in order to make sure that the final product would cater to their needs.
The final product can be seen in more detail on this short demonstration clip:
Insights for designing for low end hardware
The design methods or overall process doesn’t differ that much from normal when designing for low end hardware, but in our opinion a couple of things are more emphasised. Here are a couple of things that we learned:
Prototype and test early on the target hardware – Fail fast!
- Even though you can run your build on a desktop environment and get some sense of your design in action, the true insights on how your design works only come when you play around with it on the actual hardware.
- The look and feel is totally different (and is dependant on the hardware) and it reveals certain things that aren’t apparent in desktop mode. For example, colour presentation, contrast, usability with touching etc.
Prefer using images of UI-elements rather than drawing elements with the hardware.
- Qt can draw circles and squares to some extent, but more complex UI elements should be done with images to achieve a visually good looking UI that isn’t overly demanding for the hardware that doesn’t have a dedicated GPU and a low amount of memory.
Forget about dynamic transparency, fades etc for the most part
- For example, On/off type transparency is mostly ok, but dynamically changing effects, other than moving static UI elements around with anchors, is not recommended in terms of performance.
- Avoid changing the whole view at once, prefer changing only smaller parts at once for smooth transitions.
If you take away only one thing from this blog post, I think it should be the first point. One can not stress enough the importance of constant testing and prototyping on the actual target hardware, in realistic use contexts. The “Fail fast” principle applies to many different disciplines ranging from business to software design, and in our opinion, it applies strongly to designing for low performance hardware as well. So test a lot and prototype early in order to fail fast – it will make your design better.
Agile workshops help team building and create a deeper understanding of the Agile mindset. A well-organized workshop also gives the opportunity to step out from the normal work routine. There are numerous exercises for general Agile and teamwork topics, but fewer dealing with the project context. This blog post will introduce three simple exercises which can be used in any Agile workshop.
Definition of Done matrix
DoD (Definition of Done) is a crucial part of software quality. It defines conditions that a product must satisfy before it’s ready to launch. DoD also describes the team’s responsibilities towards the organisation. The common mistake is although the DoD has been created, it becomes outdated. The ‘Definition of Done matrix’ exercise is a straightforward method to update the project’s DoD.
The first step is to list the current DoD rules. The team writes down the rules to post-it notes, one rule to one post-it note. In the second step, the team attaches post-it notes to the Definition of Done matrix. The Definition of Done matrix’s four categories are ‘in use and important’; ‘not in use and important’; ‘in use and unnecessary’ and ‘not in use and unnecessary’. See the Definition of Done matrix below.
The Team negotiates together how every post-it note should be stuck to the matrix. After post-it notes are attached, the team creates possible new DoD rules and applies them to the matrix as well. Finally, the team collects all the post-it notes from ‘in use and important’ and ‘not in use and important’ categories and updates the DoD. This exercise outcome is the team’s shared understanding of the quality and an updated version of DoD. The whole practice is linear and does not need much moderation.
A staged interview with the Business Model Canvas
An unclear project vision is often the root cause of vague User Stories or a poorly prioritised product backlog. Typically, the team hears the vision only at the kick-off meeting, where the product owner introduces it. The following exercise turns roles upside-down, so the team take on the responsibility for the product vision.
Firstly, the Product Owner goes to sit in the middle of the room and the team starts asking questions about the product. The goal is to fill out all the elements of the ‘Business Model Canvas’. The Business Model Canvas is a simple tool for visualising the current business plan. The team can also use the ‘Lean Canvas’ template, which focuses more on a product’s early stages.
When the team has successfully filled the whole canvas, they pitch the vision to the product owner. This practice helps the team to understand the project’s goal and objectives. A short introduction of the canvas might be needed in advance.
The Disney Method with the real use case
The Disney method is a popular technique to generate ideas and solve complicated problems. The method helps to look at ideas or problems from different perspectives and includes all these ideas in a final conclusion. The method works well also in software development.
The team select a problem before the exercise. The problem could relate to integrations, deployment, architecture or some other part of software development. In the first stage, the team shares their ideas on how to solve the problem. This stage, there is no room for restrictions or criticism. The second stage, the team thinks in a more logical planning style how to implement the ideas. The last stage, the team provides a constructive critique of the ideas in order to find the weak points and solve them. Finally, the team votes best solutions for the next round. After two or three rounds, there is only one solution left.
As a result, the team reaches a solid creative idea with an action plan to apply it. The team might struggle during the exercise and in that case, guidance is needed.
Not just a free lunch
Agile workshops are not just an opportunity to skip weekly meetings and get free snacks. Workshops bring up themes which are not visible on a daily basis. Occasionally these issues surprise or even push people out of their comfort zone. However, with careful planning, an Agile workshop boosts the team morale and productivity to the next level.
Agile Games & Exercises https://www.agilesparks.com/resources/topicsubject-reading-lists/agile-games-and-exercises-list/
Definition of Done http://www.scrumguides.org/scrum-guide.html#artifact-transparency-done
Business Model Canvas https://strategyzer.com/canvas/business-model-canvas
Lean Canvas https://leanstack.com/leancanvas
The Disney Method http://idea-sandbox.com/blog/disney-brainstorming-method-dreamer-realist-and-spoiler/
Further reading from the Gofore Blog
Agile Transformation in Action – Part 1
Agile Transformation in Action – Part 2
What’s the point scaling Agile
My previous blog post focused on the side effects of ‘over documentation’s’. I identified reasons why so many projects are struggling with documentation and listed a few solutions how to prevent it. One of the solutions was that you should keep your documentation close to the source code.
Documentation as a service
As I previously wrote, documentation is valid only when it’s up-to-date. A development team will create and maintain most documentation, so it must be as developer friendly as possible.
Developers are craftsmen who make products with the help of programming code. If a developer can code and create or maintain documentation simultaneously, there is a good chance the documentation stays up-to-date. Next, we will see two examples of this ‘keep documentation close to the source code’ approach.
Dynamic style guide
A style guide is a comprehensive document that keeps track of all the common user interface elements for a project track of all the common elements for a project, from branding rules to the amount of bevelling for call-to-action buttons. On a more holistic level, a style guide defines the design philosophy for a company. A traditional way to create a style guide is in a separate pdf-document, which usually ends up being out-of-date.
A better alternative is to create a dynamic style guide. A Finnish software and consulting company SC5 Online has created a useful open source tool for this. The tool generates a style guide catalogue, where user interface elements and styles are grouped and visible to everybody. When a developer edits a style, changes will be updated to the product’s UI and the style guide catalogue.
The dynamic style guide eliminates the need for static style guide documents. Business people can review styles online and developers can make quick changes anytime. Ultimately, this approach simplifies and standardizes the whole UI design.
Software components need APIs (application programming Interface) to communicate with other components. Some believe that we will soon have an ‘API economy’, where organisations can positively affect their profitability via APIs. Anyhow, API documentation is a crucial part of the quality of software projects; the traditional way to have API documentation is in excel-documents, where data models, operations, URIs etc. are defined.
Swagger is a good example of a modern documentation tool. Swagger is a specification format that describes an API in a common language everyone can understand. Swagger packs everything about the API in a single and dynamic file which is easy to use.
The benefits of Swagger are clear. With Swagger, it is possible to design and document APIs simultaneously, thus keeping the blueprint and documentation in sync. Developers and non-developers can both have input to the API design because of the user-friendly UI. Swagger is readable by both human and machine, which gives a possibility to share documentation externally and allows powerful integration. Swagger contributes to API design in the same way that SC5 Style Guide contributes to style design – simplifying and standardising it.
Minimum Viable Documentation
Although all projects are unique, there are general documentation patterns that can be used. While reading my ‘Minimum Viable Documentation’ list, think how you could keep this documentation close to the source code in your project:
- How to get started – a tutorial for how a new developer sets up a development environment
- Design guidelines – see above
- API documentation – see above
- Definition of Done – define teams’ responsibilities
- Coding conventions – a set of guidelines and standards for programming languages
- Licenses – make visible which open source and other licences are used in the product
- High-level architecture descriptions – illustrates software architecture from different angles, for example, infrastructure, application, and integration. Favour pictures
- Maintenance process – if you can document a maintenance process, you can most probably also script it
- Principles for general tech. features – such as version control, authorisation, authentication, logging, validations, localisations etc.
- The most complicated business rules – such as complex algorithms, mathematical formulas and extensive searches
Fossil of the Project
‘It’s code which always wins; not comments or documentation’ is a common phrase. Still, many projects create way too high standards for documentation, although working software should be valued over comprehensive documentation.