Add Your Heading Text Here
A scenario based approach to design
Design - it isn't just visual
It’s a common mistake even among experienced designers to confuse usability with User Experience (UX) or User Interface (UI) design. Every application that’s been built has one thing in common – a purpose. It’s usability is gauged by both how well it is built to serve that purpose and how well it enables its use towards that purpose.
Any approach to design, and we know there are many, many of them, start with seeking to identify both the purpose of what’s being built as well as who would use it or have any stake in it i.e. the stakeholders.
At DC, we often follow a scenario based approach to designing and building applications or websites.
Scenario Based Design
Made popular by John M. Carrol and Mary Beth Rosson, Scenario Based Design (SBD) has been around for some time, although not widely adopted outside academic circles. In the real world, it’s a design approach that requires a lot of imagination, but more importantly is time consuming and hence expensive. We therefore use a slightly modified approach to traditional SBD that still stays true to the idea and suits our line of work, enabling us to reap its benefits without significantly increasing cost.
Fall in love with the problem
Our approach starts with a thorough identification of the users of the system and the broader stakeholders. Often, any application we’re building is looking to overcome a problem with the current practice. A deep understanding of the problem is pivotal to building an application that solves it.
Problem Scenario
Personas - what are they?
UX designers are well aware of creating detailed descriptions of fictional characters from who’s perspective they come up with design cues and more detailed solutions. These characters are often called personas.
Our approach uses personas extensively, always building them from our understanding of the stakeholders. We typically create multiple personas to cover every background or every stakeholder type we think is likely to influence the solution.
Example personas:
James is a delivery driver working across the Scottish central belt. An experienced driver, he drives a van which he uses for his deliveries. James is 45 years old and fairly comfortable with technology, using gadgets such as GPS devices, smartphone and a bluetooth device for work.
David runs a vehicle bodyshop in central Scotland. Having worked in the vehicle repair industry for over 30 years, he is a vastly experienced tradesman having worked on and being knowledgeable in all aspects of body repair and restroration. He is able to quickly assess any damage visually and work out exactly what needs to be done.
With our personas, we create our first scenario – a description of a problem with the current practice involving one or more of our personas – a problem scenario. A common mistake that’s easy to make here is that persona development can shift the focus on personas themselves. It is important that we dont. The focus always remains on the problem and personas are just a means to finding a solution.
Problem scenario:
During a delivery run, James is involved in a road accident. Another vehicle had crashed into his van on the side creating a large dent on the bodywork and his paintwork is also damaged. James looks up local vehicle bodyshops on his smartphone and finds David’s shop under a directory listing. He calls David on the phone, books an appointment the following day when he arranges for his van to be recovered and taken to David’s shop by a recovery vehicle. David then inspects the van, assesses the damage, dicusses the repair process with James and provides him with a quote. He then provides James with a courtesy car for use while his vehicle is being worked on.
The scenario above would describe the current practice. David has his business listed on the local directories which enables a customer to find him but he is unable to assess the damage easily. James has to arrange an appointment and arrange for vehicle recovery so that David can assess the damage.
Arriving at possible solutions
We use problem scenarios as a base on which to gather ideas for possible solutions. It helps provide a solution with a context and point of view. In traditional Scenario Based Design, problem scenarios are built upon gradually to create activity scenarios, information scenarios and interaction scenarios. We however, seek to combine these into one step, creating a “solution” scenario. We build upon the problem scenario, often creating multiple solution scenarios.
Solution scenario 1:
During a delivery run, James is involved in a road accident. Another vehicle had crashed into his van on the side creating a large dent on the bodywork and his paintwork is also damaged. James looks up local vehicle bodyshops on his smartphone and finds David’s website. The website has a handy feature where he able to provide his details, describe the damage as well as upload images of his vehicle for David to assess. David then uses the pictures to provide him with a quote which James accepts. He brings James a courtesy car the next day, recovers the van and has it transported to his workshop for repairs.
Solution scenario 2:
During a delivery run, James is involved in a road accident. Another vehicle had crashed into his van on the side creating a large dent on the bodywork and his paintwork is also damaged. James looks up local vehicle bodyshops on his smartphone and finds David’s website. The website has a handy feature where James is able to start a Whatsapp conversation with David at the click of an icon. David starts a video conference where James is able to show him the damage to his van. David assesses the damage, discusses the repair process with James and provides him with a quote which James accepts. David brings James a courtesy car the next day, recovers the van and has it transported to his workshop for repairs.
Both these scenarios provide insights into improving the usability of David’s website enabling him to provide a better service as well as making the experience less stressful for James.
Choosing a solution
In an ideal world free of time and cost constaints, both solutions would be evaluated for usability with proper user testing before a particular solution is chosen based on the analysis.
The example given in this blog is the short form of something we worked on recently for a client. We chose solution scenario 1 as it allows more convenience to David in that he does not have to be available immediately for a video conference. He, or one of his employees can provide the quote by assessing the images without having to sidetrack from the work they need to carry out for other customers.