Portfolio Design Process
Designers facilitate the engineering and development a product needs to be accessible, usable, learnable, and useful. We are our users' advocate and their champion.
It is right that we designers should challenge the enterprise and each other. We should innovate and excel, but we must recognise which battles to take on, and those that cannot benefit from the effort. Sometimes that's the Project Manager's role...
There are many design processes. Some are similar to ADDIE (Analysis, Design, Development, Implementation, Evaluation): a cycle closely related to how we learn. The Analysis part of the ADDIE cycle is often expanded. As you will see below, there is much to cover in the analysis of a design task and it can take a little organising.
Analysis is the most important aspect of any enterprise project, and yet it will be the least well resourced.
UX designers can make do and improvise intelligently, but projects benefit exponentially in line with the resources given to analysis.
What is our enterprise's Mission; its goals; its constraints, strengths, and features? How do these map to the product's and its users' environment, tasks, and needs? These are the first questions at the heart of our analysis. They are the background on which all design may flourish, or fail.
We need scope. What is the scope and how will we resource it? Is the scope finite, or does it take a more agile approach: evolution and not revolution?
What resources are available, and are there contingencies if more are needed?
And so on...
I am not a fan of the "Three Amigos" approach to Personas: a young user, a less young user, and an older user invariably useless with a browser; or whatever imaginary demographic meets our assumed hypothesis.
Where are our users accessing our digital content differently across devices, in improbable environments, or by overcoming differences in their cognitive or motor skills, browsing technologies, or other difficulties: not just visual impairments? All of them. No, your enterprise's success rests on the Three Amigos..?
Personas need to be real. To build a persona we must talk to an intelligently selected sample of our end-users.
In practice, meeting our users may not be practical. We can assume details about our users, but the result is assumed Personas. They will always miss vital aspects of who, how, what, when and where, as well as why our users approach our platforms as they do.
We need to get off our backside and find our users and talk to them - not with check-boxes on a clip board or eye tracking lasers - but talk to them. They are not Pavlovian machines. We must understand what drives them, will block their progress, or worry them. What encourages and engages them? What is it that our enterprise is asking our users to do, and what do our users expect of our enterprise?
It is important to "come off the screen". When our users access our digital products on a screen, there's a whole universe traversing their lives and their experience at the same time. We must know how that will affect the Human Computer Iteration and design for it where we can.
Even the advantages and costs of quality qualitative and quantitative research can be negated by scalping statistical bell curves into flat generalisations. How will we deal with the data?
Leaving "user testing" until after the design is completed, or only A-B testing trite solutions is not ideal, but next to useless without a clear understanding against what we are testing. Designs should be tested throughout the process from the first workshops to the last prototype. (Evolution: not revolution).
Cheapness will, if allowed, disable innovation and anything but run-of-the-mill experiences. If we want our products to do what we want and to profit from them, then we really must face up to and properly resource what User Analysis is: research!
Inclusivity Built In
Statistics suggest 80% of Internet users have a difference in their perception of, or use of our digital products. It is more important than ever to design inclusively for access and usability. This does not mean designing only for 'alternative browser technologies', but for alternative browsing strategies and methods. There's a wealth of difference.
W3C's Web Accessibility Perspectives is an excellent reference from which to challenge our perceptions of what designing for accessibility and usability is. Through videos, W3C illustrates why the underlying content and HTML architecture must be semantic, well written, and visually easy to use. Once we have the basics right, then we can do the pretty it up.
Perhaps too many visual artists get to be UX Designers and not enough UX Designers? Perhaps because managers are visual users and judge UX on the visual experience alone?
Mobile First "mythology" is an engineering methodology, not necessarily a design one. We can design for larger viewports first and scale down the UI for mobile presentation and still be "Mobile First" as long as the implementation is, "Mobile First".
Caution: Mobile device presentations may no longer be predicted by the screen size. The viewport is often under the user's or software's control. For example, two apps may run on the same mobile device screen. "Mobile First" must now, more than ever include Fluid Responsive presentation strategies. Read more about the Fluid Responsive Design philosophy and Mobile First methodology.
There is no one-size-fits-all process to build Personas or digital products and platforms. As for all aspects of design, it depends. But there are frameworks against which we can underpin our research and design processes within budget and time constraints.
There are safe assumptions we can make based on our and other enterprise's experience. Enterprises may already have sufficient knowledge of their users to make very informed assumptions.
At the least, we can prod and poke a Subject Matter Expert (SME) for information and insight. There are great resources available via Internet Searches too, which can yield background information on common user behaviours.
The ideal situation is to conduct primary user research and draw from it our users' expectations and to learn how to meet or better, exceed them. Any research is better than only making assumptions: even assumptions need researched.
Our assumptions are growingly intelligent. All is not lost.
Design relies on good intelligence of our enterprise and our user. It may be that further analysis and evaluation of our users' and enterprise's needs are required to ask questions raised by the team and our stakeholders.
The design process will generally include initial sketches of the solution used to garner buy-in from stakeholders, and which are then developed into wireframes and prototypes that can be tested against the Analysis.
In an agile scrum environment the question is, "When do we design? In Sprint, or pre-Grooming?" There are advantages to both and both can work equally well when adding new features to an existing product. However, with new products and designs, entering a Sprint with an untested solution may cause additional team effort through iterations. Contingencies of time may compromise the end solution.
The artefacts that a design team must deliver are the, "deliverables". These can include sketches, wireframes, prototypes, style guides, and all manner of supporting materials that will aide the development team - and perhaps the writers - in their tasks.
The skill is to know what needs delivered and not to deliver anything unnecessary to the task. Opinion may divide a team on what these should be. It is the designer's role to satisfy the team's needs, and to understand where and why these may at times be excessive. It's why designers need to work great with teams, and also to have the strength to help lead on and to communicate what their work-flow should be.
It is an arrogant team indeed not to offer user support. User support commences with the on-screen feedback we give our users through interaction with our materials to feedback on form completion.
Errors should be designed out where possible, but where possible errors should be managed for our user. If the on-screen environment is restricted, then this may need an external help system. This in turn may be required to open contextually to the support our user needs depending on where in the product they find difficulty.
UX Designers must have a part in this process before conflicting brands and values are implemented by other specialities who may be less well rehearsed in the digital paradigm.
Designers cannot sit back during the development of the solution. It is their role to quality assure that the design is implemented correctly and that contingencies of resources and effort are minimised by solid preparation.
A designer must understand the opportunities of technology to fully exploit it. Designers must be sensitive to the the engineers' skill set and abilities or otherwise prepared to mentor them.
Designers need to be nimble: to react to changing scope and needs rationally. They must return the best a compromise as necessary - or to call a halt on a Story that needs more attention than its Scrum schedule can afford.
Designers need to be able to say, "No". Equally, designers need to say, "Can do!"
Designers may take a back seat during a products implementation ("Release") phase, but will be far from redundant. It is during this short respite that design thinking should be applied to coming Stories and tasks.
It is also key to our engineers that, if there is an unforeseen problem, the designer can quickly confirm or adapt designs and evaluate any changes needed now or in the future.
Our designer should also take part in User Acceptance Testing (UAT): monitoring the engineering output for quality and accuracy and also picking up any nuances that may indicate a need to update a design or flow.
The ultimate test is when our users use the released features. It is important to gather feedback as quickly as possible. Your enterprise's support department is an ideal resource.
Back to Personas: you cannot capture every user in a persona. Now we have access to all of our user population there will be surprises. Designers must deal with them.
Conflict and Change
Conflict between designers can appear 'bloody' and at times damaging. But the benefits can outweigh the emotional wounds, which should be shrugged off by next breakfast anyway.
Conflict tests habits, ideas, and perceptions. It invigorates debate and encourages learning and change.
Designers will almost always conflict over something or other. At times the conflict will be trivial and at others you may see cataclysmic exchanges including salvoes of id. But as long as it is not only the loudest voice or largest ego that wins, and the outcome is positive to the enterprise, then it can be encouraged*.
Designers know that conflict is healthy. And they should know when it is not. Team managers need to be aware that conflict generally has a cause - and right or wrong, that cause may feed vital insight into a design.
*Caution: never leave two instructional designers on their own in a room together for longer than half a cup of coffee. (At least, not armed with tea spoons 😂)
There's no one-size-fits-all design process. ADDIE outlines the general flow. Each designer and enterprise will follow what works for them. It is only essential that whatever the analysis is, that it is thorough and not overly compromised by low resources.
It is important for the designer takes ownership of their design and support its development and implementation closely. They must be available to make informed decisions quickly when issues arise with it. Designers are a resource too.