Written by

The User Story Map is a simple and yet powerful way to visualize the story about how the users are using your product or service – and to build the right thing.

It is simple because it offers support to move quickly from understanding the user and their problems – to building and shipping the product, and it can be done just with sticky notes on a wall, or in simple digital tools.

It is powerful because it tells a story, it gives context to the user story and it gives a clear overview of the backlog and what we need to build to be able to support the user scenarios over all relevant touchpoints. It also supports collaboration and both horizontal and vertical slicing.

I am forever thankful to Jeff Patton who is the creator of User Story Mapping and from who I learned it from about 13 years ago or so. Without it I don’t know where I would have been today. It has been one of the most valuable methods for me to enable deliveries of great user experiences although in very complex domains, real deadlines (like sports events that happens when it happens) with one or up to +20 teams 🙏

It is a living, transparent, and value-based backlog that support the Product Owners and teams to find thin slices to release that create real value based on user scenarios, and not features. If you are looking to become a value and product-driven organization, this tool offers a lot of support.

It might not come as a shock to you that the User Story Map is the most common tool used for Agile product planning with one or several teams.  Jeff Patton invented it and brought it in as a major part of the CSPO (Certified Product Owner) training when he first created that many years ago for Scrum Alliance.  Jeff Patton, with a background in UX and design, has been a great force in Agilizing customer-centric ways of working and finding ways to connect it in a natural way to Scrum and product teams.

User Story Map Concepts

A user story map tells a story about a type of person doing something to reach a goal. Make sure to include them in your map along with a little information about them. Try using lightweight personas or roles to describe your users.

User Tasks

User’s tasks are short verb phrases that are the basic building block of a map. If I ask you what you did earlier today when using email, you’ll likely respond with tasks like:

‱ Read an email message
‱ Respond to a message
‱ Mark a message as spam

User Tasks makes great User Story Titles
Write short verb phrases on cards or stickies. Use them later as your story titles. If you use the story template to write descriptions, the task fits
nicely right after “I want to,” the activity fits nicely right after “so that…”

Goal Level

The actions that users take in order to reach their larger goals have a goal level themselves that’s tied to user behavior.

Summary: lots of tasks done in support of a bigger goal.
Functional: I’d expect to complete this task before taking a break.
Sub-Functional: smaller things done in support of a bigger task.

As you read across tasks in the backbone, check to make sure that tasks are of a similar goal level. 

Activities

Activities organize tasks done by similar people at similar times to reach a goal. For your email software activities might include

‱ Going through my inbox
‱ Configuring my email client
‱ Organizing messages into folders

Narrative Flow

The left to the right axis in a story map is organized in the order you’d tell the story about your user to someone else.

Of course, any specific user might choose to do different things in a different order. Use conversation to explain the details and variations.

If you’re looking for the precision of a workflow model, flow chart, or UML model, then a story map isn’t your best choice.

A story map will take lots of conversation to use effectively. But then that’s the purpose of stories.

Details, Details…

Break down high goal level tasks into:

‱ Sub-tasks
‱ Alternative tasks
‱ Exceptions
‱ Details

It is ok to capture ideas for solutions are ok in the details of the user tasks or activities of what the UI might look like or what the system might do in the background. But preferably this is something that is done first with design studio or something to use the collective intelligence, and then as the team start to deliver in each sprint.

Release Slice

Draw a line across the map, or use a tape to identify slices of tasks that users might use your software to reach their goals. The smallest number of tasks that allow your specific target users to reach their goal compose a viable product release.

Use release slices to identify small experiments, minimal viable product releases, or a “walking skeleton” version of your product.

Identify the target outcomes of your slice in a sticky note or card on the side of the slice. 

Map Now & Later

Use a map to describe the world as it is today. Inject pains, joys and rewards, details and observations, and solution ideas. This can be done based on your Customer Journey, or your User Transaction Map, which are great tools to uncover the as-is-state of processes, complex interactions, and the experience.

Evolve the map using design and discovery activities such as storyboarding or design studio to describe the behavior you expect users to have in the future.

User story maps are for understanding now, and imagining later.


Map the Whole System

Map a whole process as it crosses through a number of types of users and touchpoints. Story maps are for looking at the big picture.

The Process of mapping

The story map evolves with your understanding of your users and your product solution.

1. Before mapping

