Back in April the IIBA NW&E branch, in partnership with the BBC Academy, ran a successful event for over 100 Business Analysts at the BBC’s new MediaCityUK building in Salford. The presentations on the evening were recorded and made available via BBC Academy’s YouTube Channel.
Niko Vijayaratnam, BBC Future Media – News
The Business Analyst (aka. The Generalist-Specialist)
Most products in BBC Future Media are built by teams implementing Scrum yet Scrum doesn’t define a BA role… so what exactly does a BA in a Scrum team do? Niko Vijayaratnam, Senior Business Analyst in BBC Future Media – News, explores this subject looking at the work that BAs in BBC FM produce and discusses their importance to the success of recent projects.
Niko has been a Senior Business Analyst at the BBC since 2010 working on a range of projects from developing new in-house facing tools for editorial to audience facing products to cover events like the 2012 London Olympics.
John Taylor, ITV
Facing the challenge of working in a virtual office
John started his career 12 years ago working in an IT role, before moving into management accounting and finance. Eventually John found an ideal role to combine both of these areas working as a business analyst, specialising in ERP/corporate systems, which unknowingly his previous roles and experience had provided him the skills for.
Angela Stevenson, BBC Technology Solution Design
Angela is new to Business Analysis, or is she…
Angela began her journey into projects twelve years ago in the IT department of a car manufacturer, where the analysis phase was comprehensive, the objective closely guarded and the requirements rigorously tested.
Being an impressionable apprentice Angela believed all projects must be this way and so set off through a decade with variable success before finding the term ‘Business Analysis’ to neatly describe the way she worked.
Having just studied the academic side of the discipline in recent months Angela presents a light hearted look at how she is reconciling wearing both the BA and PM hats in her current role and how she aims to make the two happy bedfellows for successful projects.
The UK IIBA is a chapter of the International Institute of Business Analysis representing the Business Analysis (BA) profession in the UK. The UK Chapter was formed in 2006 and runs regular events across the UK as well as hosting an annual European Conference.
The UK IIBA is a not for profit organisation and reinvests all funding received with the aim of
supporting the onward development of the BA Profession.
Back in December 2011 the UK IIBA launched it’s first ever survey designed to:
Paint a picture of the Business Analysis profession in the UK to understand its maturity, and in future years, track changes to the profession.
To provide insight to related industries who work closely with Business Analysts informing services and product offerings.
To create an industry benchmark across a range of areas for BAs and Practice Heads to show strengths and weaknesses against BA practice nationally or in their Market Sector
The survey went out to:
The IIBA UK mailing list which contains email details of around 3,000 BAs (both IIBA members and non-members)
The IIBA UK Website
The IIBA UK Twitter account which had 468 followers at the time of issue
Through promotion to known organisations with a stake in Business Analysis including
AssistKD, BA Mentor, Barclays, British Gas, Certeco, EA Consulting Group, Hays, Hydrogen
Group, IRM UK, The JM Group, Nicoll Curtin, Pragnalysis, Randstad, Reed Professional
Services, Sanderson PLC and Skandia
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:
Creative design and review
Solution Assessment and Validation
Implementation and testing
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:
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.
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.
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.
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
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.
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.