I’ve recently completed the Design Sprint 2.0 Facilitators Masterclass, the most up-to-date and improved version of the Design Sprint developed by AJ&Smart and the original creator Jake Knapp.
The Design sprint is a four-day workshop process for answering critical business questions through design, prototyping, and testing ideas with customers. Developed at Google Ventures, and largely credited to Jake Knapp who authored the book “Sprint” in 2016.
In the book Knapp emphasises that he applies design philosophy, thinking, and approaches to solve various organisational challenges such as the launch of new products or features, growth, improvement of internal processes, innovation, and development.
Combining the best practices of Design Thinking, Lean UX, and Agile Knapp created a clear, efficient, rapid, and adaptable framework to reduce risks of innovation, align teams on the same vision, and eventually save money and time.
Design Sprint 2.0
There are a number of changes in the 2.0 version of the design sprint that make it more efficient and flexible, allowing you to achieve the same outcomes in less time.
The Sprint takes 4 days. Originally it was 5. This became possible by improving the general flow with some new elements (User Test Flow), changing the order of exercises (starting with Expert Interviews) and their structure (Mapping the System). This is really helpful for those that deliver sprints to customers, as Friday can be used as a write-up day.
Senior stakeholders are involved for just 2 days. In the first version of the Sprint your ‘Decider’ (CEO, senior executive, director) was required for the entire duration of the Design Sprint. This was a serious bottleneck as often executives weren’t able to clear their schedule. In Design Sprint 2.0 you can leave the last two days to the designers and interviewers and let the CEO and management go. They will receive the report with all the insights afterward.
Expanded organisational focus. The initial version of the Sprint was very much focused on delivery benefits to tech start-ups. However, Design Sprint 2.0 expands this framework making it accessible and relevant to large and small businesses across different sectors, not for profits, government departments, and NGOs.
What next?
I’ve already delivered my first Design Sprint and have supported the delivery of some great remote sessions, while not working in the office. I’m looking forward to sharing more about them in the coming months.
This post is the first in a 2 part series on visualising your product backlog. The second post will look at Story Mapping.
Recently on a trip to Sweden I was introduced to Impact Mapping, sometimes refereed to as effect mapping, as a collaborative work-shopping technique for identifying software features and mapping them back to organisational goals and user personas. The following article is a summary of the technique, as described in the book Impact Mapping: Making a big impact with software products and projects by Gojko Adzic, along with a mix of my own observations from being involved in facilitated Impact Map sessions.
So what is impact mapping?
Well according to Gojko Adzic, an Impact Map is [1]:
A visualisation of scope and underlying assumptionsm create collaboratively by senior technical and business people. It is a mind-map grown during a facilitated discussion
Impact Maps can help you build products and deliver projects that make an impact, not just ship software. Impact mapping is a strategic planning technique that prevents organisations from getting lost while building products and delivering projects, by clearly communicating assumptions, helping teams align their activities with overall business objectives and make better roadmap decisions.
How do I impact map?
Working your way through the following questions with your team or customer will allow you to build up an impact map from scratch. These are often best achieved in a facilitated workshop environment with a number of key stakeholders represented.
Why
Defining the business goals is essential for any project and its the focus of Impact Maps. Why are we doing this? What is the goal that we are trying to achieve above all else?
Goal definition is about understanding the problem, not the solution. It should not be focused on specifically creating a product or application, rather explaining why its existence would be useful. It can be useful to try and tie the goal to the organisations value chain.
Examples:
Increase online conversions by 15% in the next quarter
Attract 20% more customers in the next financial year
Who
The first branch of an impact map looks at actors. For anyone who has spent some time with UML or traditional use cases you will know that actors can range from end-users and external suppliers to third-party applications or systems. Try and capture decision makers and those able to achieve the goal you defined or aid/block it from being achieved by others.
Consider the following questions at this stage:
Who can produce the desired effect? Who can obstruct it?
Who are the consumers or users of our product?
Who will be impacted by it?
These are the actors who can influence the outcome of your goal.
Examples:
Students with a tablet device or smart phone in the classroom
Corporate employees with access to the secure drive
How
The second branch level of an impact map sets the actors in the perspective of our business goal. Don’t list all the activities that an actor might want to take, just the ones that are focused on achieving your goal.
Consider the following questions at this stage:
How should our actors’ behavior change?
How can they help us to achieve the goal?
How can they obstruct or prevent us from succeeding?
These are the impacts that we’re trying to create. Note: They are not product features.
Examples:
Get faster access to accurate information
Have access to a wider network of colleagues to collaborate with
What
Once you have answered the goal, who and how questions you can start to consider and define your scope. This is the third branch level of your impact map and starts to identify the top level features of your product.
Consider the following questions at this stage:
What can we do, as an organisation or a delivery team, to support the required impacts?
What is the minimum that you can deliver to achieve your goal
These are the deliverables, software features and organisational activities. Do you not get too detailed at this stage and consider what the shortest route is through your map to the goal. It is very unlikely, and is potentially not a wise investment, to deliver all the features identified in your map.
Examples:
Product galleries
Online purchasing
When
This is a section that I have added but its a step that I find useful to help understand how a feature will help the organisation to achieve their goals. Agile uses the phrase “Definition of done” and in a similar way I like to think about “What success looks like”.
Consider the following questions at this stage:
How will you know when your goal has been achieved?
What action or level of engagement will signify a success for your feature?
How long will it take to get usable data from this feature?
The outputs from these questions will help formulate your measures or metrics. Where possible you should measure the smallest individual unit Avoid vanity measures, page views and impressions are worthless unless they prove an increase in conversion or engagement from your intended users.
Examples:
A completed signup form
A social media share
What are the outcomes?
In Adzic’s book he describes deliverables as being features, lines of code that helps organisations in achieving their goals, and of course he is right. However, I’ve often found it’s useful to understand at what point your Impact Map will be ‘finished’ and what the immediate deliverable from the exercise are.
Firstly if you are creating your Impact Map in a workshop then it will be produced within a timebox and will most likely be completed within the one session. Impact Maps are collaborative artifacts and unless you have all your stakeholder representatives available after the workshop, it’s not wise to carry on developing them in isolation.
Secondly, the largest deliverable from me as a business analyst are a prioritised list of features and measures, mapped against their actors (or personas) and goals. This allows you to quickly slice your Impact Map into a product backlog, understanding that what you have is probably high level epics that will require some breaking down into smaller stories.
The diagram above shows how you can map the who, how & what into stories that can be worked up.
What do I need to impact map?
When I first drafted the outline of this post my intention had been to discuss different types of mind-mapping software here. And for the record, I use Xmind and have had some great results with it.
However, having written this post now, it’s clear to me that what you need in order to effectively Impact Map is a good mix of stakeholders who can represent both your organisations goals and your users needs. Without access to them you will not produce an effect map that adds real value and your roadmap and backlog will be flawed from the start.
If you’re interested in Impact Mapping you’ll need to get a copy of Adzic’s book. This colourful and illustrative book take you through the basics needed to facilitate and create an Impact Map for your team or customers.
Today I was lucky enough to attend Jeff Gothelf’s O’Reilly webcast on Lean UX.
I was particularly keen to attend the webcast as I’ve been around Agile projects for some time, performing business analysis activities and supporting clients through rapid prototyping, but I wasn’t sure how to make UX activities Agile and I was hoping that this webcast would help me answer that.
Well the good news was, Jeff explained that Lean UX is inspired by Agile development theories:
Lean UX is the practice of bringing the true nature of our work to light faster, with less emphasis on deliverables and greater focus on the actual experience being designed.
Individuals and interactions vs. processes and tools
Working software vs. comprehensive documentation
Customer collaboration vs. contract negotiation
Responding to change vs. following a plan
Up until this point I hadn’t really seen any differences between Agile software development and what Jeff was describing as Lean UX. That’s when Jeff explained how Lean UX is really based on the Lean Startup Process. And how Lean UX had evolved the Lean Startup process to create this:
The Lean UX Process [1]It started to make sense to me.
There has been a shift from can this product be developed (technically) to should this product be developed (because our users need need/want it).
Jeff went on to say that “In a fast-paced environments, traditional UX is a bottleneck. We have to change perspective on how to “do” UX, today’s markets require a new way. A faster way. Designers can no longer hide behind their monitors any more! This is a designer led initiative. Get designs out there. Fast. In public – where others can see them.”
5 Things you need to do to be Lean
In Jeff’s presentation he suggested 5 tactics that you can do to help kickstart Lean UX into use in your projects:
Solve the problem together
As opposed to implementing someone else’s problem.
Give them a problem to solve – not guidelines to implement a solution.
This team will be far more effective, motivated and productive if you do.
Sketching – it’s all the rage!
Get the ideas out of peoples heads.
It’s NOT drawing, we don’t need to see the finished article. And you can do it collaboratively.
Doing it together allows software engineers and designers to problem solve.
Sketching brings experiences to life faster.
Prototype it [Amen!]
Build an experience, not a document.
Once validated, demo it to the team. And get everyone started.
There are no additional deliverables needed!
Pair up! But do it, cross-functionally.
Pairing saves time and builds a common language and a common understanding of the challenges.
You start to free up your designers and empower your developers.
Developers don’t have to wait for a design to start coding something and designers are freed up to do something difficult.
Start a style guide
The cause of, and solution to, all UX problems.
A catalogue of the code snippets, the colour palette, the elements, the graphics.
Lean UX is not
If you’ve been around Agile projects in the past you’ve probably had to defend the things that it is not to the outside world. Lean UX is no different:
Lazy
Its not a shortcut
The only thing being removed is waste
Leave the toolbox intact, just use it one tool at a time and at the right time
This is not a design by committee
That never leads to anything pretty
What did I learn?
A lot. As I’ve been writing this post I’m considering more of what Jeff described and how it can be worked into projects that I’m working on. There were a few nuggets that will stick with me though:
The Goal: Moving forward in parallel path with development and design.
‘The Spec’ doesn’t control: Lead with the conversation, trail with the documentation (that you need).
The Pepsi challenge: Use data to settle subjective issues. A/B testing can settle them.
Go for bronze: You’re not aiming for gold medal work. It needs to be ‘just’ good enough.
Every design is a hypothesis: Don’t design things people don’t want. You can find out if people want theses things before hand.
Validate your hypothesis with the users: Keep it light and cheap. Put it in your diary once a week – get 3 or 4 people in and show them what you have ready to show them.
[1] Kauzkaric, Kevin. 2013. “‘Lean UX’ Can Propel You Ahead Of Your Competitors In Product Design” [online]. Published on 15th March 2013. http://kevinkauzlaric.com
This month I was fortunate enough to have been asked to speak at a conference, alongside my colleague Chris Bush, on the topic of PET ™ Design Theory, “Persuasion, Emotion and Trust”. The conference was being hosted in Gothernburg, Sweden by Maverick, a Swedish based digital agency by Sigma.
PET design uses research-based techniques to leverage the science of Persuasion, Emotion, and Trust to make websites more engaging, compelling, and effective. This innovative methodology complements classic usability, empowering companies to achieve their business goals.
Presentations and Resources
We presented two sessions on the topic, an introduction to PET and then a session looking at some examples of the PET design applied.
Introducing (PET ™) Design Theory, “Persuasion, Emotion and Trust”
Applying Persuasion Design and PET ™ Theory in the Real World
Camp Digital 2013 Presentation
At our recent Camp Digital 2013 event, my colleague Chris Bush presented on the same subject, his slides are available here:
6 Months ago I joined Sigma, a User Experienced design agency. I joined as a BA, to support the team and the their clients, designers and developers to evaluate, specify and deliver successful solutions.Movie Passengers (2016)
I had initially thought that I would be part of the development team, having over 5 years experience of delivering software projects, but I’ve found myself working with the UX designers. While design is not what I would have traditionally called my domain, I’ve been surprised at the amount of cross-over my BA skill-set has with that of a UX practitioner.
Both BAs and UX practitioners use analysis, design and research to identify and document business goals and user needs. While their titles might suggest that their roles are focused on opposing areas there is a great amount of overlap.
Academics at Berkeley have suggested that the overlap can be viewed on a continuum:
The Berkeley Continuum
So what competencies and skills do a BA and UX practitioner share?
I’ve attempted to map a number of core competencies and skills against the Berkeley Continuum as a way of illustrating what divides and unites the BA/UX roles. It could also be used to identify who is better placed in your team to undertake certain activities. It could also be used to help individuals who wish to transition between the roles, identify which skills they need to develop.
I should note that these are very general classifications of competencies and are not always strictly followed in practice. Just as an example of my own work experience, as a BA I’ve spent a lot of time working in the area of Interaction design (traditionally a UX competency) and yet I have never done a Business case.
But as it’s often said, “It’s not what you’re called, it’s what you do that counts”.
Card sorting is a technique for informing Information Architecture. It allows the architect to collect data on users categorisation preferences and gives them an opportunity to observe users discussing their reasons behind their choices.
Over at Boxes and Arrows Donna Spencer and Todd Warfel describe it as:
A great, reliable, inexpensive method for finding patterns in how users would expect to find content or functionality. [1]
An example
Imagine you’re standing in the supermarket and you’ve been given a list of items to purchase. The list is in no particular order and is completely uncategorised. You read down the list:
Shopping List:
Chicken
Oranges
Sweetcorn
Cotton wool balls
…
In your head you’re already starting to think “Is the Chicken in the meat aisle or the freezer section”, “Do I find the Cotton wool balls with the baby stuff or with the cosmetics”
This is what a user is doing when they come to your site for the first time. They’re trying to find something and they’re looking at the sections on your navigation and trying to work out where to go first. Which section titles best describe what they are looking for.
So how does Card Sorting help us with this? Well we do something similar to standing our users in a supermarket with a shopping list, except this time we ask the to group the items and name the groups in a way that makes sense to them.
Note: The following method is for an observed/moderated experiment. There are a number of great tools available on the web to help you setup remote/unmoderated experiments, however, I find that while these are great for producing a lot of data quickly, you lose the context provided by observing the users as they discuss cards and move them between categories.
Before you start
Picking your cards
I work on the basis that 75 cards will take your users about an hour to sort. So consider how many cards your users will be able to sort effectively in the time available. Also consider which pages to sort. You should strip out any category pages, as these will be replaced by your users newly named groupings. Typically you should be looking at 2nd/3rd level pages.
Preparing your cards
There are 3 things that I’d recommend each of your cards having:
1. A unique ID
This is purely for administrative purposes. It allows you to identify the cards during the analysis phase. Make sure it’s random and doesn’t relate to the section that the page currently lives in (if you’re experimenting with an existing site). Make it small, you don’t want to lead to the users into groupings based on the ID.
2. A page title
If you’re testing an existing site you may be able to pull these straight from the page titles in the metadata. However, if your page titles have been optimised for SEO (or spammed with keywords) you may want to clean these up so that you don’t mislead the user.
Watch out for any pages that may have duplicate names like “FAQs”. Some sites have one of these pages per product or per section, consider renaming it to “Product Name – FAQs”.
3. A short description
Again this may be able to be pulled from your pages metadata. The same consideration applies to SEO optimised descriptions. If the page title is a little ambiguous use the description to supply some context to the page.
Here is an example based on our supermarket scenario:
Free range corn-fed British chickenThis delicious and richly flavoured bird has a characteristically golden colour to the flesh, which comes from its maize based diet. The hens are reared in the same way as our other free range birds.
#1
If you’re any good with a spreadsheet I’d recommend setting up a mail merge to print these. Depending on who you’re asking to take part, their location and the time between the sorts talking place and being able to start the analysis, you may need several sets of cards printing.
Recruiting users
Consider who you’re going to recruit to represent your users. Make sure that your sample is as representative as possible of gender, age, nationality, skill and role/user type.
Card sorts can be done with an individual user but you tend to not get a lot of discussion with users sharing their thought process or opinions. For this reason I’d suggest groups of 2 or 3 users so that there is plenty of discussion, you’ll be able to hear where there is consensus and where there is disagreement.
When recruiting users I would recommend a minimum of 5 groups, as this will give you 5 unique sets of data to analysis. While this is just my opinion it is loosely based on Jakob Nielsen’s Why You Only Need to Test with 5 Users.
If your site or application has a diverse range of users then perhaps consider 3 groups of each user type, or persona if you have created these.
Grab a copy of the analysis spreadsheet
Donna Spencer, whose definition of card sorting I used to open this post, has done a lot of work in the area of card sorting. This includes the production of some fantastic resources and materials to help you with your card sorting.
While the post is 5 years old the resources are regularly updated to ensure that formulas continue to work in the latest versions of excel etc. So for that reason I’d like to point you directly to Donna’s post on the Rosenfeld website.
Running the experiment
After the planning, the preparation of the cards, recruiting your users and scheduling the sorts to take place – running the actual sorts is relatively straight forward. However, there are some things that you can do to make the sorts go more smoothly:
Have a facilitator
If you’ve run any workshops in the past you’ll be more than use to facilitation. You should consider using the same skills to facilitate an experiment. The sorts of things that you should lookout for are as follows:
That everyone in the group is having an equal input
That the group is working as a team and not working against each other
That the group remains on topic
Do your best not to lead a group into making decisions, but you can advise or clarify to some extent if the group are running into real difficulty.
Run through an example
Just as I have given the example of a supermarket in this blog post you should make up 10/15 cards in advance that you can show the group. I like to use items from around the house. This quickly shows that items can be categorised by room (bedroom, lounge, kitchen etc) or by type (electrical, furniture, soft furnishings etc).
Be sure to explain that both are valid ways of categorisation and that the users should go with the approach that they are most comfortable with.
Observing and scribing
As well as having a facilitator in the experiment I would suggest having someone available to observe and scribe. If you have access to an observation lab the scribe could sit in the observation suite taking notes and recording the discussion and actions made by the group. It is not essential that your scribe be hidden away, I have been known to sit in on the experiment, recording, note taking and in some case photographing the groups activities.
If you are unable to get a scribe it as at least worth considering recording the session. Most iPods/iPhones will record through the headphone socket using the headphones straight to mp3 and you’ll be grateful of having something to go back to when you’re writing up your findings.
Spare cards and envelopes
Although this is a relatively low-cost experiment you’ll need to raid the stationary cupboard a few times…
It’s always worthwhile having some blank cards with you. Some users may want to split content or duplicate it into multiple categories, like the cotton wool balls that live in both ‘baby stuff’ and ‘cosmetics’. Allowing your users to duplicate the card by hand and putting it in both categories will act as an aid when it comes to the analysis.
You should also have a number of large envelopes with you. I like to take large A4 envelopes with me and allow the group to write on them and use them as placeholders for their categories. At the end of the experiment you can quickly collect up the cards and store them in the envelope that they are piled on. If you are doing more than 1 sort on the same day ensure you write which sort the cards belong to clearly on the envelopes.
The analysis
Once you’ve populated your spreadsheet with all your categories and cards from your sorts its time to start standardising your categories. When doing this you’re looking for 3 things, in my opinion:
1. The groupings of the cards into categories
Irrespective of the categories name, you want to look out for agreement by users that a set of cards should be categorised together.
2. The names given for the same category
Once you’ve identified that all your users put the cards bread, french stick and bagels into the same category then it’s time to review what they called those groups:
Breads
Baked goods
Bakery
You will have to come up with a naming convention and try to be consistent across all your categories. It may even be wise to consider search term traffic if you are looking to optimise your site for search, when picking a category name.
3. Spotting the dump category
When undertaking your analysis be mindful of the users that were in the groups. Consider their understanding of the content and if they are the target audience for all your content. I sometimes refer to something I have observed in the past as ‘the domain specialists vs. the dump category’.I’ll give you an example, where in a supermarket would you find Quorn (imitation meat mycoprotein) or a USB stick? If you’re a vegetarian or cook for vegetarians there is a good chance you know exactly where to go for the first item. Likewise, if you are into gadgets and are tech-savvy there is a good chance you’ll be able to find a USB stick in a supermarket and you’d know where to put it in a card sort. However, if you are neither a vegetarian or techie then you may simply give up. You may even create a category called ‘Misc’ and dump cards that you don’t know where they fit into it.
More on analysis
There is quite a bit more to the analysis of card sorts, probably enough for another blog post on its own. As I suggested earlier, some of the best resources on ‘using the spreadsheet’ can be found on the Rosenfeld resource site.
Testing your new categories
So once you’re pretty happy that you have your categories, you have the items in them and you have determined a logical hierarchy, it’s time to test your IA. The following 2 methods can help to validate your IA:
Treejack
Treejack is an IA validation tool that allows you to test your IA without visual distractions.
You can create tasks for a user to undertake such as “You want to buy some fresh bread to make bacon sandwiches at the weekend, where would you locate the fresh bread?”.
The tool tracks the users path through the navigation and produces reports on their outcomes.
Task based testing
Once you have Treejack tested your IA it’s time to include it in any prototype that you would build during the design phase of the project. At Sigma we are big advocates or developing prototypes for testing, prior to sites or applications being developed.
Both these approaches will give you insight into how users interact with your categories and the content within them. Based on the results you may want to refine your IA further and re-test.
Conclusion
There are a lot of steps to this post and you may need to refer back to them at different times. The steps to a successful card sort are:
For more on Card Sorting I strongly recommend this book. In it, Donna describes how to plan and run a card sort, then analyse the results and apply the outcomes to your project.
It’s a great addition to the bookshelf and a great reference before, during and after a card sort.
[1] Spencer, Donna & Warfel, Todd. 2004. “Card sorting: a definitive guide.” [online]. Published on 7th April 2004. http://www.boxesandarrows.com
If you’ve been around any software development projects then there is a good chance that you’ll have seen wireframes. Some sketched, maybe some mocked up in prototyping tools or crafted in photoshop. They are a popular tool to help conceptualise page layouts or even go as far as to demonstrate interactions in an application.
The level of detail or interaction that is present in a prototype is often described as fidelity. Fidelity is the degree of closeness to the “depth, breadth and finish of the intended product” (Hakim & Spitzer) [1].
To help explain the difference between low and high fidelity the following definitions are from Usability First:
low-fidelity prototype
a prototype that is sketchy and incomplete, that has some characteristics of the target product but is otherwise simple, usually in order to quickly produce the prototype and test broad concepts. [2]
These are the prototypes that you’d sketch in your notepad when describing the layout of a page or the interaction of an element with a colleague. You may capture them in a meeting with a client as a visual record of what has been discussed, so that you can work them up later into a design concept or higher fidelity prototype.
high-fidelity prototype
a prototype that is quite close to the final product, with lots of detail and functionality. From a user testing point of view, a high-fidelity prototype is close enough to a final product to be able to examine usability questions in detail and make strong conclusions about how behavior will relate to use of the final product. [2]
Unlike the quick sketch in your notebook, a high-fidelity prototype is at the other end of the scale. It’s likely to be rich with interaction, styled graphics and layouts that give the appearence of the finished product.
These are the two extreme end of the scale and in reality you will often be working somewhere between them. Some prototypes will have interactions but not so much visual treatment. Others will be worked up to a high level of design treatment but are just flat images, produced in photoshop with some image regions placed over the navigation to give the impression of a clickable ‘wired-up’ prototype. The reality is that often prototypes are just the vehicle to help us prove a concept or elicit requirements. They are not the end goal, just a means to help you reach it, so we take them as far as we need to go – as far as they remain useful and then we stop and move into code. Your choice about whether you go with a low vs high-fidelity approach is likely to be based on a time/cost/benefit decision, and each project is likely to be different.
There is nothing wrong with low or medium fidelity prototypes. I’ve worked on a number of great projects where this level of prototyping has generated some real rewards for all parties involved. However, more recently I have been working with very high-fidelity prototypes in two new ways. They are:
JAD sessions
Task based user testing
1. JAD Sessions
The purpose of a JAD session is to dramatically reduce the timeframe required to complete a deliverable where consensus is required by getting all of the major decision-makers, stakeholders, and knowledge providers into one place all at the same time.
The real-time production of a prototype during a JAD can help stimulate the discussion, capture decisions and demonstrate ideas and concepts to non-technical stakeholders.
Questions like, “What fields do we want to be capturing during the signup process” are easily answered when a marketing representative is present along with your database administrator. Consensus is reached and the prototype is updated to reflect this detail. The designer gives his input on the layout and one of the developers is able to highlight a constraints of the existing technology stack used. And then you move on to the next decision.
The prototype acts as the living record. The organic deliverable that in the space of 2 or 3 days has grown to encompass all the requirements, decisions and actions.
Task-based User Testing is all about learning how users interact with your application or website in order to access information and complete tasks. Nielsen states that the biggest improvements in user experience come from gathering usability data as early as possible. He estimates that it’s 100 times cheaper to make changes before any code has been written than to wait until after the implementation is complete [3]. With this in mind it’s important to get user feedback and research findings as early in the process as possible, waiting until the site or application is live can be costly and impracticable.
While the prototype is not the finished product it’s important that it is worked up to a very high fidelity so that users are comfortable with its look and feel and aren’t distracted by inconsistent elements or broken interactions. The prototype requires a high level of polish and a set of well crafted scenarios to test and journeys through the prototype.
Working a prototype up to the is degree of fidelity requires time and skill but it’s a worthwhile investment to ensure that you can capture user feedback in the design phase, before any code is written.
Conclusion
Prototyping at any level will give you a great return. Your decisions on how close to make it to the finished product will depend on your budget, your deadline and the influence you are trying to achieve with it.
[1] Farnum, Chris. 2009. “What you should know about prototypes for user testing.” [online]. Published on 29th July 2009. http://www.boxesandarrows.com
[2] “Usability First, Glossary”. Accessed on 11th July 2012. http://www.usabilityfirst.com/
[3] Nielsen, Jakob. 2003. “Paper Prototyping: Getting User Data Before You Code.” Published on 14th April 2003. http://www.useit.com
We Are SigmaThis month I joined a fantastic team based in Macclesfield called Sigma. The aim of my role is to support Sigma’s clients, designers and developers to better evaluate, specify and deliver successful solutions. Most of this is done through requirement elicitation, rapid prototyping and user testing.
Sigma are a user-focused digital communications company, who design and build smart solutions for web, mobile, and corporate applications.
They are the centre of excellence for user experience and digital services in the Sigma group, a Swedish based IT Services Company with over 1500 staff globally.
I have already had some great exposure to clients and projects. The team use some fantastic workshop techniques which I’m keen to post about soon.
Recently I wrote about User Stories and how card based software development can help identify ‘clear, brief descriptions of functionality as described from the perspective of a user’.
Today I want to look at how User Stories or ‘Stories’ can impact the user interface (UI) design and user experience (UX) of a software product.
So what is UX?
Don Norman (2007), Nielson Norman Group, describes it as
All aspects of a person’s experience with the system including industrial design graphics, the interface, the physical interaction and the manual.
I like this definition. It goes beyond the traditional Human Computer Interaction (HCI) thinking of physical device design. It goes beyond the point of how a user engages with a mouse and keyboard to get to the site or system and focuses on the software design and how the user interacts with it.
While there are many approaches available to User Experience Designers, Business Analysts and Software Designers, I’m going to be describing my approach to implementing UX in agile projects. I’m going to attempt to directly map these activities to the IIBA’s BABOK V2:
Elicitation
Persona Development
Story Writing
Analysis
Prototyping
Creative design and review
Communication
Managing Stories
Solution Assessment and Validation
Implementation and testing
Elicitation
Persona Development
Early last year I wrote about Users, Roles, and Personas and how they can help you as a BA to understand the users that you are designing systems and solutions for.
Stories are written from the human perspective, e.g. As a user I want to be able to do this or that. This is the shift I mentioned earlier from some of the more traditional “Systems Thinking” where we modelled what the system wanted to do. However, we can take this further by integrating Personas, by making the Persona the voice of the story.Watch Full Movie Online Streaming Online and Download
In other words, if we do a Persona workshop in the early stages of the project, each story that is created should correspond to one or more Personas. Let’s user a Facebook user, Rick, as our example. After modeling Rick and working up a relevant Persona, we can now leverage that in how we create and talk about our stories. For example, we can add a Persona prefix to our story statements:
Rick Says:
As a User
I Want To upload a photo
So That other users can view it
With this short prefix, we’ve both helped to make the story feel real and made a connection to a particular user that will perform this interaction. As we have conversations about this story we can talk about what Rick would want or not want, rather than what some anonymous and disembodied Facebook user.
Story Writing
In a recent post I covered the process of writing user stories using the Card, Conversation, Confirmation format. While I’m not going to cover the entire topic again here I’d like to stress the importance of getting real users to help write stories.
It’s also important to try and separate out design and requirements until you start to prototype and work on design concepts. Try to avoid allowing users to write the sorts of stories where they dictate UI implementation to you. These can often be expressed as “I want to ‘click on a button’ to” or “I want to ‘select from a list’ something”. In my experience a user is trying to help you, but often they are describing a legacy systems implementation of a particular feature and this can distract from why the action is being preformed and focus too much on the how the action will be performed.
Analysis
Prototyping
I could write an entire post on prototyping, and probably should. I am a real advocate of both low fidelity (lo-fi, often used to describe hand drawn or basic static wireframes) and high fidelity (hi-fi, often used to describe interactive prototypes). I am always amazed at how much feedback you can get from users by showing mock-ups and prototypes. As a caveat to this, my last note about not mixing requirements capture and design still stands. Try not to just sketch a quick solution in your notepad and show it to users in workshops. This can sometimes lead to a false setting of expectation and doesn’t allow you to properly test and capture feedback on the design.
Prototypes can perform two key functions:
1. They can be used to give early validation to a solution. Remember, user stories are small chunks of a bigger system. We can get validation feedback that the feature is correct, without having to have every page and feature implemented.
They allow you to observe the user’s interaction with the proposed solution. I often find this activity more valuable then a users verbal feedback. This could take place in the form of formal lab testing scenario or as informal stakeholder reviews.
Creative design and review
In my experience visual treatment is usually applied to a prototype after it has been tested and signed off by the client. However, I know some teams don’t differentiate between the prototyping and creative stages in the process. To these teams the development of the prototype and visual treatment is the same stage, and their prototypes use the brand guidelines and colour pallet to allow for a much richer experience.
This is one of the exciting things about UX. As we move away from traditional HCI, UX is much more about the emotional experience than the physical one. UX is not just about demonstrating functionality ie. “If I click this then…” but far more about the journey that you are talking the user on to make engaging with your feature an enjoyable one.
Visual treatments and concepts can be tested at this stage also. User-centered design (UCD) focuses on analysing and foreseeing how users are likely to use a product, but also in testing the validity of their assumptions in real world tests with actual users. This can be performed in labs or using a range of remote testing solutions.
Like other aspects of agile, this is an iterative process and may take a few rounds of testing, feedback and implementation before the agreed design is agreed and put into production.
Communication
Managing Stories
There are a number of ways to manage stories, from story boards, spreadsheets and project management systems. While I don’t have a personal preference, I do use redmine for the electronic copy of my stories. Like other aspects of documentation on your project the important things to think about are:
Ease of collaboration
Visibility
Traceability
While it’s important to keep good documentation around your stories, these aren’t bound documents that BA’s working on traditional projects will be writing. It is important to think about how you can make them visible to the rest of the team and/or stakeholders. They should living documents, growing organically as more information comes to light.
The benefit of tracking these in a ticketing system like redmine is that you may even be able to offer traceability with the code repository. Other teams may check their stories and tests into SVN to live alongside the code.
Since my last post on the subject I have updated my base redmine user stories template to allow for some additional fields that you may want to capture when performing UX activities.
Solution Assessment and Validation
Implementation and testing
This is one area within the BABOK that I struggle with. While I obviously believe it’s important to validate a solution and test it, I’m not sure that I agree that this is a formal activity that happens at the end of the development life cycle. I think that the BABOK may be referring to a degree of formal signoff or UAT that takes place, however, on agile project my experience is that this happens on a much more regular occurrence.
Testing and validation of a solution can identify issues that can often be quickly and inexpensively corrected during the prototyping and design stages.
Conclusion
As Business Analysts we need to consider the use of such practices in our toolbox to help us communicate and demonstrate solutions to our clients or business teams. At the same time they can be used to collect rich feedback on a project before a single line of code is written.
Defining the business goals is essential for any project and its the focus of Impact Maps. Why are we doing this? What is the goal that we are trying to achieve above all else?
The first branch of an impact map looks at actors. For anyone who has spent some time with UML or traditional use cases you will know that actors can range from end-users and external suppliers to third-party applications or systems. Try and capture decision makers and those able to achieve the goal you defined or aid/block it from being achieved by others.
The second branch level of an impact map sets the actors in the perspective of our business goal. Don’t list all the activities that an actor might want to take, just the ones that are focused on achieving your goal.
Once you have answered the goal, who and how questions you can start to consider and define your scope. This is the third branch level of your impact map and starts to identify the top level features of your product.
This is a section that I have added but its a step that I find useful to help understand how a feature will help the organisation to achieve their goals. Agile uses the phrase “Definition of done” and in a similar way I like to think about “What success looks like”.