Set the stage on what customer journey, product, service, and target users you most likely will have in your map. Remember this might be updated once you uncover the full story. This might tell you who to involve in creating it, and what customer journeys, user transaction maps, or personas that might need to be done before you move over to the user story mapping.

2. Map the big picture

Focus on getting the whole story. Think “mile- wide, inch deep” The activities and high-level user tasks that tell the whole story form the backbone of your story map. Look at the customer journey end to end, what they do before, during and after using your product.

Start with the user type most critical to your product’s success. Imagine a typical day in your user’s life with your new product, or use information from your user research and map it directly from your customer journey or user transaction map. Map the steps they take as user tasks left to right. It is ok to make assumptions at this phase, but all risky assumptions would have to be validated to make sure you deliver the right product and meet real user goals.

Identify user activities â€“ groups of tasks that work together to support a common goal. Activities often emerge after you see more of the story. Make sure the user activity end with the user reaching its user goal in that activity.

Add in additional users. As you follow the typical use of your product, you may find other types of users enter your story. Continue modeling their story left to right.

3. Explore

Fill the body of your story map by breaking down larger user tasks into smaller subtasks. During this phase, you’ll add cards, split one card into two, rewrite cards, and reorganize them. 

Any tasks and sub-tasks that might not give value to a user will be out of scope and not prioritized to build or work on, but this will be discovered later in the process when you start to validate your ideas and release.

It might be a good idea to timebox this phase. Keep in mind that “good enough” actually will take you longer than having all the details in now when you have the least information.

4. Slice our viable releases

Slice your map into holistic product releases that span the users and use of the product. These slices form an incremental product release roadmap where each release is a minimal viable product release.

For each release name the target outcomes and impact. Outcomes and impact say how this release contributes to the overall goal in the “big why” that motivates building the product, and how users will behave in a way that helps us reach the goal.

Example of release goals:

Release #1
 enabling the user scenario “Start an account, put in money and use it online” for the persona “Millenial Millan” 

Release #2 enabling the user scenario “Send and receive money from friends” for the persona “Millenial Millan”

For each release, identify product success metrics. Answer the question: “what would we measure to determine if this product was successful?” Ideally, you’ll find specific changes in user’s behavior as they use the product the way your story map imagines.

5. Slice out a development Strategy

Slice the first release of your map into three or more delivery phases that allow you and your team to learn fast and avoid risk. Think of the opening, mid, and end-game phases of a chess game.

This development strategy will help you release the best product possible in the time constraints you have.

  • Opening Game builds a “functional walking skeleton” â€“ the simplest possible functional version of the product. As you finish “Opening game” vet the product with users and other stakeholders. Begin validating wanted performance and scalability.
  • Mid Game completes all major functionality and makes existing functionality richer and more complete. Continue user testing and leverage feedback to adjust the product. Continue testing performance and scalability.
  • End Game refines the product in preparation for release. Continuously assess release readiness based on your release level product goals. Count on unforeseen work to emerge during this last stretch of development.

Once the User Story Map is up this is the living backlog that the Product Owner, or Product Owners use for continuous planning together with the team or teams. Based on the release goals the team(s) can plan what user tasks to cover, and the Product Owner(s) can re-plan the release goals based on feedback.

The User Story Map as the Product Backlog – with one, or several teams

A lot of times when using a User Story Map for a big project, you end up not doing about 50% of the storys. This is due to that those are not needed to reach our goals and satisfy our users. This of course saves a lot of time and money, that we can spend on the next prioritized goal.

When working Agile we want to keep our teams stable over time and they will release incrementally, and iteratively, and the teams always maintain what they built.

The user story map is a great way for the product owner to facilitate that ownership over time since the backbone of a process always stays the same they can add in new stuff when they learn about it, and re-plan their sprints and release goals. The map is also a great way to keep stakeholders in the loop on what the teams are working on, and what not. It is super transparent.


Want to learn more?

This content is part of our Agile Management In a Nutshell in our Digital Academy.

Agile Online Trainings at your own pace, in a fun, brain-friendly and engaging interactive format. Get access now!

Written by

HOW TO RUN THE WORKSHOP

Strategy is only as good as its ability to enable your product people to make smart decisions. It must evolve to remain fit for purpose. For those of you who want to make sure your product strategy serves your people, a collaborative approach helps you recognise and prioritise the most crucial gaps to work on.

The last post shares the product strategy health check template. Here’s one way you could work with it to align your POs, PMs, CPOs or whoever is in your product org chart. Co-creation is key to a shared commitment and conviction. Start with asking your product people to identify areas where they want more context. You can enable them a little better, each time, even if the official strategy is still in progress.

