Designing Products: From Concept to Prototype (Part 3)

Tom Jepson
Nov 16, 2017 · 7 min read

Note: I have shared lots of process insight in the two articles which precede this one. If you didn’t read parts one and two, don’t worry; you can find them here and here!

In this article — the third and final part in a series where I share the processes my team and I have utilised to develop a new product — I look at how we took our findings from user journey mapping and service blueprinting to drive ideation to find a solution to carry forward into production.

One of the major benefits of working with journey and mapping tools is that we can work on the fundamental concepts of what the user needs to do and why they are doing it, without focussing on any form of ‘how’ (outside of a core touchpoint in the service blueprint). We are able to design the flow of our product without the distraction of UI complexity or aesthetic subjectivity.

So, we’ve got this idea…

The first step to kicking off the UI design for our new product was to digest the findings from the user journey and Service Blueprint sessions that I had hosted for the team. We had — unlike our first pass at the product — a solid plan to follow and some key critical insight (albeit mostly our own learnings) that would carry us forward to make some better, informed decisions.

The sessions plus our combined experiences from recent product design sprints highlighted areas where improvements could be made. We could see clearly areas that were misrepresented the first time round and that we had already started to make improvements where they were needed.

Some critical insights that were drawn from the sessions:

  • There was a need for better signposting and indication of state for the user
  • We needed improved error handling and ‘zero’ states
  • The visual feedback for user interaction needed to be clearer and faster
  • The journey as it stood was complex
  • The volume of content the user was seeing at any one time could have been overwhelming

After picking over the discoveries from the sessions, I updated our journey maps and collected blueprint syntheses to share with the team.

There are many ways to generate ideas for UI concepts; if you’re reading this I can only assume you’re familiar with ideation processes and design thinking methods, so I shan’t delve too deeply. As an example, however, I have in the past worked with the team around the whiteboard using the insight we have to build out a concept together; everyone’s collective knowledge builds to form something greater than a solo effort.

Having designed the first solution with a lot of stakeholder input and steer, I had a preconception that the solution we were looking to design for our second version needed to be simpler and much more focussed on resolving the user’s challenge. The first solution had a high cognitive overhead; it was functional but the investment required from the user to complete the journey was great. There was content to be digested, content that needed to be entered, and more than one ‘happy path’ through the journey.

The risk of low engagement and dropout because of the lack of simplicity was real.

Grid notebooks and markers… The designers’ best friend!

I worked — trusty notebook, pencils, and markers at the ready — to quickly generate ideas to share with the the team; this was to meet a tight, self-imposed deadline and also because I had worked out a number of solutions in my head and believed at least one of them may have been fit for purpose.

It was prudent to quickly process the ideas to reach some early solutions since sharing early and often is one key to success when collaborating.

Note: There are many examples of collaborative practices out there: GV Sprint by Jake Knapp and Lean UX by Jeff Gothelf to name but two. Both of these titles are really worth checking out.

From the whiteboard to paper and back again…

Once I’d reached a couple of ideas I thought were a good fit as a solution, I moved over to the whiteboard and sketched them out in readiness for a conversation (which usually means a lot of head-scratching and redraws with the development team!). We mulled over the sketches and shared ideas, drawing and redrawing, reflowing screens and individual areas of functionality.

You always know when you’ve struck a potentially viable idea because everyone reaches the same conclusions together, quickly, but often from different angles. On this occasion, the solution proved itself to be worth exploration for a number of reasons:

  • It simplified the journey the user needed to take to achieve their core goal
  • The UI supported clearer, immediate feedback to highlight the user’s action
  • The modularity of the solution allowed it to be easily scalable using our new React-based platform; some patterns could be established now for future reuse

Sharing the ideas early and collaborating on the iteration resulted in a coherent screen flow that could — if needed — be implemented in a single sprint (thinking Agile again). We knew we would need to recycle concepts and patterns from other established areas of the design language and build our journey with common, known interactions: at this stage there was no value in reinventing the wheel entirely.

Once the raw screens and core functionality had been ‘signed off’ on the whiteboard — it falls to me to say ‘This is the least worst thing we can do to achieve the goal today; run with it’ — the team split apart to ready themselves for planning. Because we’d been hot on detailing the core functionality of each step in the user’s journey, our front-end developer had established baseline unit tests for each screen before we’d wrapped for that day. Talk about setting yourself up for success!

Collaborative whiteboarding. Always have more than a single-coloured marker…

Planning and delivery.

The next step for the team was to plan the work we needed to undertake to move our concept into development. As an Agile team, user stories were required; this meant breaking the screens down into manageable, deliverable chunks. Given the nature of the design — deliberately modular and driven heavily by simple, single-concept views for the user — breaking the work down was a quick, collaborative process; everyone in the team is given the opportunity to weigh in on the acceptance criteria and estimations for a deliverable story.

During our planning session the team persistently framed the work with ‘What is the MVP?’; given that any sprint could be the last that we have to work on a project we look to ensure that anything we ship could be a viable product. Using this frame, we agreed that one of the ‘core’ functions we had brought in from the original set of requirements was not achievable in the sprint but was also not critical for the user completing their journey; it was sidelined as ‘out of scope’ for our first shippable version.

To aid with the delivery and ensure that our build met expectation, I quickly put together a high fidelity wireframe from our whiteboard sketches using a toolkit I’d created in Sketch. The wireframes acted as single source of truth to ensure consistency in patterns and micro copy when the front-end team picked up the designs.

To share out the hi-fi screens, I put together a clickable prototype using Invision’s Craft Prototype plugin in Sketch; of all the tools I’ve used, Invision feels the most efficient (plus, stakeholders know to look at it to provide feedback).

The integration with Sketch — being able to select elements as hotspots, string them together, and upload directly to Invision — is a huge time saver. Lastly, I printed the default state of each screen wireframe and stuck them to our central whiteboard to maximise the visibility of our impending work; having the printouts often sparks some discussion and lets people comment quickly and easily if you leave some post-its and sharpies lying around!

Prototyping in Craft is quick, easy, and a great way to bring your designs to life.

The Outcome

The final steps in the process were for the newly designed product to move through into visual design and development.

Over the last 12 months, we as a team have cultivated an efficient front-end design process. The wireframes can be rendered into UI from our established visual language without much reinvention or refactoring thanks to a solid library of standard patterns, and the back-of-the-front-end (where the heavy lifting happens… Javascript!) is often structured and considered as React markup is committed. Our style, markup, and framework are entirely decoupled meaning development and release of new features or products can be rapid. This efficiency means we can, generally speaking, ship at the end of each sprint.

All of this ‘process’ sets us up for success.

By sharing ideas at the whiteboard early and often, working through the service blueprints to unpick the granular detail of our previous decisions, and collaborating on our proposed outputs we positioned ourselves to hit the ground running. These sessions gave the team a deep, shared understanding of the product and the goals we needed to achieve.

One key thing for any team is to explore new methods and ways of thinking, piecing them together to maximise efficiency and enjoyment together. Engage with every team member’s strengths and deliver products that are not only fit for purpose but that you’re proud to ship, too.

If you’ve found these articles useful or want to chat about anything I’ve discussed please feel free to hit the comments section. I can always be found on Twitter or in the TechNottingham and UX Notts Slack channels, too!

Thanks to Matt Wheatley for the proof-reading, too; forever making good my output.

Tom Jepson

Written by

Freelance UX designer. Coffee enthusiast. Spare-time musician.

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade