Designing at speed

Ed Everett

4 minute read

Earlier in the year we were asked to work with a large environmental consultancy to improve, and digitise, their business processes. The goal was to make them more efficient and productive, but also to find new sources of value by connecting the newly digitised data.

The client wanted to build things fast and lean on an ambitious schedule. This article is a look at the processes we followed to design, prototype and build their new services as quickly as we could, taking advantage of new tools and tailoring our processes to their organisation.

Low code development and building at speed

The client had selected Mendix—a low code development environment—as their tool of choice.

The promise of Mendix, and low code environments generally, is to shorten the distance between an idea, a design and production. In theory a single designer (or anyone really) could have an idea in a workshop, log into Mendix, arrange the interface, connect the data sources and press ‘publish’ then put the changes live. This is excitingly fast but also terrifying. Our practices and toolkits have evolved with checks and balances to ensure consistent delivery of high-quality products. The challenge in this project was to take advantage of the best bits of creating with low-code tools but keep the rigour and quality of our thinking and output.

This is a hard balance to get right, and the approach for this project might not be right for most.

Generating ideas at speed

We had previously created a Target Customer Experience map that described a vision of the future for our client. It described a story for how one of our client’s consultants would manage a project from beginning to end. And we’d prioritised the main functions from that map. The next step was to unpack the selected functions, understand the business processes in much more detail and turn them into some kind of design.

Every Thursday afternoon, with our four key stakeholders, we had a half-day workshop to unpack the prioritised features of the Target Customer Experience. The workshops followed a set structure:

  1. Map the pains in the current process
  2. Sketch or prototype a new, and better, process enabled by good digital services
  3. Use the pains mapped in Step 1 to illustrate the value to the business of the new designs

With our client project team divided between New York and London the workshops were done with conference calls and screen-share.

The pain mapping consisted of walking through the process and discussing the parts that were good or bad. We used either “virtual post-its” in Realtime Board or the workflow tool in Axure if we needed to record more details about a process. Both tools allowed us to work fast and loose and visually, and then quickly group the pains.

For sketching and prototyping we usually used Axure. Axure allowed us to work extremely quickly, digitally sketching interface details at the speed of the conversation. The fidelity was of course very low, it was messy, the digital equivalent of drawing on a whiteboard. But we could add simple interactions and links between pages so we could walk through the new journey in the meeting, making sure it made sense and getting our first bit of feedback from its eventual users.

We then started to put rough business metrics against our new design. This is normally things like an estimate of time saved, ways it would increase client satisfaction or improve the quality of the output. From the start our designs were wrapped in business rationale agreed with the client and importantly using their own language.

With just 3-4 hours of our client's time we generated a huge amount of ideas and gained a deep understanding of that part of their business.

An example of workshop sketch created with Axure on a conference call.

Shortening the distance between design and development

With a pre-prepared component library in Mendix and a drag-and-drop development tool, we could build the interface directly from our workshop sketches with no further design. This is the leanest process I’ve ever seen. We could come out of a workshop with an idea, sit down at our desks, build it, hook it up to the data and have put it in front of users later that day. It allowed us to very rapidly get feedback and iterate; the agile dream.

But a process this lean skipped huge chunks of our normal design process. And our development process. And QA process.

What are we missing out on?

Workshop sketches suggest a direction, but they haven’t been fully thought through. Developing a sketch into a full design is thinking it through. If we jump from sketches to built product we are taking a risk that the idea is immature. We might be missing a better solution, or we might not have understood how it will affect the rest of the system.

Our normal design process is deliberately collaborative, intended to make sure that the designs are the best solutions by the time they are built. We share our work with other designers across projects and we work with developers to refine the designs further, bringing in their technical expertise. We then go through a process of specifying the features and sizing the effort; a QA-led systematic break down and analysis of the how the feature will work. There is always something we’ve missed, and improvements to be made.

It’s only then that we have a mature design and the understanding of how it’ll work and effort to build it.

Working fast with Mendix meant missing out on all of this; we traded increased risk for speed. We were flying by the seat of our pants.

Designing fast and slow

As we got used to working with Mendix we started to better understand its place in our processes. After a couple of sprints we began to have a mature API and interface design system.

We started to find the agility that Mendix gave us to iterate the product that was most effective when constrained by a stable API and interface design system. A tactical layer supported by two strategic layers. We could move slower with the API and design system where the requirements were more predictable and move faster (but not break things) with the product itself.

Results

The (condensed) result is that we delivered a user-centred, tested product that solved real business problems in a short time period.

It was slightly rough round the edges but we delivered the first product after about 3 months. It is a system for automatically generating project proposals. This is a fast paced, arduous and often thankless task that puts the consultants under a lot of pressure. We dramatically sped up the process and reduced business risk by eliminating manual copy-paste errors; the savings were estimated at £1,000 per proposal (about £3 million per year). As importantly, we managed to reduce consultant stress, giving them a better work life and in the long term, reducing staff turnover.

Ed Everett

Senior UX Designer
View all thinking