Treat it like a Kata, returning monthly or quarterly (but no less frequently) to prioritise the next biggest gap you want to close. A strategy isn’t grown in one night, so this is something that you can make more robust over time, piece by piece. Each time, gather product people to add what they know, then dot vote on which field they most need more data on to make informed decisions. Then split into pairs or small groups, choose one, and work on making it clearer before you next meet. This way, your strategy evolves over time, can gradually be strengthened, and benefits from collective effort. Don’t forget to remove old, irrelevant info as you go too. 

(more…)
Written by

All product companies likely have a document titled Product Strategy, but do they have a real product strategy? Perhaps you’re in charge of the product strategy and want to test and strengthen it. Perhaps you’re a Product Manager feeling the consequences of a strategy that isn’t fulfilling its promise. Do you see any of these symptoms in your product company? 

  • Direct solutions coming from senior stakeholders, without space for product discovery
  • Teams and stakeholders feeling the costs of context switching, working on very different initiatives, and spread thin
  • Teams caught by surprises, needing to help other teams working on very different initiatives
  • Senior product stakeholders unhappy with PM decisions closer to the work, even if the PMs are technically making decisions that fit within the strategy
  • Slick presentations promising upcoming, unvalidated features, rather than focus on opportunities

Alignment is crucial. You can get alignment by directly reviewing decisions, Or, you can share the appropriate information and decision making framework so that others can make smart decisions without the direct oversight. To scale, product leaders can no longer rely on personally approving plans. A leader’s role is to enable their colleagues to make decisions themselves. Especially in the days of hybrid workspaces, it’s all about the flow of information. Your strategy plays a huge role in that information flow. 

(more…)
Written by

Many Agile teams are struggling to connect user experience and the design process with Agile ways of working and often Scrum. In this Poster (and post) IÂŽm trying to describe the connection, and how you can collaborate in the team to learn more about user needs and solutions to solve real user problems together. IÂŽve been using this poster for over a year in my combined PO and UX training (Build the Right Product – Innovation through Collaboration & Design Thinking) and in my Agile coaching.

Download the Agile User Experience in a Nutshell in high resolution (PDF) >

Download in Portuguese >

Download in Spanish >

Download in Turkish >

Buy printed A1 poster >

Agile User Experience in a Nutshell Poster

My hope is that this poster might give some guidance in how User Experience can work in an Agile setup in combination with the posters; Agile Product Ownership in a Nutshell and Agile in a Nutshell (with a spice of Lean UX).

What does UX mean?

UX stands for User Experience. Basically, the expected and needed user experience of the service or digital product to meet user and business goals. To connect user needs and business goals is basic when working with user experience, it is basic to meet users and understand who they are – and involve and understand stakeholders. Any team can work with UX as long as they get to do this, and have the methods and processes to do it in a structured and effective way. (more…)

Written by

HĂ€r Ă€r min presentation frĂ„n konferensen Agile Islands pĂ„ Åland om hur man bestĂ€ller pĂ„ rĂ€tt nivĂ„ för att möjliggöra en Agil leverans.

Agile Islands anordnas av privata Agila företag pĂ„ Åland, deras gemensamma vision Ă€r att Åland ska bli ett Agilt samhĂ€lle. PĂ„ konferensen hade de Ă€ven bjudit in politiker, offentlig sektor och andra frĂ„n nĂ€ringslivet.

Jag beundrar verkligen deras starka visionÀra ledarskap och förmÄga. Ett vÀldigt trevligt och lyckat event. Tack för att jag fick vara med!

Written by

The Agile Product Ownership in a Nutshell poster that I published a few weeks ago has now been downloaded over 1000 times already, and there has been lots of great feedback. It is so great to see how it is being used all over the world. Now it has been translated to Italian as well thanks to the wonderful Angela Maile. Thank you so much Angela!

You can download the Free Italian poster here in high resolution for great print out (PDF) >

Italian Agile Product Ownership in a Nutshell

Here is Angelas blog >

Here you find the original Agile PO poster in English as well >

Agile Product Ownership in a Nutshell – Free Poster

Written by

