Design Processes, Artifacts, and Work Style

Design Processes, Artifacts, and Work Style

A collage of my work artifacts: paper and whiteboard sketches, Balsamiq Mockups prototypes, Photoshop prototypes fed into interactive on-device prototypes, HTML/CSS prototypes, and UI specifications.

A collage of my work artifacts: paper and whiteboard sketches, Balsamiq Mockups prototypes, Photoshop prototypes fed into interactive on-device prototypes, HTML/CSS prototypes, and UI specifications.

Design Processes, Artifacts, and Work Style

What Am I Like As A Designer?

How do I work, and what am I like to work with?

There are many ways to answer that, and here are a few, more focused questions that should shed light on that overall question:

  1. With what UX design processes am I conversant, and how flexible am I with those processes?
  2. What artifacts do I typically produce in my design work?
  3. How do I work with those around me, from other interaction designers and UX professionals to management, product management, developers, business stakeholders, marketing, legal, etc.?

Design Process and Artifacts

I believe that there is no One True User Experience Design process, but, rather, many different approaches and tools with the same goal—a design that “fits” with users’ behavior and how they think about their domain of activity.

There are quite a number of processes, frameworks, and tools that have been developed and articulated to get to that goal. These include Norman and Draper’s User-Centered Design, Constantine and Lockwood’s Usage-Centered Design, Alan Cooper’s Goal-Directed Design (which pioneered the use of Personas), and Beyer and Holzblatt’s Contextual Design.

I’ve used each of these and am familiar with them to varying degrees, but which one is the best to use? As with so many UX questions, the answer is, “It depends.” It depends on things like the UX team’s skills and background, the project’s timeline, the corporate environment (whether and how fully management supports UX priorities), the type of project or product, and many other factors.

So the best approach is familiarity and expertise in as many of these approaches and tools as possible, then choosing the ones that fit any given situation.

