When your job is designing digital services and products – apps, websites, enterprise software etc – there’s a tendency for people to be most excited when you start producing those first drawings. Call them what you like – wireframes, scamps, mockups – the jargon varies from company to company, but as the first visual expression of the result you and the team are heading towards, it’s easy to understand why people are so interested. These drawings are the point when what you’ve all been talking about suddenly comes to life, and can be easily understood by everyone involved.
Establish a solid foundation
Part of the magic of working in design is helping people to make their ideas real, and yet however rewarding it may be to bring them to life, a great visual can be misleading unless it’s preceded by credible user research and groundwork. A good designer can create a beautiful and engaging mockup from scant details, so it’s possible to have convincing concept drawings from the get-go, but truth is despite the best intentions, they’ll be wildly inaccurate. Sometimes a great concept drawing is what you need to get buy-in to your project, but as software developers we know from experience that every design, particularly something new, will inevitably need to change. When the team first spend time building up a solid understanding of customers, and conceptualise how the product will work to answer their needs, then we can put pen to paper with more confidence because we better understand where we’re headed.
For this reason, it rarely makes sense to start the design process until we have first achieved a solid ‘foundation’ of understanding of the problem to be solved. This may mean a stakeholder workshop to clarify what the business hopes to get out of the project. It will definitely mean identifying the users of the new service – both consumers and those working behind the scenes to deliver the service. It will likely mean spending time with these people directly to clarify their frustrations, ideas and assess what value our new service will deliver. This face-to-face contact is incredibly valuable time for designers, because this is where we build empathy with our users as real people, and will notice a myriad of tiny details about their situation that we’ll use in a later stage to fuel a rich and well-informed design. This is the stuff you never get from site analytics or customer surveys. That data is helpful of course, but to understand ‘why’ your customers do what they do and how you can help them, you will always need rich, investigative conversation between people.
Run a Design Sprint before you do much else
Typically we establish our foundation in what we call a ‘Discovery’ phase, or a Design Sprint. How long this takes depends on how much we already know, but can be anywhere from a week – as used in Google Design Sprints – to a couple of months for clients who might not have so much direct contact with customers and hence have more to learn. Designers conduct research to establish our foundation, sketch some well-informed concepts and take them back to users for assessment. In this way we can dramatically lower project risk by quickly delivering an outline design that’s already been tested and proven to be worth pursuing – it’s feasible to build, it’s viable as a business proposition, and it’s desirable to customers, and this can be done in just a few days. During these early stages, change is cheap and so we can afford to try out multiple ideas and explore innovative new services as all it costs is a few hours to sketch or prototype. Once development has begun, changes will become much more expensive and so it makes sense to explore early, and ensure we’re on the right path before we start coding.
We also recognise that innovation means we are designing something new – quite likely, we have little idea what that is at the start and our idea will evolve over the course of the project. One of the principles of the Agile development manifesto is to “welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.” This is particularly relevant when creating new things, as it is useless to lock down the specification of a design before we truly understand the problem to be solved. More than that, it’s useless to lock down the specification at any time. Being able to shift course without red tape when we learn something new is critical to improve chances of success.. This is why we provide estimates and ranges for work to be done at project start, and update these estimates as the real work reveals itself and the project progresses. It’s simply a more realistic view of software development. If we followed a specification written without the benefit of a design sprint, it is highly likely we would hit a problem further down the road that would require starting some or all of our work again, causing unnecessary cost and delay.
A natural fit for Agile development; Lean Design involves regular and close collaboration between designers, developers, users and client stakeholders – for example those in a product owner role. The designer often becomes the voice of the customer, helping everyone share that understanding and nudging the team towards a people-centric solution. The designer drives the design vision forward by liaising with everyone, translating their input into requirements and visualising what that means for the end product or service. As development sprints begin, the designer gradually transfers responsibility to the development team but stays involved, able to be called upon as needed to resolve issues or offer advice on usability etc.
We can expect to return to our users several times over the course of development to conduct usability testing or similar, and this will mean changes. I have never seen a testing session like this that was not hugely informative – in terms of teasing out usability issues the team never thought of, designing for edge cases of user behaviour, and building confidence we’re on the right track. Every time we test, we learn and iterate our design to improve, and so the idea of stage-gated process or formal ‘sign-off’ of designs is just shooting ourselves in the foot as it leaves us unable to use what we’ve learned. Expectations like this can become a hindrance that serves only to slow progress and cost our clients more. Instead, it is far more cost effective for our clients to become part-time extensions of the design team, with daily, informal communication and planned testing enabling us learn, iterate and adapt quickly.
Build prototypes and user story maps
All this collaboration is much easier when designers and developers use the same language and refer to the same materials. In my experience, these are typically a user story map and /or service blueprint, and an interactive prototype. The maps describe not software features but stages of the digital experience from a customer’s’ perspective. There are many variations of these maps available, but all that matters is we use one that enables us to prioritise work on elements that deliver most value to customers. A user story map can be created as a direct output of research during the Discovery phase, and serves as an ideal format to work from as it makes sense to both designers and developers.
When the designers are crafting a UI, we start with simple sketches during our design sprint. Lean Design work quickly moves on to interactive, responsive prototypes that give the entire team the clearest possible understanding of design intent – after all, they can now use it themselves on their phone or screen. There’s no need to add detailed annotations to prototypes when the development team are being kept informed through daily stand-ups and close collaboration. On projects where the dev team is outsourced and not involved in discovery, clients should plan for slower speed, lower quality and the likelihood of extra cost as communication becomes more laboured. Wherever possible, get your whole team sat together for better results.
Interactive prototypes suggest to developers how we might implement a feature, whilst the story map tells them why we’re building it in the first place. Prototypes have the added benefit of being ideal for user testing – bringing our design to life in a way that elicits far more detailed user feedback than we can get from static sketches and mockups.
Once we’re confident our design is taking shape, we can begin development, and the most cost-effective way to do this is with Agile methods. Agile development means that we – both developers and designers – work in 2 or 3 week cycles or ‘sprints,’ each a focused phase of work where we design and build specific parts of our software. Agile principles state that “Working software is the primary measure of progress” and so at the end of each sprint we aim to deliver complete, working features and components, not leave anything half done.
Use Dual Track development to get more out of design
Sprints continue until we’ve built the ‘Minimum Viable Product (MVP.’) This is the soonest point at which we could launch that would still enable our customers to do what they need and bring the business a return. Sprints beyond that further improve quality and add value, refining our offering with every 2-3 week period. Of course, we’ll almost always go beyond MVP to make something that really surprises and delights your customers, but MVP is a key milestone as we can start using it for things. Once we have a working software experience, we can return to customers and begin testing the product in earnest – reducing risk, improving chances of adoption and maximising the value our clients get at launch. Typically, MVP will allow users to do everything they need to, but will be missing less critical features and will lack the refined UI and great visual design we’d get to by launch. These will come in due course.
As MVP is such a significant point in development, it is especially important that we’ve carried our a Discovery phase to properly define what users need and value from this product. If we missed anything, our testing will make this apparent, but as mentioned before, changes are cheaper the earlier they’re done as less is committed to code.
Lean Design works in parallel with Agile development to maintain our ability to respond to new information and change. This is a particular kind of Agile method called ‘Dual Track.’ Whilst the development team are working on their first sprint, the design team are conducting a deep dive into the area needed for the second or third sprint together with customers and stakeholders. The design team can support and continue to refine aspects such as UI and visual design in parallel, and support developers with questions and UX advice.
Another Agile principle I find particularly apt is “The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.” I’ve seen personally how detailed design specifications can waste time and foster misunderstandings between designers and developers. For that reason, Pancentric favours minimal documentation where possible, and instead has designers and developers sitting and working together, encouraging face-to-face discussion and informal problem solving. Daily ‘stand up’ meetings keep everyone in touch and can include client stakeholders too and work using the same set of deliverables. The user story map and prototype are central references for all, but act to aid collaboration, rather than specify every detail.
With a thorough Discovery phase, it’s possible to establish KPIs for our creation and measure performance by how well it meet the goals of our customers and client’s business. When we test prototypes of our product or service, we’re often able to quantify the quality of the experience and apply some approximate metrics that let the whole development team know how we’re performing. There are several different methods, but the SUS scale is widely recognised as a way of quantifying subjective qualities such as ‘usability.’ Many development teams struggle to know when quality is good enough to be ‘done,’ and this kind of assessment helps answer such questions.
In this way we’re able to track the quality of our design and help stakeholders plan when to release, and when to spend sprints building new features or refining existing ones.
At Pancentric we know no two clients are the same, and so we adapt our working process from a flexible toolbox of design and development activities that we can combine in different ways. Lean Design allows us to make the most of our time and follow an evidence-led process, tying everything we do back to an understanding of customers and the value we deliver to them. Dual Track development allows designers and developers to work efficiently in parallel, and we believe that means with us you’re always working in the most customer-focused manner possible, from the first workshop to the day your new service becomes a reality.