We started the session with a quick look at the weeks homework – project briefs, Matt our course leader, gave some useful feedback. I quickly realised that I hadn’t quite hit the mark with my initial project brief by going too far in to the ‘solution zone’, I listed a mix of user goals and potential features in the order I thought that they needed to be completed, I will need to re-think what my defined user goals are for this weeks homework ! I have since re-written my project brief after confirmation from my tutor Irene that a brief should only look at contextualising the problem statement with a ‘brief’ outline on what kind of product could be designed to overcome the problem statement. This led on well to the main topic of discussion, the role of the business analyst and product manager. At the beginning of a project it is likely that the BA or PM will define what direction the project will be taking; often needing to write a brief off the back of multiple conversations with the client (they don’t always know what they want). Briefs are a good way to ensure that everyone is on the same page before budget spending kicks off!
BA’s and PM’s work to understand pre-existing project constraints and requirements, it requires a lot of effort to collect, document and make sense of all this information. Their roles differ company to company and there is often some overlap, in general a BA will work pre project and a PM will work throughout. They are concerned with how the company measures success and makes money, i.e. ‘what tasks does a user need to accomplish in order for us to be successful’. Where as the UX person is the voice of the user.
At some organisations, there is a formal business analyst role, but it will often be incorporated into other teams. They will study performance internally, proposing the strategic plans, business models, systems and processes to give skate holders evidence that the tasks currently being completed are the optimum ones. BA’s will often be looking at quantitative data, such as mass surveys, to justify decision making. Matt informed us that as a UX person you may need to keep your eyes open for signs that the client/BA has not been thorough/decisive and any questions or requirements that seem a bit odd…
The UX role can often expand in to a PM role as you gain responsibilities within a company. I went to a Soda Social MeetUp last week, Mike Atherton (who is a lead instructor at GA) spoke about UX Trends: it is his belief that in the future the UX and PM will/ should merge together or at least compliment each other better. Often a PM will make all of the decisions about product strategy which just leaves the UX Designers the ‘fun’ implementation task. He said that:
I predict that Product Management and UX design will merge into a common strategic function informed by brand values and company mission, and with iteration focused more on making the right thing, and therefore less on making the thing right.
The product management position was born about 10 years ago in the Silicon Valley because people were becoming more and more user focused. They are concerned with future planning, day to day task management and backlog consideration. They handle the co-ordination between the company, design and development teams, staying a few steps ahead to make sure that resources are not put in the wrong place, asking for different things from different people. They will have a firm hand on product iteration. Matt again gave us insights about what to look out for as a UX person working alongside a project manager; you may need to catch assumptions before they go to far in to informing product decision, you will also be responsible for the more subtle shaping of the product through the interactions it offers. Plus of course keeping everything user focused…
The BA and PM roles are essential in making sure that things in design are within project constraints, as well as making sure the company’s task list stays on track. A gant chart for example, is not a sure fire way to ensure that a everything will be completed on time: Things go wrong, timings are misjudged, user research and iteration will probably change the direction and there for the importance of particular features.
There are many challenges involved in these roles such as difficulties with fact collection; data may be owned by lots of different people or stored on a variety of systems, or not exist at all! Gathering requirements can be tricky (people come with different opinions), being able to understanding long complex lists is quite a skill and nearly everything they do will involve some sort of prioritisation.
Matt showed us some examples of when a company really needed some help from the positions I have just been speaking about. Who remembers the Segway? They were thought to be the next big thing in personal transport however they forgot to check transport laws and are therefore banned for pavement use in most countries due to health and safety reasons. We then saw a collection of websites which would be sure to bamboozle anybody looking at them, there was no clear indication about what the main purpose of the page was, visually there was lots of cluttered conflicting information. This is the result of no consensus around priorities, nobody decided on what was most important, users’ needs are not driving the train because the decision-makers’ agendas are. Sites also prioritises activities that are not directly tied to the business objectives which results in missed opportunities for business.
Project managers, product managers and business leads will have to deal with scoping, i.e. making sure that the features and functions that characterize the product are defined, its mostly an issue of money and time. Hopefully this is not something a UX designer will have to deal with, it is much easier to have someone else filing the client ‘tough guy’ position, so that demands and needs can be pushed back on them.
The creation of a good Minimal Viable Product is a good way of meeting scoping demands quickly and cheaply, there are other benefits also. The lean process initially developed in Silicon Valley lets designers and developers to work closer together to produce this MVP, this process was introduces to us in week 1. Matt showed us this slide which sums it up nicely, the MVP has to actually function it can’t just be part of a whole.
This process gives faster real-world user feedback and will advocate continuous learning. It is better to try it out in its rawest form before it is too late to make changes. Looking at the Lean process model, the MVP sits somewhere to the right and in-bewteen build and product, here is the sketch I made in class:
Part of the scoping process will also be the gathering of requirements. Where solicited input from all stake holders will need to be confirmed. A bridge needs to be built between business needs and user needs -everyone’s voices need to be heard. Publicly prioritise the requests and define the scope based on existing resources/time/budget. Aim for the Least amount of effort i.e. the Minimum Viable Product philosophy…
Deliverables can include choosing backlog items for the ‘sprint’ in the lean method, managing user and business requirements, the final say on personas, scenarios and user flows.
Mat then led us though a group discussion, showing us sites where the user and business goals are fairly aligned (although he didn’t tell us this first!), we had to analyse what these were. Generally the user wants something and the site wants to make money . So on booking.com – the user wants to book a holiday and the BA wants them to book with them.
Our second task was to look at more complex task analysis. The example website was facebook, as a class we came up with the different goals for the user and the business, clearly these are very different:
During the creation process, goals form tasks which will inform features. Definitely something to note for our personal projects. i.e on facebook:
- Goal = Share Photo
- Task = Share photos from holiday
- Feature = ‘Bulk upload’
This led on nicely to a chat about feature prioritisation and how competitive analysis can sometimes help with this, the sweat spot is between ‘essential’ and ‘low effort’. It is possible here to piggy back of things learnt from competitor analysis where key flows and features have been analysed to get that MVP out: