In my last post, I introduced the single-page application, a more sophisticated alternative to developing complex Web applications. Now I would like to go through and talk a bit about what it takes to design such an application.
First, an important point of clarification: “design” is not just about the visuals. Design is about developing the complete experience; decisions on system architecture, database structure, and integration points between systems all are as much about design as the look and feel. In addition, how the site or application looks is also only a small part of the design; as important are the decisions that go into the interactions between the person using the application and the application.
It’s critical to have a good design process, and that as many issues as possible are identified and addressed before implementation. The consequences of bad design are severe:
- Addressing a design flaw at the beginning of a project might take only an hour. Once implementation begins that same flaw might take 10 hours to address, and once deployed then it can easily extend to 100 hours to address.
- Forrester’s analysis of public companies showed that over a six year period, those who were leaders in customer experience saw a 43% increase in stock price, while the laggards saw a 34% decline.
- In the case of mission critical applications, bad design can have life or death consequences.
At the start of any project, the team needs to agree on the methodology to be used for design and development. That means that agreement is needed on how much to design at once (e.g. do we break it up into phases), how to incorporate the client and the client’s customers into that process, whether to break off any elements of the project to work on separately (e.g. proof of concept work), and how to document the design.
The Typical Artifacts of Design
In most Web applications, there is a fairly common set of artifacts that are created by the visual designer, the information architect, and the business analyst, including but not limited to:
- Site map
- Use case definitions
- Front-end style guide
There can be many other kinds of design documents used as well, but for the purposes of brevity this article will focus on those artifacts used for UI design.
Wireframes are a low-resolution approach to modelling the layout of a page or screen. They show the presence and position of labels, containers, icons, and other visual devices but omit any stylistic embellishment. They are created to put focus on relationships between different elements of the page or screen, and through annotations on each wireframe, critical business rules might be hilighted (such as “only show this link if the person has logged in”, or “grid should show up to 10 most recently viewed products, not including the currently viewed product”).
Wireframes can be used to model a wide range of content, including informational sites and single-page applications, and are quite helpful for the application developer as they can represent the entirety of the application without having to do high-resolution mockups for each page or scenario. Multiple scenarios can be modelled, and different flows through the site or application can be shown, which can be quite useful for demonstration to the client and for usability assessments for the application’s end audience.
The site map is a high-level view of the site, showing the top-level navigation hierarchy for the site. It can highlight important parts of the site and can show the relationship between a single-page application and any other site content that might co-exist, however is too high a level of a work product to be useful for within a single page application.
Use case definitions (usually just referred to as use cases) are specifications that document the desired interactions between the system and the actor (the person using the system). They generally define a set of steps to be taken to achieve a specific outcome. For example, one use case for software running a bank machine might be to withdraw cash, and it would detail the steps to be taken from the actor identifying themselves, selecting the account, entering a quantity, and finally dispensing the cash.
The use case generally goes into significant detail and identifies all relevant business rules that influence the outcome as well as any relevant data relationships. Use case definitions are routinely used for websites, web applications, stand-alone applications, mobile apps, and any other interactive application. Properly done, use cases should be written in a manner that’s agnostic to the implementation. So for instance a use case should not provide a step that says “the user enters their username and password, then presses the login button”; instead it should say “the user authenticates to the system”, as that does not prescribe a particular way of logging in. Use cases written with this approach make it easier for them to apply to developing a single page application.
The style guide documents the look and feel of the website or application, separate from the site content. It includes guidelines for the use of colour, typography, grids, and spacing & alignment. It will often include guidance statements that talk to the visual design philosophy, and it will include a library of re-usable design patterns. The intention behind the style guide is to create visual consistency amongst all designers and developers in an organization, and to allow for new content or capabilities created after the initial development effort to continue to use the same consistent design. The best style guides include actual live samples that developers can copy and paste into their work so that buttons, links, tables, headings, and any other screen elements not only look the same but are structured the same and are kept updated as the project changes over time.
A prototype usually takes the form of a simplified version of the application to be developed, done in a way where it looks and behaves like the final application will, but uses only static data and simplified code. It may not use the same technologies that the final product will use, as the emphasis in a prototype is fast development. The purpose of a prototype is to allow a design to be shown to client or internal stakeholders, then quickly updated in response to feedback. The big advantage of showing a prototype to stakeholders versus a set of screen mockups or wireframes is that screen flow and transitions can be evaluated, not just the layout of information. On the flip side, it can also leave the impression with the client that the application is almost done even when you tell them what still needs to be done to actually develop the application.
Depending on the development methodology used, prototypes can be useful for SPA design. If all the design work is to be done up front, a prototype mitigates some of the risk of developing the significant complexity by allowing interaction and design issues to be worked out before major development begins. If an agile methodology is to be used, a prototype may be less useful.
In addition to these more traditional design tools, there are many other useful design artifacts, including:
User stories, a staple of the agile development community, are very short descriptions of capabilities that a person using the system would want to achieve. They are often just a single sentence in the form of “As a [type of user], I want [some goal] so that [some reason]”. This format is frequently used because it provides an indicator of who the capability is to be used by, what the capability is, and why it’s needed. They are often written on small cards so that they can be moved along on a whiteboard to indicate the story’s status.
Storyboards, previously used primarily for developing media content, are increasingly being used for application design. In this context, a storyboard is used for telling a user story, outlining how a particular feature is to be used. Storyboards are often quite low fi, and can be as simple as a set of 6 or 8 hand-drawn panels. They are good for telling quick stories in a visual manner with context and are quite relevant when used with an agile development approach.
Whiteboards & sticky notes are used to generate any number of different design artifacts, such as empathy maps (a tool for understanding the application’s audience), scenario maps (steps taken by someone using the system to perform a task), and many other possible artifacts. This genre of artifact is extremely useful for developing an understanding of the problem area, the people involved, and approaches for tacking these problems.
The Challenges of Designing a Single Page Application
One of the big challenges of designing a single page application is that there is no single approach that works for every project. There are a myriad of different approaches and a myriad of advocates and detractors for each approach. The one commonality though from a single page application perspective is that when designing an SPA, you are not designing a web site, you are designing an application that happens to be developed using web technologies.
The first thing we need to look at when determining how to design our application is the development methodology that we are going to use, which is basically what are the steps that we are going to take to design, develop, and test our application. There are a huge number of methodologies, but it can be useful to put them on a continuum of how much iteration is going to be done.
Heading Down a Waterfall
On one end of the continuum is the traditional waterfall approach, where we design everything up front, then we develop everything, then we test everything. This approach requires extensive design documentation, and pretty much all of it done at the beginning. Wireframes, use case documentation, site maps, and style guides are all par for the course here. Also frequently seen are design documents such as process flow diagrams (documents business processes), entity relationship diagrams (documents data relationships), and others. Prototypes are also common here since if you are designing the entire application up front, and there are limited opportunities for revision as you go, then you will probably want to validate your design early.
With waterfall, traditional template-oriented wireframe approaches that have been used to create web sites may not be sufficient to handle the increased complexity and business logic that goes into application design. Wireframes still can be a useful tool, but the complexities of some SPAs can result in a large number of wireframe screens. One phased waterfall application I worked on had more than 200 wireframe screens detailed.
Waterfall is sometimes broken down into a phased approach, where each phase might be a complete 4-6 month development effort. This spreads out some of the design effort, but the design work products generally are much the same. The waterfall approach is falling out of favour at the enterprise level, and is totally eschewed by many small development shops in favour of Agile approaches, however it is still found in many enterprise projects where there is regulatory oversight needed, where the burden of changing requirements after design approvals are obtained can be high.
WOrking in Circles
At the other end of the iteration continuum are the Agile methodologies. In Scrum, for instance, design, development, and testing are done in very short cycles, often as short as two weeks from start of design to production ready code. With such short cycles, it should be no surprise that there are much fewer design artifacts. The emphasis instead is to do only the work needed to get a small subset of features designed, developed, and ready for production. Refactoring of code is done as needed in subsequent iterations to provide for the additional features to come, and continuous testing and integration processes are used to give constant feedback as to whether the ongoing development meets the design criteria set in the design effort for that iteration.
Many proponents of this approach see well designed working code as the only real design artifacts, which is too minimal for my taste. Scrum encourages as much documentation as is needed to communicate what needs to be developed, and no more, but it does not mean there is no documentation. Style guides, Photoshop mockups, and simple wireframes all still make sense with this approach, but it’s up to each Scrum team to decide amongst themselves what kind of documentation will be needed. Scrum and related methodologies can handle SPA types of applications without all the large up-front design overhead, however not every client or every project works well with an Agile approach.
Mixing it up
Where things start to get interesting is when you look at some of the hybrid approaches. IBM’s Design Thinking methodology, for instance, uses the short development cycles from the Agile playbook, but injects a more robust design process into the mix. An initial client engagement workshop focusses exclusively on applying design principles to the client’s business problems. There is additional design work before development starts to plot out a vision for the solution, which creates a foundation for the design efforts applied to each iteration. In addition to user stories, there may also be storyboards, white-board empathy maps & scenario maps, style guides, and use cases. Some artifacts such as style guides and empathy maps might be done before primary development begins. Others such as user stories, storyboards, and use cases will be done on a per-iteration basis and will focus just on what needs to be developed for the next iteration.
Designing a single page application can definitely involve significant complexity, and it is important that developers have a visual picture of what it is that they are doing. Working solely from use case definitions can be very challenging and can lead to differing implementations across a multi-developer team due to differing interpretations of how to actually implement a use case. To mitigate this, wireframes, storyboards, and style guides can all be really useful tools. For waterfall-like projects, wireframes are extremely useful for both developers and testers and for getting early feedback from stakeholders. For agile projects, wireframes can give a useful top-level view of the application and its parts without going into the specifics of each screen, which can be created along with smaller scale wireframes or storyboards that give a visual overview for developers to follow for each user story. Regardless of development approach, style guides (especially if done as a living pattern template) are a very valuable tool that will help you design a high quality consistent experience in your single page application. Develop an agreement on your team as to what makes sense, and if things don’t seem to be working as well as you like, don’t be afraid to recommend changing what design artifacts you create.
If you have any questions on the artifacts or approaches described here, feel free to ask in the comment section.