This is a poster I made for a Agile intro class at Hyper Island Digital Business class 2017 where I and my colleague Per Lundholm was last week. The class was as big as 40 people, and covering from a couple of experts to mostly total novelty, which is usually the most difficult type of situation for a teacher or coach. But it went well, maybe not all thanks to the poster 😉 but it sure made it a lot easier for both me and Per as teachers, as well as the students who could follow more easily as well as take notes.

Free poster on Agile in a Nutshell
Agile in a Nutshell poster - Free download

Free Download of the poster on Agile in a Nutshell here (PDF)

EDIT 1: Due to some companies restricted IT policies the poster is now available directly here in the blogpost and not in Dropbox. Thank you for that feedback!

This poster covers both briefly the background to why we work Agile, some history and problems as well as values and principles. It also covers the difference between waterfall development and Agile in two aspects and the most common Agile practice, basic Scrum. Also I added some Lean practices to the mix to add a more advanced level to it.
(more…)

Written by

Next week on april 28th, we’re having the worlds first Nordic conference on Agile Procurement in Copenhagen!

The line up with speakers is extremely interesting. We have real cases from from Denmark, Finland and Sweden where Agile Procurement and Agile Contracts has been used with successful results. With a lot of the cases in the public sector. Also, there will be talks about the Agile contracts and time to mingle and talk to speakers after the sessions.

Conference on Agile Procurement
Key Learnings from the upcoming conference on Agile Procurement and Agile Contracting on April 28th, 2016.

We are starting to see a shift here in Sweden where the public sector as well as the private are starting to procure with Agile methods, but the Agile contracts are rarely being used. This makes it difficult to get the benefit from the Agile requirements process and the Agile development. What I believe is needed to change this is to give access to real success cases within the same field, and to get the lawyers to understand and wanting to try the Agile contracts. This is what the conference is all about.

I hope to see some curious Swedish government agencies on the conference getting inspired from the many great success cases from Denmark and Finland. It can be done, and it will change the outcome of so many projects.

Join us in this great event and spread the word of successful procurement and development of big complex projects!

Book your ticket here, we still have seats left!

Read the full Conference description here >

Written by

Att fÄ bygga, skapa, designa och uppfinna har alltid varit nÄgot jag Àlskar att göra. Egentligen spelar det inte sÄ stor roll vad det Àr, det roliga Àr att lösa problem, formulera vad jag vill, komma pÄ vad som gör det bra, skissa och se att det vÀxer fram nÄgot efter hand som jag inte kunde förestÀlla mig innan jag pÄbörjade arbetet.

Till vardags jobbar jag som kanske bekant för en del, med att coacha inom hur man bygger bygga digitala produkter, oftast Lean UX i Agila Team. Kanske Ă€r det dĂ€rför det kliar lite extra i fingrarna i bland att göra vĂ€ldigt fysiska produkter 🙂

HiFi prototyp efter nÄgra mÄnader frÄn The Game Crafter

LoFi prototyp
LoFi prototyp efter nÄgra veckor

(more…)

Written by

PĂ„ grund av att mĂ„nga försöker fĂ„ med “allt” I en IT-upphandling, Ă€r det endast 40% av det som byggs som gör nytta i digitala tjĂ€nster och produkter. Lean UX hjĂ€lper oss att bara bygga de 40% i stĂ€llet för allt.

Att arbeta med Lean UX Àr ett bra sÀtt att kunna identifiera vad vi behöver bygga, och prioritera rÀtt löpande. Men hur funkar det egentligen med Lean UX och Agila team?

Mina nÀsta kurser inom Àmnet under vÄren 2016: https://crisp.se/kurser/kurstyper/product-discovery-med-lean-ux

Jeff Gothelfs kurs för managers i Lean UX som kommer under vÄren 2016: https://crisp.se/kurser/kurstyper/lean-ux-in-the-enterprise

Upphandling med Lean UX och Agila kontrakt för upphandling med minskad waste: https://crisp.se/kurser/kurstyper/certifierad-agil-bestallare

Vill du att jag kommer och förelÀser pÄ ditt företag, eller hos din kund? Hör av dig!

Written by

Hur nĂ„got som egentligen Ă€r sĂ„ sjĂ€lvklart kan komma som en aha-upplevelse Ă€r en gĂ„ta – Ă€ven för mig som jobbar med det dagligen. För ett litet tag sedan höll jag en utbildning i upphandling och kravstĂ€llning, “Certifierad Agil BestĂ€llare”, efter utbildningen sa en av deltagare att den största aha-upplevelsen var insikten att vi ska göra en bra “behovsstĂ€llan” i stĂ€llet för kravstĂ€llan för att lyckas med upphandlingen och inte styra in pĂ„ detaljerade lösningar. Det var ju sĂ„ sjĂ€lvklart! Att jag inte har sett det förut?

