University College London

Information Security Group

What can others learn from how your team is organized and how it works?: 

Guiding principle: Sentire was conceived to streamline and integrate the disciplines of engineering and design into one mono-lingual and systematic process where requirements and UX are intertwined into a single workflow. Mono-linguality is based on measurable goal setting and monitoring whereby all stakeholders within the multi-disciplinary team would work towards achieving pre-agreed goals (e.g. at least 75% would be willing to complete the task at hand while reducing perceived workload to less than 30%).

We provide a framework, based on the Volere requirements process and extending traditional user-centered design techniques (personas), to inform the team’s decision making process. Traditionally requirements engineering processes focus on technical solutions where "non-functional requirements" is a catch-all category that also includes usability. UX requirements are very difficult to specify in a measurable way, and so these are the first aspects that suffer especially in a competitive tendering process.

Designing with the user in mind is a philosophy that stems from the usability and interaction design fields, but less from the more traditionalist and formal requirements camp. Many requirements frameworks, processes and techniques exist, some of which are formal while others are less so. We feel that there is a need to merge UX disciplines and requirements techniques in one rigorous and agile requirements framework. This needs to be user-centric by definition and from inception. Our technique (Sentire) merges a requirements elaboration and specification discipline with user centered techniques – as part of the process, rather than as an afterthought. This places the user at the center and thus making the role of the UX specialist (in person or computationally) central to the whole process.

Through our experiences with e-government service design/development teams we have always seen:

a) A high dependence on contractors’ experience

b) A lack of UX expertise in the design team (unless a third party is assigned the task to fix issues post-launch)

c) Lack of knowledge accumulation and re-use

d) In a competitive bidding process contractors are virtually compelled to drop UX considerations in order to submit the lowest bid, and this is also because there are no concrete and **measurable** ways to define UX requirements at the earliest stages.

e) Contractors are generally interested in delivering products on time to avoid over-runs, and again, due to the lack of measurable requirements, UX suffers.

Is there a way to merge UX disciplines within the more traditional engineering disciplines? Can we ensure UX-centric requirements engineering processes? Can systems engineers and UX specialists speak the same language? How can goals be specified in a measurable and thus agreeable and comparable manner? By devising a unified process and associated CASE tools we present a way by which design and engineering teams, as well as policy makers, can speak the same language and follow a common requirements and design process while being guided by measurable goals. UX should not be a minor consideration in the requirements process (i.e. a couple of requirements pointing towards a usable system) but as part of the overall workflow. Especially because UX specialists are not always involved within smaller (but also larger) e-government projects we introduce the idea of UX-analytics through which UX feedback is simulated at design time during use-case specification and for each specific user group involved.

Calibrated Personas are at the core of this process, representing user behavior through quantitative models. Persona calibration could be outsourced to research institutes or design specialists interested in building and maintaining such models. This enables the team to follow an iterative design process based on commonly agreed and measurable goals. These user models are stored in a persona library, and are re-used across government projects.

What is the composition of your team, and how was that composition determined?: 

For the smaller, but more regular e-government projects, teams are generally composed of a project champion (policy side), an IT person (generally the systems engineer or IT manager within the entity) and a business analyst (contractor). This should be complemented with a Sentire facilitator who would be knowledgeable on both the requirements engineering processes as well as UX and user centered design techniques.

This is an important role which needs to understand the requirements, the technical limitations or opportunities while keeping the users’ experience in check. Sentire offers the process and tools to manage all of this in a collaborative environment. Users are generally not involved in the earlier stages of the process unless UX specialists are hired, which again is a rare occurrence especially in low-budget projects. Such projects would nonetheless impact thousands of users who have no alternative service providers to choose from. Sentire aims at getting UX-specific knowledge and decision making as part of a unified requirements and design process, moving away from the idea that UX is an additional non-functional requirement.

It builds upon a common language and reporting facilities that facilitate decision making based around simulated user feedback. This ensures a UX-oriented workflow which guides design decisions based on the user’s behavioral patterns. It stems from an understanding that UX is crucial at the earliest stages of a systems’ life cycle during which users must have a voice.

Please describe the manner and process by which your team collaborates over a typical iteration, feature, sprint, or any other unit of work.: 

We are currently focusing on the enrolment process as a critical success factor in e-government services. The current user modelling technique (persona calibration) is used to build behavioral models that provide us with insights on the levels of:

a) perceived workload and

b) willingness to complete the task at hand (i.e. sign-up versus give-up).

Before working on a specific use case, the facilitator guides the team to decide on measurable goals. For instance, the project champion would be happy if 60% of the target population adopts the e-service. Following the Volere requirements process a set of scenarios are specified for which product use cases are designed.

Example: designing the enrolment process for a consumer advice portal

Policy stakeholders: Emphasize the importance of identity assurance given the service’s sensitivity (e.g. require users to visit a registration authority to complete enrolment)

Engineering stakeholders: Comply with requests by providing technological solutions.

UX stakeholders: Emphasize the fact that users operate on a continuous cost-benefit assessment and this decision might result in non-adoption for specific groups of people (based on heuristics).

Given that the group agreed on a specific and measurable goal, the facilitator can move on to generate UX feedback based on the pre-generated behavioral models. This can be carried out immediately following each and every design decision, each time providing a quantitative result that is actionable and easy to understand for all the stakeholders involved. The facilitator would guide the process using the following equipment:

1) A device with internet access (e.g. laptop)

2) Access to the Sentire's CASE tool

3) Projector (we found that this improves participatory design)

Although our focus is on e-service enrolment we believe that this technique can be used as a design pattern for other critical design factors, such as checkout processes, security processes and so forth.

How has the fusion of design and engineering benefited your projects, products, services, and the company generally?: 

In principle quantifying UX goals makes it simpler for team-members to agree on sub-optimal designs. On the other hand visualizing impact in a quantitative manner helps engineers understand the designers’ argumentation.

We find that providing measurable and actionable feedback, rather than subjective argumentation, both policy makers and engineering stakeholders can:

1) visualize the impact of their design decisions and in doing so

2) making it easier to find a balance between user-goals and business-goals through an iterative process facilitated by Sentire’s Volere-inspired process and associated tools.

Currently we’re working on a consumer advice e-service for a consumer affairs authority which will be used by several user groups represented by a number of personas. Sentire allows us to determine which design alternatives might perform better in terms of perceived workload and service adoption rates based on comparable feedback (rather than basing our decisions solely on heuristics and extensive (and expensive) iterative user testing using high-fidelity prototypes).