That said, the UX process of any particular project will generally have some subset of these general stages:

  1. Domain research. Are there aspects of the domain that may be identified as domain structure or constraints that may influence or be taken advantage of in the ultimate design? This is a phase in which the UX team learns about the things that matter in the domain for which they are designing the product. What things matter, how can they be used/interacted with, how they influence each other, who has what rights to see, use, or edit what, how are these things and activities related to other tools, products, or processes that will be outside the scope of your product?
  2. User behavior research. How can users current behavior in the current domain-state be described? Does that behavior suggest positives or negatives with respect to accomplishing their goals within the domain? Are there regularities that may be taken advantage of when positive or done away with when negative? What tools do they use now? How are those tools embedded in the fabric of their activity or their activity “ecosystem”?
  3. Market research. Are there solutions already out there? What’s out there that is related? How well do they support users in their activities and goals? How are they strong or weak with respect to your design and experience goals?
  4. Digesting the data into design-useful artifacts. This process may include diagramming, card sorting, Post-It note affinity diagrams/sorting, and re-representing the notes and data in various ways. Products of this process may include diagrams, personas, scenarios, sketches, lists of problems, lists of requirements, usage models, content models, navigation models, task models (e.g., essential use cases), etc. Of particular inspiration to me a this stage is a quote by Herbert Simon (from his book, Sciences of the Artificial, 3rd Edition): “solving a problem simply means representing it so as to make the solution transparent.” This means trying many different approaches, framing and reframing the problem that you’re trying to solve in search of different ways to understand and capture the problem, choosing promising ones, creating designs to follow them, and iterating upon those, going as deeply as you need to in order to choose the most promising designs. This stage often blends and flows back and forth with the next stage, Design.
    1. Sample artifacts: Digesting data for personas
    2. Sample artifacts: Content Models (Usage-Centered Design)
    3. Sample artifacts: Navigation Models (Usage-Centered Design)
  5. Design. Of course, this is an iterative and circular process with sub-processes. It can involve attempts to re-represent the problems (as mentioned in the Digesting phase), casting about for inspiration and models, brainstorming and ideation, lists and re-lists of requirements, content models, navigation models, task models, sketches, Balsamiq mockups, HTML, PowerPoint, even Photoshop–whatever’s quick,  easy, easily let-go, and supportive of reflection. The level of fidelity used in producing prototypes will vary with the stage of the design. The further along the design is, the more likely that the prototyping will be of higher fidelity or specificity. "Implementation" tools that I’ve used in the design phase include: whiteboards, paper and pencil, Balsamiq Mockups, PowerPoint, HTML/CSS (Dreamweaver), Photoshop, Axure RP Pro, and Word (i.e., for UI specifications). This is also the phase in which existing solutions such as platform guidelines, UX guidelines, product suite UI conventions, and design pattern libraries are taken into account and used as appropriate. For me, the first time designs start to take shape are in sketches. It is rare that the first explorations are in digital form. Rather, perhaps like Da Vinci (though I won’t claim any other comparisons with him), I generally explore my ideas first by drawing freehand (so, paper or whiteboard, usually). As a medium, freehand drawing is less constrained, generally takes less effort, and requires less time commitment to get ideas down, giving the freedom to explore any potential design space more widely. After some ideas or approaches solidify a little bit, that’s when I’ll switch to other prototyping tools that generally require a little more time and are a little more constraining on design possibilities.
    1. Sub-processes: Idea generation, Idea exploration, Refinement, Make choices and “go deep”, then repeat recursively as design problems are identified.
    2. Sample artifacts: sketches on paper. Paper and pencil sketching is great. It’s quick, can be done in almost any environment, is generally portable, offers just enough structure to hang imagination on and yet barely constraining it. Paper sketches can be abstract or detailed or anything in between. Together, these qualities make it especially great for jotting down inspirations, brainstorming, and quick explorations, yet don’t prevent more detailed work when necessary, though other tools may be better when doing detailed work that involves, say, particular platforms’ UI standards.
    3. Sample artifacts: sketches on whiteboards. Whiteboards are also great. They allow for quick, easily modifiable sketches and a quickly switchable, limited color palette. They also allow designers to literally have a “big picture” of their design. Finally, they provide great support for brainstorming, designing, or reviewing as a group.
    4. Sample artifacts: Scenarios, screen flows, storyboards, etc. These show users might use your product or how it might fit into their lives, whether showing a series of interactions in use or showing how users might progress through a set of interaction contexts (for example, screens) as they do their task or activity with your product. These can even be a sequence of screens annotated with behaviors, as I present in my Pandora Driving Mode’s storyboard, or a sequence of screen mockups in the order in which they are expected to progress, as in RedBeacon Design Challenge: Storyboarding the New Design.
    5. Sample artifacts: Balsamiq mockups. Balsamiq Mockups is a fantastic product aimed primarily at the ideation phase of design. Its tools and stencils support very quick creation of screens and pages, and its sketch-like quality leaves imagination free in a way that more finished-looking artifacts do not. This makes it great for not only personal ideation, but getting feedback and reflections from others. In that latter case especially, Balsamiq Mockups’ clear lack of finish encourages feedback that is more “I don’t know if users will understand that arrangement” and less “I think that font needs to be Calibri”. Balsamiq Mockups output can be be shared as Mockups files, images, clickable prototypes, or clickable pdfs.
    6. Sample artifacts: HTML/CSS. Sometimes, you need to communicate precisely what colors or precisely what you want something to look like in a way that is expressible in HTML and CSS—whether that be a coworker in the cube next to you or a remote development team. And when that’s necessary, or when they simply prefer to get their input from their UX designer as code, sometimes that’s just the way to go.
    7. Sample artifacts: Photoshop and HTML/CSS-Photoshop hybrids. When you need to create pixel-perfect mockups, whether to add to HTML/CSS mockups or on their own, sometimes, Photoshop is the way to go. This can have its cost, of course. For me, sometimes HTML/CSS is faster or a better hand-off product for the development team with which I’m working, and other times, and, other times, Photoshop is what’s called for.
    8. Sample artifacts: Interactive prototypes, using various tools including POP (Paper on Paper),, Invision, and Pixate. Whether using raw materials such as pictures of sketches, screens, or assets created in Photoshop or other graphic programs or their own drawing and animation tools, these prototyping tools enable designers to create truly interactive prototypes, allowing the linking up of screens, the defining of hotspots, the use of interactive UI widgets, animations, and transitions, and sensitivity to gestural input, taking your prototypes that much closer to a native, real app experience on your mobile device.
    9. Sample artifacts: Video demos of prototypes. Sometimes, a storyboard or an interactive demo is best showcased via a video.
      • From my Pandora Driving Mode project, here are two demo videos of my interactive prototype, recorded on my Android phone using AZ Recorder—one demo without commentary, and the other essentially a presentation of the prototype along with rationale for its design:

        Driving mode prototype in action, no commentary (45 seconds). Tools used: Photoshop,, AZ Screen Recorder.

        Presentation of Driving Mode prototype (7 minutes 25 seconds). Tools used: Photoshop,, AZ Screen Recorder.

    10. Sample artifacts: UI specifications
  6. Develop. This will interact with the Design processes as constraints and interactions between elements are identified. The way I’ve seen this work best is with heavy interaction available between development engineers and the UX team, with each being able to ask and answer questions and adjust the design as it develops.
  7. Usability/User Experience testing. What is it like to use the product at its various stages of being designed and developed? It should be tested and evaluated all along the way, with lessons learned from testing adding to the mix of idea generation, idea exploration, “going deep”, etc. To label this as a seventh “stage” is a bit misleading, as testing should ideally be done whenever user behavior questions arise from stages 5 and 6 and as ideas and prototypes coalesce to gather feedback and information about how each design idea or prototype works for users.
  8. Wrap up version and release…
  9. Repeat the processes looking towards future versions.

Working with Edwin

While it is true that the creative processes that are part of any design effort require a certain degree of solitude and self-reflection, it is undeniably true for me personally that collaboration and feedback, especially with other designers and UX professionals, help me achieve better solutions sooner.

Thus, I prefer environments and cultures that include a number of UX professionals, provide space and room to create your own solutions, and foster a spirit of collaboration.

Excerpts from recommendations on my LinkedIn profile attest especially to my team focus:

Edwin brings a fun attitude to a team and works hard at creating a great working environment. – Paul Gilliham

He worked with the project team collaboratively, remained open to our suggestions, and retained his flexibility under pressure. – Deanna Wells

His deep knowledge and empathetic approach wins him fans whenever he works with a new team. – Bill Skeet

Comments are closed