I den stunden myntades ett nytt begrepp – “behovsstĂ€llan”.

Insikten hade hon fÄtt genom att vi hade gjort övningar i att gemensamt definiera mÄlgrupper med gemensamma behov, och sedan titta pÄ vilka dom behoven var genom att göra user journeys. Insikten att vi definierar befintliga beteenden och hittar problem som utgÄngspunkt i upphandlingen gjorde stor skillnad i att förstÄ att en lyckad upphandling mÄste vara en upphandling som utgÄr frÄn behov och löser riktiga problem för riktiga anvÀndare.

Ett skifte som mÄnga behöver göra

Ofta nĂ€r jag jobbar pĂ„ produktföretag, oavsett storlek, sĂ„ ser jag att just detta Ă€r Ă€r ett skifte som behöver göras. MĂ„nga företag fokuserar direkt pĂ„ vad lösningen Ă€r genom att beskriva en detaljerad lösning, i stĂ€llet för att först titta pĂ„ VARFÖR och för VEM, vad Ă€r behovet och vilka problem ska vi lösa? Har vi inte förstĂ„tt vad problemet Ă€r och för vem, sĂ„ kan vi inte heller hitta den rĂ€tta lösningen. Det faktiska utförandet av lösningen bör ligga i teamet, och inte hos bestĂ€llaren, det Ă€r dom som har kunskapen och verktygen att bygga lösningen pĂ„ rĂ€tt sĂ€tt, bestĂ€llaren bör fokusera pĂ„ att man bygger rĂ€tt sak.
(more…)

Written by

discovery-adn-delivery-process-w-one-team-small

Here you find the “Product Discovery and Delivery process with one team” as a PDF poster if you like to download it >

Ever since I saw Henrik Knibergs movie “PO in a nutshell” about how the PO role work for the first time I have been thinking about how he could have included the discovery process in the picture too. A while ago I created this as an example of how it could look and work for a X-functional team.

All ideas could be good ideas

The process starts with some kind of idea that could come from any stake holder – even from anyone in the team (this is usually a very rare occasion in most companies). The idea is verified in a concept (see example of a concept in my blog post on discovery framework) by the owner of the idea and the Product Owner decides if it worth starting the discovery process to figure out what it is they are supposed to build – or if it is not, based on the information in the concept.
(more…)

Written by

konverteringsoptimerin och hypoteser pÄ lantmÀnnen

I september höll jag en endagskurs hos LantmÀnnen i Konverteringsoptimering & Digital Design, som Àven inkluderade user research, anvÀndbarhet och effektstyrning och agil metodik. Den hÀr dagen var starten pÄ en serie utbildningar för LantmÀnnens centrala IT och marknad samt alla webbansvariga för respektive varumÀrke.

Tanken pÄ en gemensam grundutbildning föddes i vÄras av Anette Lovas som Àr centralt ansvarig för alla LantmÀnnens 35 EPI-webbar.

I min roll som centralt IT ansvarig för alla EPI-webbar sÄg jag en möjlighet att bidra med en gemensam kompetensplattform i modern utfallsdriven webbutveckling för att ge alla möjlighet att inte bara förvalta respektive webb, utan ocksÄ förbÀttra löpande pÄ ett effektivt sÀtt. Vi behövde lÀra oss att anvÀnda rÀtt data som beslutsunderlag för att skapa anvÀndarnytta och driva affÀrsvÀrde Àven online. Mia var given som kurshÄllare för den första delen av utbildningarna med sin erfarenhet inom konverteringsoptimering och effektstyrning samt att hon de senaste Ären har hÄllit mÄnga liknande utbildningar pÄ Crisp.

Webbansvariga i vĂ„ran organisation arbetar vĂ€ldigt mycket ensamt ute i organisationen och har fĂ„ gemensamma kontaktytor. Utbildning Ă€r ocksĂ„ ett sĂ€tt att mötas och diskutera hur vi pĂ„ LantmĂ€nnen ska arbeta med vĂ„ran onlinenĂ€rvaro, hitta synergier och utnyttja varandras olika kompetenser. “

(more…)

Written by

