Category Archives: Agile

The Design Trifecta

Recent research from the Design Council and other sources indicat that 51% of service design projects do not get implemented.

Design groups can fall into the trap of telling business  high level strategic stories using overly complex assets that present a nirvana.

They do not get implemented because they lack testing with users, fail to add value to the business and are not implementable.

In terms of innovation, teams need to understand if they defending, differentiating or disrupting and set strategy accordingly.  By combining service design thinking and business science in a participatory design process projects stand a better chance of success.

Clients do not need high level, ethereal and glossy design concepts. They need a trifecta of creative know-how, business acumen and implementation. In design thinking  this is the minimal viable product desirable, viable,  feasible and usable!

Waterfall, Agile and Wagile

In the past two years here at Factotum we have started to use a leaner design and implementation process as part of an integrated strategic design and innovation methodology that is referred to as WAgile.

In the past there was a focus on phased approaches to design and implementation called Waterfall, where the phases of research, framing, insights, design and implementation were completed in sequence – this was typified in engineering, product design and software development.

Then Agile came along and the emphasis shifted to implementation through sprints and a series of ‘drops’ as the software or app  scaled from a minimal viable product (MVP). This works well for software products or new app development but it sometimes fails to include a research and insights process that identifies and engages with target users to understand core needs and how the app is a touchpoint in a larger and distributed service ecology.

Both Waterfall and Agile have strengths, weaknesses and their own merits, but used separately they are limited and flawed.

Wagile

HCD & Contextual Research

Understanding users needs and importantly their desires is key.  Increasingly  ‘wants’ rather than ‘needs’ motivate customers.  For example, customers ‘need’ to text messages but they ‘want’ an iPhone. Customers want a great experience and the social cache of owning a premium brand and awesome products. In short cusotmers are seeking self-actualisation and they are willing pay a premium for it.

To understand ‘wants’ and ‘desires’ we need to intimately know and understand our customers; their attitudes and values. To do this we need to undertake sustained research at the beginning and throughout the early phases of a project through ‘conversations’. However, we need to work quickly and with agility, without over committing resource to design directions that might fail in the market place. 

This is where WAgile becomes attractive.  It takes the best features and benefits of Waterfall and Agile to combine them with HCD and Design Thinking. WAgile is an iterative design and innovation model that employs contextual research driven insights, design thinking, business science and uses sprints to work with agility in cross-functional teams to implement quickly.

At the beginning of the WAgile process I use both contextual inquiry techniques and data analytics to discover who is the ‘customer’ and what are their desires, needs and goals. I balance this with the business needs as we seek new opportunities to disrupt.

This means working closely and dialoging continually with current and potential customers. The process starts with Contextual Inquiry (CI) using ethnographic research augmented with data driven strategies where we use data garnered from customer interactions through owned, paid and social media. Each point of contact with the customer is an opportunity to harvest information and data to gain insights.

User Stories – a common currency

An important tool in the WAgile process are User Stories; the common currency of design. We describe customers tasks and goals through user stories that in turn become features and functions to design and build.

Framing the problem, defining the opportunity areas and designing solutions are based on User Stories. Then workstreams and sprints are forumlated based on MoSCoW principles working with users and the core team. This is part of the continual dialogue and conversation model with customers.

Working sometimes only a day or two ahead of the software developers, the designers use ‘Evidencing’ to bring concepts to life. Evidencing involves creating objects or ‘props’ to act out scenarios and create Rapid Experience Prototypes.  The prototypes explore the way a proposed MVP and design concept will feel and perform. 

By ‘Evidencing’ concepts we can animate and interact with concepts to assess their usefulness in an iterative process with users. This results in tangible evidence (as wells as stills and videos) that enables the core team make early informed judgments about the implications of the design concept.

Based on the outcomes and insights of Evidencing, the user stories are refined and translated into detailed features and specs. The information architectures are refined, wireframes are created, GUI assets are created and coding begins.

WAgile is fast, efficient and enables the user to be involved while the team implements what the user wants.