Visualising your backlog: Impact Mapping

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.


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.


  • Increase online conversions by 15% in the next quarter
  • Attract 20% more customers in the next financial year


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.


  • Students with a tablet device or smart phone in the classroom
  • Corporate employees with access to the secure drive


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.


  • Get faster access to accurate information
  • Have access to a wider network of colleagues to collaborate with


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.


  • Product galleries
  • Online purchasing


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.


  • 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.

Impact Mapping: Making a big impact with software products and projects by Gojko Adzic

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.

[1] Adzic, Gojko. 2012. “Impact Mapping.” [online].

Lean UX: Agility through cross-functional collaboration

Update: Jeff’s presentation is now available online.

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.

And is based on the values from the Agile Manifesto:

  • 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:

Figure 1: Lean UX Process. Source: Kevin Kauzlaric (
The Lean UX Process [1]
It started to make sense to me.

Note: I know it’s unfortunate that only this week I was tweeting that It’s Time to Retire ‘Crap Circles’, but it did the job!

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:

  1. 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.
  2. 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.
  3. 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!
  4. 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.
  5. 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:

  1. Lazy
    • Its not a shortcut
  2. The only thing being removed is waste
    • Leave the toolbox intact, just use it one tool at a time and at the right time
  3. 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.

Lean UX: Applying Lean Principles to Improve User Experience by Jeff Gothelf.

For more on Lean UX I strongly recommend this book. Mine is in the post!

For more on Jeff you can follow him here:

[1] Kauzkaric, Kevin. 2013. “‘Lean UX’ Can Propel You Ahead Of Your Competitors In Product Design” [online]. Published on 15th March 2013.

Applying ‘Persuasion, Emotion and Trust’ PET Design Theory in the Real World

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.

So what is PET Deisgn?

Well Human Factors International (HFI), the authors of PET design say:

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:

Blending Business Analysis with User Experience: the BA/UX continuum

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.

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
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: Designing user informed categories

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.


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:

  1. Breads
  2. Baked goods
  3. 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 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.


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:

  1. Pick & prep your cards
  2. Run your experiment
  3. Analyse your results
  4. Test your findings

Card Sorting: Designing Usable Categories by Donna Spencer

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.

Prototyping: understanding the benefits to fidelity

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:

  1. JAD sessions
  2. 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.

2. Task based user testing

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.


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.
[2] “Usability First, Glossary”. Accessed on 11th July 2012.
[3] Nielsen, Jakob. 2003. “Paper Prototyping: Getting User Data Before You Code.” Published on 14th April 2003.

Sigma Consulting: Technical Consultant

We Are Sigma
We Are Sigma
This 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.