Product Discovery defines what should be built – and why. Collaboration Is Key. Your success with agile development depends on delivering the right product requirements at the right time.

During the past few years when I have been working as Lead UX or Product Owner I have come to a core process of how to do the discovery. At my latest gig on Viaplay as Chief Product Owner I had great use of some of these methods and also found it to be a great tool to have it visualised for all Product Owners in a one pager.

Within this process I see lots of different methods that may be used.As I use it I pick different methods in each level depending on organisation, product or project. Sometimes not all steps are neccesary off course. When working methodically for some time you start getting a feel for what seems like a good ide or not.

In this post I’m presenting a framework of the process as well as the methods in short formats. I will try to post more in dept posts on some of the methods going forward. Please let me know what methods you would like to know more about 🙂 Hope you find it useful in your daily work.

Download the one pager for Product Process and Tools here >

Here is my blogpost on the product development process with a continuous discovery and delivery process with one team >

Note: Due to some lazyness there are some Swedish material in this article also – sorry for that!

1. Strategy

Why are we doing this? What is the goal & desired impact? 

1.1 Concept
Concepts enables people passionate about a product idea, regardless of role, to realise it all the way to happy client. Concepts is a one page specification, in A3 format that represents a product idea of feature. It is enough to enable a prepared conversation with engineers developing the product. Think of it as a “flexible minimum specification”.  Mattias Skarins blog post on this http://www.crisp.se/concepts

Screen Shot 2014-09-05 at 11.08.12

Here you can download the Concept template I have created from Mattias Skarins examples > (more…)

Written by

Bakgrund
Kungliga Operan Àr Sveriges nationalscen för opera och balett och det har den varit sedan 18 januari 1773. Verksamheten har i dag ca 552 anstÀllda och bedrivs i Operahuset i Stockholm samt i GÀddviken dÀr man har alla verkstÀder.

Det Ă€r en stor och komplex operation att planera verksamheten pĂ„ Operan med mycket information som ska hanteras över lĂ„ng tid – en planeringshorisont pĂ„ 5 Ă„r med mĂ„nga inblandade i flera steg av planerings- och produktionsprocessen.

NĂ€r Operan hade fattat beslutet att gĂ„ över frĂ„n manuella och spridda planeringsverktyg utan gemensamma lagringsutrymmen som sĂ„g olika ut pĂ„ olika avdelningar till ett standardsystem sĂ„ tog Camilla Högström, IT chef pĂ„ Operan rodret som projektledare för upphandlingen av det nya systemet. Camilla kontaktade mig under sportlovet för att höra om jag trodde att det var möjligt att kravstĂ€lla utifrĂ„n verksamhetens -och anvĂ€ndarnas behov och vara klara med kravstĂ€llningen innan semestern. “SjĂ€lvklart!” svarade jag och undrade lite varför det skulle behöva ta sĂ„ lĂ„ng tid.

Effekter och KPIer
Vi startade med att tillsammans med styrgruppen sÀtta vilka effekter man ville uppnÄ med implementeringen av det nya systemet. Det resulterade i ett antal effektmÄl med mÀtbara KPIer. DÀrefter tog vi gemensamt fram vilka de olika mÄlgrupperna för planeringssystemet Àr och en hypotes om vilka deras största behov skulle kunna vara. NÀr allt detta var prioriterat och klart fick vi ett godkÀnnande av styrelsen och kunde fortsÀtta vÄrt kravarbete.

(more…)

Written by

Det hÀr den första artikeln i en serie av artiklar som handlar om olika ramverk för att generera och skapa hypoteser för att uppnÄ  mÀtbara effekter.

Vad Àr gamification?

Gamification (eller spelifiering pÄ svenska) betyder att man anvÀnder spelrelaterade element eller drivkrafter i nÄgot som inte Àr ett spel. Vanliga exempel pÄ det Àr till exempel olika lojalitetsprogram dÀr man fÄr poÀng för varje gÄng man handlar. Eller virtuella tjÀnster som dÀr anvÀndaren kan fÄ uppdrag som ger poÀng nÀr man utför dom.

Hur funkar gamification?

Syftet med gamification Ă€r att öka motivationen att göra nĂ„gonting, det ska ocksĂ„ finnas regler som ska följas – och det ska vara frivilligt. Det kan ocksĂ„ vara ett sĂ€tt att skapa en förĂ€ndring gentemot nĂ„got som anvĂ€ndaren sjĂ€lv vill, till exempel att trĂ€na mer eller Ă€ta mer hĂ€lsosamt. Det mĂ„ste dock INTE finnas en vinnare och en förlorare – men det ska finnas nĂ„gon typ av outcome – och det ska vara nĂ„gonting som gör det roligt och som anvĂ€ndaren kĂ€nner att de vill göra om.

Exempel pÄ gamification

Vanliga spelelement som kan (men inte mÄste) anvÀndas Àr:
(more…)

Written by

Att anvÀndarnytta och kundnöjdhet Àr viktigt för att bygga lÄngvariga relationer och öka Life Time Value (LTV), det vet vi. MÄnga företag ser det som ett strategiskt val att prioriterar arbetet med att öka kundnöjdheten.

HĂ€r Ă€r fĂ€rska siffror frĂ„n Oracle i deras rapport “2012 CX Index Report Europe Why Customer ‘Satisfaction’ is No Longer Good Enough”.

Key findings include:
‱ 70% of shoppers have stopped buying goods or services from a company after experiencing poor customer service
‱ 64% have, after experiencing poor customer service, gone straight to a competing brand to make a purchase
‱ 81% are willing to pay more for a better customer experience Clearly the subject of CX is front of mind for many executives.

In the recent Forrester report The State of Customer Experience 20121, 93% of respondents said customer experience is on their company’s list of
strategic priorities, with 28% stating it is their top priority. This is an inevitable reaction to the forces of globalisation, which has made it a difficult and risky proposition for organisations to compete on price or product alone.

TyvĂ€rr rĂ€cker det inte att slĂ„ pĂ„ för fullt i ena Ă€ndan av anvĂ€ndarupplevelsen – man borde man göra mer Ă€n sĂ„. Man borde inte bara arbeta pĂ„ att ha bĂ€ttre kundtjĂ€nst och öka servicen kring sin produkt – man borde ocksĂ„ förbĂ€ttra produkten sĂ„ att kunden inte behöva ringa kundtjĂ€nst för att lösa sina problem. Vad man borde göra Ă€r att ta reda pĂ„ hur kunden verkligen upplever produkten, och arbeta med att förbĂ€ttra anvĂ€ndarupplevelsen i grunden. HĂ€r listar jag 10 punkter som kan vara en hjĂ€lp pĂ„ vĂ€gen i det arbetet.

1. Minska smÀrtan och öka den positiva upplevelsen

Ta reda pĂ„ vart smĂ€rtan Ă€r som störst i anvĂ€ndandet av produkten genom till exempel anvĂ€ndbarhetstester. Gör de billiga Ă„tgĂ€rderna först – och sedan de dyrare. HĂ€r kan man anvĂ€nda sig av en matris för att prioritera de billiga och mest effektskapande Ă„tgĂ€rderna först. Lösningen pĂ„ problemet ges ofta av den anvĂ€ndbarhetsexpert som utför anvĂ€ndbarhetstestet. Lösningsförslaget sedan tidsestimeras av den som ska utföra Ă€ndringen för att man ska kunna vĂ€rdera kostnaden och effekten för affĂ€ren kan ofta sĂ€ttas av produktĂ€garen eller kunden.
Matris för prioritering

(more…)

Written by

De tvÄ sista veckorna som har gÄtt har jag haft möjligheten att fÄ jobba med hÀngivna och duktiga utvecklare och en ny product owner i ett nytt spÀnnande utvecklingsprojekt. Jag har dessutom passat pÄ att anvÀnda mig av en av mina favoritmetoder, story mapping (lÀs mer pÄ skaparen Jeff Pattons webb).


Som grund för story mappingen började jag med att visa och beskriva vilka mĂ„lgrupperna för vĂ„r produkt Ă€r, som personas med behov, anvĂ€ndarmĂ„l och problem, och till det effektmĂ„len som vi vill uppnĂ„ kopplat till affĂ€rsmĂ„l och dessa mĂ„lgrupper. Under tvĂ„ intensiva dagar lyckades vi sedan skapa en story mapping över anvĂ€ndarnas alla aktiviteter och delaktiviteter i produkten, frĂ„n början till slut. Som vi sedan tillsammans med PO prioriterade för release 1 och 2, gjorde user storys av och sedan efter mycket trixande (tyvĂ€rr) lyckades fĂ„ in i Jira (inte mitt favoritverktyg… men har man ett team i Sverige och ett utomlands sĂ„ mĂ„ste man i bland). Det betyder att alla som Ă€r med i projektet frĂ„n PO, projektledare, UX, design, backend- och frontendutvecklare tillsammans har mĂ„lat upp en ganska exakt mĂ„lbild för produkten dĂ€r alla vet exakt vem av mĂ„lgrupperna som vill spara ett event till sin kalender, eller hur sökningen skulle fungera med förslag nĂ€r man skriver text och vilka filtreringar som ska finnas för att anvĂ€ndaren ska hitta det de Ă€r ute efter pĂ„ bĂ€sta sĂ€tt.
(more…)

