Upgrade to Pro — share decks privately, control downloads, hide ads and more …

The agile process explained (for non-technical people)

The agile process explained (for non-technical people)

To many people, the term agile web development is still something new. Although they may have heard of Agile and read a few articles about it, many people still tell us that it’s hard to visualise how the process will actually work.

Non-technical people involved in a web project often ask: “what should we expect?” To help them understand in simple terms, we’ve produced a ‘How We Run Projects’ slide deck to shed a little light on how the agile process works within Browser.

Rene Morency

May 28, 2015
Tweet

More Decks by Rene Morency

Other Decks in Technology

Transcript

  1. We create beautifully designed web products that help people work

    better
  2. An overview of how we run projects…

  3. We work in four phases Discovery Alpha Beta Go-live Research

    Workshops Analysis Sketch Prototype Test Refactor Test Analysis Refactor QA Objectives Design IA Consultancy Planning
  4. The Discovery phase

  5. Discovery Setting expectations and discussing your ROI • It’s suggested

    that before we proceed with the project we need to discuss the deliverables versus the cost and how varying levels of complexity will affect the cost - this will help ensure budget is spent where it’s most effective. Technology Interaction
  6. Discovery Data analysis, what can we learn from the existing

    data • We investigate relationships and behaviours highlighted in the analytics, research data, surveys & questionnaires. 
 • We discuss barriers to entry and technology available prior to a kick-off meeting, during the initial kick-off meeting we’ll discuss and draw insights together which will influence the forthcoming workshops. Research & data Website optimisation report
  7. Discovery User input and involvement from the start • We

    meet, discuss and draw insights from both stakeholders and users during a series of focus group workshops. These workshops help to solidify the business and user objectives that can be used to compose user stories, user journeys and influence the information architecture. Business objectives User objectives
  8. Discovery Our existing knowledge • We’ve been developing digital products

    for over seven years now, during that time we’ve learnt a lot about users and their expectations. This valuable knowledge will be brought through to your project so you too can benefit from all of the research and development undertaken so far. User feedback IA planning
  9. Discovery Persona development and user stories • Using research and

    workshop data we map out personas together with you. Who, why, what and how are the main focus of this exercise. Personas are used throughout the project for identifying and sense checking against development tasks. 
 • We look at creating high level user stories that assist with mapping user journeys. It’s important at this stage to measure user needs against business objectives and prioritise accordingly. Prospective international student Internal staff Prospective student Research user Who, why, what
  10. Discovery Mapping user journeys • Using our research data, personas

    and high-level user stories we use various tools and methods to map user journeys - all with the focus on what a user needs to do and why (their objectives). This process often works in conjunction with re- engineering the information architecture. Map and test Refactoring
  11. Discovery Engineering the IA Identify problems Test solutions • Using

    all of the research and analysis we architect how content is accessed, what to include, and what functions are required to fulfil the user needs. This works in conjunction with mapping user journeys and light prototyping (perhaps using Keynote or HTML/ CSS) and user testing (perhaps using Treejack).
  12. Ted Baker Sunglasses Discovery Improving discoverability • As part of

    our development cycle we advise on keywords and content creation for SEO (for organic search). Using feedback from the workshops we share our knowledge on how to create content that users want, and how to present it (link building, creating inbound content).
 • From a technical perspective we write semantic code and correct page/site structure that helps assist with SEO (organic search). Your product
  13. The Alpha phase

  14. Daily video meeting • If possible we like to run

    a daily video meeting (a scrum) which is 5 mins max. We will guide you through our thoughts, and development (via screen share) we also share and discuss potential problems. The main purpose of this exercise is to keep everyone focused on the project in hand. This exercise has been to be a bit hit with our clients. Alpha 5 min scrum Screen share
  15. Alpha Sketch the content and template design Quick sketches •

    We’ve found the quickest way to map out an interface and communicate ideas within the team is through an open discussion and quick sketching or wire framing. It’s great for quickly visualising concepts, user journeys, information architecture and user interfaces.
 • Products usually consist of several bespoke template pages that are used to accommodate the content and functionality. We use this early stage process to plan out what’s required and where it goes.
  16. Alpha Prototyping • We use various tools and methods to

    rapidly prototype our initial sketches, these come in various forms such as interactive visuals or HTML/ CSS wireframes. These prototypes are then tested by users and the feedback is used to refine the product during our weekly iterations.
 • Prototypes are built to test; navigation, information architecture and usability amongst other things. These are sense checked again both business and user objectives before moving forward. Press play
  17. Alpha Build and test Business objectives User objectives • During

    the build process we either invite users to our studio, or remotely test the interface against a range of tasks (user stories). We’ve found that the most successful way of doing this is to keep it informal on a one-to-one basis. • The results are recorded and sense checked against the business and user objectives to ensure the project remains on track.
  18. The Beta and Go-live phases

  19. Beta User acceptance testing (UAT) • We’ve found that with

    as little a 5 test users we can normally identify about 80% of potential usability issues. These usually revolve around terminology and signposting. • During a test scenario users interact with the product against a set of scenarios/tasks on a range of devices. Various tools can be user to record results, after a discussion these results can be used to refine the product (if required). User testing Gather feedback
  20. Beta Quality assurance (making sure everything’s done correctly) • We

    adhere to a strict set of code standard rules (our own go-live checklist). This ensures all code output from our studio is of the highest standard and fit for purpose. Code standard Integration
  21. Summary Key points moving forward • We analyse your research

    data and draw insights. • We run workshops to define the business and users objectives and how they can be achieved. • We work with you to map and re-engineer the information architecture - prioritising content accordingly. • Sketch and discuss possible solutions on a weekly basis, prototype when and where required. Invite users to test and record feedback. • During the Alpha phase we meet (virtually via Google hangouts or Skype) on a daily basis to share prototypes, development, test with users and make iterations with the feedback we receive to ensure our product is fit for purpose.
 • Assist with the integration phase and ensure the product is deployed smoothly.