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.
I thought it would be a good way to start my first few weeks as a robot expert at Gofore by sharing some very basic info about the robots I am mostly working with here.
RPA (Robotic Process Automation, “ohjelmistorobotiikka” in Finnish) is quite a new phenomenon in business process automation. Basically, RPA is a software robot which uses the computer by itself so it’s not a physical robot. The software robot will follow defined business process logic and usually emulates human interactions to execute the process. RPA often uses the graphical user interfaces of the information systems as humans do especially if there are no APIs available. This means that the RPA sits on top of the existing infrastructure and thus is not an intrusive technology.
RPA robots can be categorized into two groups: attended and unattended robots. Attended robots work in human workstations together with human employees. Attended robots can be started by humans or get triggered by events. They can run in the background or ask for human input if needed during the execution of the process. Attended robots can be useful, for example, in the service desk or other customer-facing operations.
Unattended robots work on their own at either physical or virtual cloud workstations without any human intervention. They usually execute high transaction volume processes by automated schedules. Unattended robots can, for example, process accounting tasks during the night so they are finished by the morning when employees come to work. Even though unattended robots work on their own in the background, they can be monitored, audited and managed by human “robot supervisors”. Skynet is not yet here…
What can RPA do?
Basically, almost anything that humans can do at a workstation. However, robots are still bit dumb so they can’t do something that requires complex human interpretation or thinking. On the other hand, by combining AI with the RPA, robots can do more complex human thinking requiring processes but practical implementations of these are still a bit rare. If the process has inputs in a digital, preferably structured, form and the process can be depicted with e.g. flowchart with unambiguous rules, it is most likely quite easy to automate with RPA.
Typically a companies’ RPA journey starts by automating support function processes:
- Finance (e.g. reconciliation, purchase to pay, reporting)
- HR (e.g. onboarding, payroll)
- IT (e.g. monitoring, user management)
- Sales and operations (e.g updating inventory, creating invoices)
With RPA, it is possible to use your imagination and do all kinds of fun stuff like making a robot play piano while filling in online forms: https://twitter.com/UiPath/status/1025155664421838849
RPA, chatbots and AI
You can automate a lot of processes with only RPA. However, by combining RPA with chatbots and AI you can do a lot more cool things. For example, RPA could gather data from legacy systems for AI to produce a prediction about maintenance needs for industrial machines. After that, RPA could set those machines to get a maintenance visit at an appropriate time. Finally, a chatbot could inform humans about the upcoming maintenance. RPA, chatbots and AI are interconnected like illustrated in the picture below:
Another example of combining RPA and chatbot is a bot which will buy train tickets for you: https://www.linkedin.com/feed/update/urn:li:activity:6430749212501168128
RPA vs traditional software development
Developing human mimicking RPA robots might not seem so sexy for traditional software developers but both methods have their pros and cons in process automation. During the last couple years, there has been a bit of hype about RPA and automating everything with it but it should be seen as just one tool for process automation and compared to other available methods case by case.
- Relatively easy and quick to implement and realize the benefits. With RPA, it’s possible to automate some business processes in just a couple of days or weeks compared to usually a much longer traditional software development time. For example, I have developed an RPA robot in four days which automated a quite tedious financial reconciliation process.
- Quite low-cost thanks to the quick implementation times and potential quick returns on investment
- Basics of developing RPA robots is quite easy to learn also for non-software developers
- Doesn’t disrupt existing infrastructure and systems
- It’s possible to do UI automation if APIs are not available and access basically every needed system and legacy systems
- Changes in existing infrastructure and systems can disrupt RPA robots. If the robot uses the UI of the systems and it changes considerably, the robot may need a reconfiguration
- Robots need to be managed in case of changes in the processes or IT systems. When scaling up to dozens or hundreds of robots all doing different tasks, managing them needs resources
- Traditionally developed e.g. integration between two systems is technically more effective than RPA
- Risk of taking quick wins with RPA and forgetting longer term more traditional system developments
Some RPA technologies:
- UiPath (current market leader)
- Blue Prism (main competitor of UiPath)
- Workfusion (offers a free version for enterprises)
- Robotframework RPA (Finnish open source solution)
At Gofore we are technology agnostic so we can evaluate your specific automation project and recommend the best technology available for your requirements.
Wow robots seem cool, I want to learn more?!
- Leave a comment for me – I am happy to help, for example, I could arrange RPA training.
- Start studying free courses about RPA developer and general business skills online: https://www.uipath.com/rpa/academy
- Download free community edition of UiPath and try e.g. automate some boring manual task you need to do: https://www.uipath.com/developers/community-edition
- If you are more of a software developer person you could also try Robotframework RPA
Today was the last day of the conference and it’s starting to show. People are heading home, so sessions are not that crowded and last session ends around noon / 1pm. People wearing conference badges are thinning out and replaced with more regular tourists.
I managed to get into a very good chalk talk about Cloudformation given by Check Meyer and Ryan Lohan. So a big thanks to them! We had a good discussion about tooling, feature requests and so on. This is also something that many people might overlook. AWS prioritizes features and their implementation on the basis of feedback received from customers. You do not have to be APN partner, done certifications, or anything like that. As Amazon/AWS themselves say, they try to be the most customer-centric company there is. The most important thing is that instead of silently contemplating on a feature or bug you should make yourself heard. Join AWS Developers slack. Use Twitter, AWS forums, email their evangelists or talk to their employees at any event. If the barrier is still too big you can email me or my colleagues and we can bring your case to AWS. Make yourself heard!
Finally, some tips & tricks in case you find yourself in Re:Invent 2019!
First, don’t be too greedy. There are tons of good sessions but the thing is – the sessions are recorded and can be watched at a later time Youtube. Chalk talks, workshops and hackathons are not. You get to talk to product-teams or their representatives in those. I can highly recommend attending those and if there are competing sessions at the same time try to prioritize chalk-talks and workshops higher than breakout sessions.
Second, as I’ve mentioned in the first post, Las Vegas is designed to remove your money from you. There will be coffee/soda/water provided by Re:Invent as well as some snacks. The expo area is excellent if you want to eat something. There is usually food being served. Hotels are expensive and if you need to buy something there are multiple Walgreens (shops) on the Strip.
Third, keynotes by Andy Jassy and Werner Vogels are great. However, you should consider passing the keynotes if there are some other interesting happening at the same time. For example hackathons or gamedays. Keynotes are usually recorded and any announcements made are also published on Twitter, blogs and so on.
Fourth, when booking your schedule try to cluster up the sessions/workshops/etc you are attending. Moving from one venue to another takes time. Cluster your sessions on certain venues. For example, The Mirage and Venetian are very close to each other. Moving between them is much easier than moving from Mira/Venetian to Aria/Vdara. On the other hand, Aria/Vdara/MGM are situated relatively close to each other.
Fifth, pick your parties. There are TONS of different parties hosted by AWS partners. You cannot visit all so choose early.
Sixth, talk to people. That might not be the easiest thing to do especially for us Finnish whose culture is not extroverted. “Hey, my name is Aki. What do you with AWS?” and the conversation takes on.
Now it’s time to sign-off and get some rest before starting the long trip back home. Quoting Werner now it’s time to “Go build”.
Jeff Bar, Abby Fuller and Simon Elisha before Twitch live