Written by

Jag mĂ„ste erkĂ€nna att jag ganska ofta sparkar lite bakut. För jag vill verkligen inte göra samma sak om och om igen – jag vill lĂ€ra mig nya saker, vrida och vĂ€nda pĂ„ det jag trodde jag visste och kunde, och trĂ€ffa och jobba med folk som kan andra saker Ă€n jag. Vilket dĂ„ kanske inte helt sjĂ€lvklart har resulterat i att jag gör saker som jag inte kan speciellt bra, men lĂ€r mig en hel del pĂ„ grund av det.

Kanske inget revolutionerande i sig, men för vissa kan det kanske finnas nĂ„got litet nytĂ€nkande eller till och med provocerande i det. Kan det kanske inte uppfattas som oseriös, naivt eller dĂ„ligt? Eller om man Ă€r mer optimistiskt lagd kanske modig, eller orĂ€dd eller till och med lite dum? Att man Ă€r öppen för nya saker innebĂ€r ofta att man lĂ€r sig nĂ„got och fĂ„r nya referenser. Och ju mer man vĂ„gar prova pĂ„ den spĂ€nnande o-vissa vĂ€gen – desto mer lĂ€r man sig ju, och desto roligare blir det.
(more…)

Written by

Iterera mera - Product discovery
I höstas köpte jag ett par vÀldigt billiga skor pÄ H&M, för sisÄdÀr en 250kr. Ett par stövletter. Anledningen till det var att jag ville testa om jag verkligen gillade att ha ett par stövletter eftersom jag bara har haft höga stövlar de senaste 15-20 Ären. Det var första iterationen pÄ mitt byta skor-projekt. Nu nÀr jag har upptÀckt att jag gillar dom riktigt mycket och dom börjar bli slitna, sÄ kÀnner jag att jag skulle vilja ha ett par skönare med lite lÀgre klack och svarta i stÀllet för bruna. DÄ kan jag tryggt gÄ till den dyra skoaffÀren och köpa ett par utan att kÀnna mig osÀker.

Gör du kanske ocksÄ sÄ i vardagen eller pÄ jobbet? I sÄ fall jobbar du testdrivet och itererar dig fram till bÀttre lösningar eftersom.

(more…)

Written by

Vi trĂ€ffades en kvĂ€ll i Crisps lokaler pĂ„ SveavĂ€gen ett gĂ€ng intresserade agila UXare, coacher och utvecklare för att prata om nĂ„got som vi alla tycker Ă€r spĂ€nnande, vill dela med oss av och lĂ€ra av varandra – hur man kan arbeta med att upptĂ€cka och utforska produkter och tjĂ€nster i ett agilt team – Product Discovery. Ett Product Discovery-team innehĂ„ller oftast tre roller, dĂ€r ingĂ„r en person med fokus och stenkoll pĂ„ de affĂ€rsmĂ€ssiga förutsĂ€ttningarna och mĂ„len (PO), en person med anvĂ€ndbarhets och upplevelse-kompetens (UX) och en person som kan avgöra hur enkelt eller svĂ„rt det Ă€r att implementera (Utvecklare/Arkitekt).

Vi pratade om vilka metoder man kan anvĂ€nda för att utforska och lĂ€ra sig mer om mĂ„lgrupper och behov och hur detta kan kopplas mot effektmĂ„l och visualiseras. Men ocksĂ„ om hur man skulle kunna gifta i hop Discovery och Delivery-processen till en helhet utan överlĂ€mningar och vi och dom kĂ€nsla. Vilket vi kallade “Continuos Discovery” – kanske myntade vi ett nytt begrepp? (more…)

Shopping basket
Our Trainings
The Agile Product Development Process and Organization Training & Toolbox – Online
Target Group: Anyone interested in doing Agile product development with customer focus and fast feedback loops and getting the business value from it.
Start at any time!