How I work

The way I’ve been working in the last years basically bridges Product Management and Development. I’ve worked in Waterfall process in the past and moved to Scrum in 2011, but part of the process is still done in Waterfall: the Research and the Definition phase. Concept phase is done in Scrum process, together with developers, QA, architects and product owners. I’ve been working in scrum teams with up to ten people, depending on the project complexity.

UX and UI Concept creation in Agile context (click on the picture to enlarge)

Research

Research is about gathering relevant background information that support decisions about what is to be developed and how. I’ve been working using different methods, as described below.

User research

It is important early in the process to understand as much as possible about the target users of the project or product to be developed. What are their expectations? How do they currently work? What solutions from their problem space they currently have in use?

I gathered experience creating Personas to deliver precious information about the users we wanted to approach. The data for the Personas came from qualitative interviews and user-context analysis, both providing conscious and unconscious insights about user behavior. Information gathered from user-context analysis also provided a great overview about how these users were coming up with solutions for their work routines, which enriched our understanding about their mindsets and the problems they were facing with the tools they were using.

Personas:

 
 User-context analysis: task overview

 

 

 


 

 

 

 

Competitors analysis

During the user research, especially during interviews, I have the chance to learn and observe which competitors’ products are in use and why. Where are the disadvantages? Which workflows are properly covered with such products? Which are not? I use this information as starting point for investigating more about those products and other similar ones, checking for consistency within the interfaces and with common patterns, as well as how ease of learn and ease of use is covered.

Support on product requirements

I support product managers and product owners during this phase in the definition of requirements, based on user research results, competitors analysis and, eventually, usability tests results from previous projects, when available. The deliverable of this phase is a definition of “what” is to be done, not necessarily providing concept ideas, unless they are relevant for technical feasibility check.

It usually overlaps on the second part with the Rough Concept phase, smoothly transitioning to Concept work.

Brainstorming workshops

Brainstorming techniques are very common during concept creation, but it is also a strong method to support gathering, prioritizing and organizing requirements. In brainstorming workshops, I had the chance to bring users, developers and product managers together to collect and prioritize such requirements, which helps product definition and planning.

Workflows and use cases

High-level workflows and use cases diagrams are deliverables used to provide an overview about how users are currently working. I’ve been also creating them to support requirements phase of projects with high complexity, providing also some possible answers on “how” these workflows should be covered and enabling discussions about technical feasibility and planning.

Rough concept ideas

Eventually I also sketch some ideas during the definition phase to enable the discussions about technical feasibility and needed implementation efforts of different possible solutions. Once these discussions sometimes need to start before the concept phase in order to consider possible investment constraints, these sketches provide an overview of possible directions and the chance to identify risks from the technical point of view.

 

Concept

Rough concept

The idea behind the rough concept is to create quick low-fi prototypes than can be used for easy usability testing. I usually use Balsamiq Mock-ups for such prototypes, it is quick to make and react to tests results. It has limitations on the interactions possibilities, but it is highly helpful to identify usability problems on the basic proposed workflow, explore several options, evaluate the position of UI elements and eventually also icon ideas, allowing quick and easy reaction to those problems early in the process. After some iterations, the same prototypes evolve to wireframes, to be used for the following step: the fine concept.

Rough concept prototype:

 

Fine concept

The iterations in this phase are now done with high-fi prototypes, where more detailed visuals and rich interactions can be tested. I’ve been using JustinMind Prototyper to generate html prototypes during this phase, combined with graphics done in Adobe Illustrator and Photoshop. For each iteration, the prototype is tested with users and refined after results. Fine concepts are done in Agile process, providing deliverables for smaller but more detailed Sprint stories.

Final documentation

Once this phase also takes place in Scrum environment, much of the final documentation is done directly on the prototypes used in during the iterations of the concept creation. This is done adding information like visual specifications, workflow diagrams and detailed descriptions that might be not clear enough in the prototype itself. This document is submitted to team approval, so that it is clear for everyone what is to be done.

Concept and visual specification:

 

 

 

 

 

 

 

 

Style guides

I’ve been working with software interfaces that are part of a wider software family, and therefore need to be compliant with existing style guides. It is part of my job to check if there are already components available that can be re-used, analyze in specs and libraries if these components cover the use cases I am working on and, eventually, propose changes to the existing components and style guides. In case I create new ones, I also check if other apps might have their use cases covered with the same concept and work on a generic document to have it integrated in common libraries or frameworks in use, making it available for other teams and ensuring consistency and good usability across apps.

The reality…

This process description is what I use the call “ideal process” for big projects, proposed and put in practice in the last two companies I worked on, and followed in my previous experience as well. The pictures displayed are a collection of assets coming from different projects.

However, it is also relevant to mention that, in work routine, turbulent moments, tight deadlines, missing team colleagues (people get sick, go on vacation or, eventually, change jobs), change requests from customers, among other facts beyond anyone’s control required flexibility in order to achieve goals and overcome challenges. In practice, this means that I had to adapt in some situations, skipping parts of this process, proposing quicker methods, relying on expert’s evaluation only, working on consulting basis, or negotiating the best-possible solutions to fit on budget or technical constraints.

In all those situations, team working was decisive. And this goes on top of any process to achieve goals successfully.