Email iconarrow-down-circleGroup 8Path 3arrow-rightGroup 4Combined Shapearrow-rightGroup 4Combined ShapeUntitled 2Untitled 2Path 3ozFill 166crosscupcake-icondribbble iconGroupPage 1GitHamburgerPage 1Page 1LinkedInOval 1Page 1Email iconphone iconPodcast ctaPodcast ctaPodcastpushpinblog icon copy 2 + Bitmap Copy 2Fill 1medal copy 3Group 7twitter icontwitter iconPage 1


User stories are the bread and butter of an agile workflow and from a development perspective you’ll have no problems finding assurances on their responsibilities and how to go about adopting them into your process.

Over the past 12 months we’ve tried to give some serious thought and application into how we could apply some structure to the way we take a user story into the design process and this post hopes to document our successes and some of the pain points we’re still working through.

The user story

Newly born, a result of consummation between business and analysis during a requirements gathering session, no one knows whether it will make it in the world, whether it has what it needs to survive – a purpose. Like the mother of a newly born bird, it falls to the designer to kick it over the cliff edge to see whether it will fall or fly.

Returning from the land of colourful metaphor (although I may return), whether that user story succeeds or fails is potentially quite an expensive discovery. Our aim recently has been to detail a process whereby we can ensure we know, as quickly as possible, if we are working towards a valuable design solution.

Hatching the egg

At some point in the fulfilment of a feature, nearly every member of the team will be significantly involved applying their specific skill. For this very reason we aim to front-load the ideas and skills these people will bring into the concept generation.

We do this by the design team spending a short period of time drafting some design solutions in a very low fidelity format which forms an invitation for discussion with other team members. The team will be briefed on the user story and presented with some very rough concepts to help shape their initial understanding. At this point, anyone in the team can validate the design direction or offer alternative approaches. It’s the designer’s responsibility to make sure any conversation is framed in the context of the end user.

Initial sketches are used to communicate ideas within the team

We also draw on any precedent we have in the application at this stage, referring to our project pattern library to see where we may have tackled this problem or concept before.

Example of a project pattern library

By collaborating so early in the process, we can quickly remove any unfeasible ideas and focus on ones that have the full experience of our entire team behind them. The key here is to keep these sessions short. Naturally it will depend on the complexity of the user story, but the idea is to iterate, even at this stage.

Walking to the cliff edge

We’ll now work our best ideas up to present to the client. Its important to remind yourselves here that you’re trying to do the least amount of work in order to validate a direction, or learn enough about the design in order to proceed or pivot. With that in mind our presentations to a client start very early on and will generally involve a sketch (on paper or on a whiteboard), or a low fidelity wireframe. Generally we’ve found wireframes work better when there’s quite a lot of UI or information required in the design, since they tend to be cleaner and easier to follow, although that entirely depends on your drawing skills.

Taking the design, to the client we’ve found its much more beneficial to work face to face, but we’ve also had reasonable success over the telephone, emailing over the concept after we’ve spoken briefly about it. However you present the design, communication is paramount here in setting expectations.

A low fidelity prototype to talk through with client

After the session we can incorporate any feedback into another quick concept and repeat the process above, keeping the feedback loop as tight and frequent as possible.

The benefit of this part of the process is that it eliminates any obvious business challenges the design choices may present. User testing can be expensive, but by getting our designs before a stakeholder as quickly as possible, we can make the user testing step much more effective.

Naturally the success of this step depends on the client, but briefing a client of the purpose of this stage will hopefully shape their perspective positively and the tone of the conversation will be focussed on ideas rather than critiques.

Looking over the edge

In some cases our concepts can be validated by sketches and wireframes; we can present these in a user testing session and move on. However, most design solutions will involve some level of user interaction and understanding whether the behaviour we enable is optimal to the users’ workflow is something we really need to validate early. This is where communicating behaviour in wireframes and sketches can become quite frustrating; we’ve all seen the design documents that try to communicate every single stage in a process or the outcome of different interactions – it’s inefficient and ineffective.

In these situations the wireframes previously shown to a client become the reference for a discussion about what behaviour we could include in the design. Once we’ve done some sense checking with the client, we want to get a prototype in front of the end users as quickly as possible. There are a lot of options for building UI prototypes out there, and there’s plenty of other blog posts that discuss the merits of each, but at UVD we’ve been embracing AngularJS for a lot of client work lately and it’s equally fantastic for creating rough functional UI quickly. We’re building a workflow for creating prototypes using AngularJS that will hopefully form another blog post.

Interactive prototype

The push

At this point we have an interactive prototype that we hope will fulfil the requirements for the user story, our entire team has had some level of input and the client has bought into the concept. Whilst the process may seem a bit long winded, in practice it can actually be quite quick and every effort should be made to make it so since the most important people haven’t been exposed to it yet: the end users.

Running usability testing sessions can be scary; assumptions can be squashed and ideas nullified. Ultimately though they are your best option for validing that the design solution will work. We recently ran a few workshops for Thomson Local to redevelop an existing sales booking platform, using the structure we learned at Evgenia Grinblo’s excellent usability workshop. The sessions are run against the test scenarios we create: essentially a narrative that instructs the user to carry out the activities we want to test, but also priming those activities with information or background relevant for the task under test. For our reference, we also outline the expected success path to validate that our design works. If they successfully complete the task with little to no resistance, based on our success path, then we know we’re heading in the right direction. You can see an example of one of the test sessions we ran here.

During the session we take notes whilst observing the person testing the design. Some of the key information we need to gather here include:

  • Whether the user can achieve the desirable outcome at all.
  • Whether there are any behaviours the user is used to, that we aren’t taking advantage of.
  • Whether the design meets some of the mandates (goals and aspirations for the project) we defined in user research, during requirements gathering.

Flying is just falling with style

What you learn from the usability session can be rather unpredictable, but it’s important to remember that this is your opportunity to learn from the very people that you want to use your design so come prepared to find issues and embrace them when they occur (there’s no room for your ego).

We’re trying to assess a couple of key points in the testing, the first being the general acceptance and enthusiasm for the feature the design enables, and the effectiveness of the design in delivering that feature.

The validity of the feature, or the enthusiasm for it, is primarily the concern of the business case and something I won’t concern myself too much with here. It’s important to gauge whether the functionality is communicated sufficiently in the design and inquire that the user fully understands what’s being presented to them.

Observations that need to be captured from a design perspective are:

  • Patterns of hesitations or frustrations in interacting with the design, despite being able to complete the task.
  • Opportunities where supplementary functionality would significantly expedite the ability to complete the task.
  • Functionality that’s not been considered, is missing from the design, is necessary to complete or would supersede the functionality provided by this design.

After the session it is up to you and the client to assess and prioritise which parts of the feedback are worth acting on immediately or in the near future. From this point we take whatever feedback that’s been deemed actionable and work back through our process again with more information than we had previously.

The final UI re-worked after feedback

Hopefully this post has given you some insight into some of our learnings and how we’re trying to develop an efficient and effective design process into our workflow. We’ve certainly encountered, and are still working through some challenges. Namely the availability of users to test against and the cost in time and organisation to arrange the sessions means we rely a little more than we’d like on client feedback rather than that of the end user.

We’d be very interested in other peoples’ experience of integrating design and user experience into a lean workflow, so as always feel free to leave a comment below!